• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSLog with %f and comparisons using ==
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSLog with %f and comparisons using ==


  • Subject: Re: NSLog with %f and comparisons using ==
  • From: James Maxwell <email@hidden>
  • Date: Sat, 11 Apr 2009 16:47:41 -0700

oh, geez... Okay, you guys made your point! ;-)

One thing I love about this list; I *always* get useful info.

I'll find a better way to do this soon. In this particular case, the "match" could be specified as broadly as any value falling within a sort of "bin." The "bottoms" of each of these bins are defined by the constant float array. So, I could probably just say that any number that falls above the lower limit of a bin (i.e., half-way between float A and B), or below the upper limit of the bin (half-way between float B and C) is in the bin.

Anyway, these "bins" are fairly far apart so, as I said before, it seems pretty safe, for the time being.
I will clean it up soon.


thanks for all the valuable info!

J.


On 11-Apr-09, at 2:12 PM, Michael Ash wrote:

On Sat, Apr 11, 2009 at 4:45 PM, James Maxwell
<email@hidden> wrote:
hmm... Well, this all sounds like a sledge-hammer approach to my immediate
problem.


The actual explanation of what I'm doing is kind of long-winded, so I'll
spare you that. For now, I know the calculated values will always come out
the same, since there are a limited number of possible inputs, and I know
they'll very nearly match my stored constants (and my constants are well
separated, so  is more than enough).

Are you always running these calculations on identical hardware? Because unless you're doing that, there's no way you can know that your calculated values will always come out the same.

Floating point isn't just imprecise because the variables are of
finite size and therefore finite precision. It's also imprecise
because the individual calculations are not always performed to the
full precision available in the finite representation, and the
variation from full precision is pretty much implementation defined.

Mike
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: NSLog with %f and comparisons using ==
      • From: Michael Ash <email@hidden>
References: 
 >Re: NSLog with %f and comparisons using == (From: Greg Guerin <email@hidden>)
 >Re: NSLog with %f and comparisons using == (From: James Maxwell <email@hidden>)
 >Re: NSLog with %f and comparisons using == (From: Michael Ash <email@hidden>)

  • Prev by Date: Re: NSLog with %f and comparisons using ==
  • Next by Date: @selector not working with (id)anObject
  • Previous by thread: Re: NSLog with %f and comparisons using ==
  • Next by thread: Re: NSLog with %f and comparisons using ==
  • Index(es):
    • Date
    • Thread