+[NSNumber objectWithSqlColumnRepresentation:] perfoms a non fixed-point comparison.

[GoogleCodeExporter]

In +[NSNumber objectWithSqlColumnRepresentation:] you're comparing a long long 
to a double 
without a margin for error.

For more information http://www.cygnus-
software.com/papers/comparingfloats/comparingfloats.htm

Original issue reported on code.google.com by j.p.dann on 23 Jan 2009 at 2:55

[GoogleCodeExporter]

Actually, I don't want a margin of error here - that comparison is intended to 
determine whether you should use 
a floating point value or not. If NSNumber is holding an integer, then the 
values will be equal. I'm not checking to 
see if they are equal for mathematical reasons, I'm checking to see if they're 
the same. If they are the same, then 
NSNumber holds an integer value, if they aren't exactly equal, then it holds a 
floating point value, so I don't want 
a margin of error. I don't want to assume that 1.9999999 is really 2 in this 
case.

Original comment by jeff.lam...@gmail.com on 19 Feb 2009 at 1:38

• Changed state: WontFix

[GoogleCodeExporter]

hi Jeff,

In that case you should use the CFNumberRef API. NSNumber is toll-free bridged 
with NSNumber so you can 
do

NSNumber *myNumber = /*...*/;
if (CFNumberIsFloatType((CFNumberRef)myNumber) {
}

or for more fine-grained control use CFNumberGetType()

Original comment by j.p.dann on 25 Mar 2009 at 3:47

[GoogleCodeExporter]

Sorry, that should read:

"NSNumber is toll-free bridged with CFNumberRef"

Original comment by j.p.dann on 25 Mar 2009 at 3:49

[GoogleCodeExporter]

Sorry to post en-masse.

Is there a particular reason that NSNumbers are stored as strings in the SQLite 
database? With the CFNumberAPI 
above you could determine the correct data type to store the value, rather than 
using -[NSNumber stringValue], 
then the whole problem goes away.

Please correct me if I've missed something :)

Original comment by j.p.dann on 25 Mar 2009 at 5:30