Re: NSNumber stringValue

[Lane Roathe]

on Sat, Dec 12, 2009 Andy Lee may have said:

>As glenn pointed out, that string most certainly *can* be a string that
>can be converted back to a bitwise equivalent of the original float.
>Ben's question was whether in practice it is guaranteed to be so, or
>whether stringValue uses a maximum number of decimal places that would
>lead to rounding error.  I can't tell from a quick look at the docs.

A float is 32 bits, so it can not represent in exact bits every integer
value, not to mention decimal places. Thus while a string can be
converted back to a bitwise equivalent of the original float, there is
no guarantee that it will be.

Also, keep in mind that internally Apple represents many values as
doubles. Thus some of the examples in the discussion, such as:

>whether going out to the stringValue and back to
>the doubleValue is guaranteed to yield a float that is bitwise
>identical to the original float

are giving up 32 bits of precision for no reason. If you start with a
NSNumber, write that out as a string, then read it back in as a string,
convert back to an NSNumber, and then get that value as a float you are
not only converting the value back and forth between binary and string
representations, but also from 64bit to 32bit representations. The
binary conversion is likely to loose more precision than the string
conversions.

If you are starting with a value that can be represented as a double,
keep it in that format. Unless you are on a mobile device, GPU code or
other specialty code the use of doubles is not costly enough to worry
about and it gives you much better precision during calculations as well
as better retention when converting back and forth between string and
binary representations.

Lane Roathe, CEO
Ideas From the Deep, llc  
___
Life is cheap, but the accessories will break you.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[Andy Lee]

On Dec 12, 2009, at 7:38 PM, RedleX Support wrote:
> My original intent was to store a representation of the float in a string so 
> I can load it back again. In the meanwhile I found that using the %a format 
> along with NSScanner's scanHexDouble does the trick (since I don't need that 
> string to be human readable a hex representation is ok for me)
> 
> 
> double a=pi;
> double b;
> 
> [[NSScanner scannerWithString:[NSString stringWithFormat:@"%a",a]] 
> scanHexDouble:&b];
> 
> if (a==b)
>   NSLog(@"Success");
> else
>   NSLog(@"Failure");

I hadn't thought of that -- I was going to suggest using NSArchiver and 
NSUnarchiver, though that approach would produce binaries rather than strings.  
NSScanner will work if you know you're always going to have a normal value but 
doesn't handle the nan and inf cases Andrew mentioned.  I'm guessing you can 
get around that by writing your own trivial parser class that detects "nan", 
"inf", and "-inf" and converts those special cases to NAN, INFINITY, and 
-INFINITY, and uses NSScanner for all other cases.  I don't know enough about 
"non-normal" float values to know for sure, though it might be close enough for 
your purposes.

As a side note, I found that you don't get perfect precision if you store an 
NSNumber in a plist; it looks like it stores the stringValue.

Out of curiosity, I wonder how Core Data stores floats and doubles if you 
choose an XML data store.  I would expect it to be precise, but I'm admittedly 
too lazy to check.

--Andy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[RedleX Support]

You should not compare floating point numbers for equality in most  
cases. This is true of any language on any platform.


Indeed, some floating-point numbers (such as the one represented by  
the integer 0x7fc0) will compare as not equal to themselves:


 I think what the OP really wanted to know (and I'm interested in  
the answer too) is whether going out to the stringValue and back to  
the doubleValue is guaranteed to yield a float that is bitwise  
identical to the original float, or whether there is "drift" in the  
least significant bit or two due to the changes in representation.   
Anyway, even if that's not the OP meant, that's what I'd like to  
ask.  :->



My original intent was to store a representation of the float in a  
string so I can load it back again. In the meanwhile I found that  
using the %a format along with NSScanner's scanHexDouble does the  
trick (since I don't need that string to be human readable a hex  
representation is ok for me)



double a=pi;
double b;

[[NSScanner scannerWithString:[NSString stringWithFormat:@"%a",a]]  
scanHexDouble:&b];


if (a==b)
NSLog(@"Success");
else
NSLog(@"Failure");

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[Andrew Farmer]

On 12 Dec 2009, at 09:32, Ben Haller wrote:
>>> You should not compare floating point numbers for equality in most cases. 
>>> This is true of any language on any platform.
>> 
>> Indeed, some floating-point numbers (such as the one represented by the 
>> integer 0x7fc0) will compare as not equal to themselves:
> 
>  I think what the OP really wanted to know (and I'm interested in the answer 
> too) is whether going out to the stringValue and back to the doubleValue is 
> guaranteed to yield a float that is bitwise identical to the original float, 
> or whether there is "drift" in the least significant bit or two due to the 
> changes in representation.  Anyway, even if that's not the OP meant, that's 
> what I'd like to ask.  :->

Nope, there are trivial counterexamples there too. All NaNs stringify to "nan", 
for instance, and all infinities stringify to either "inf" or "-inf", depending 
on sign.

(And, even if you only care about finite numbers, Andy Lee has an excellent 
counterexample for that as well.)___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[Andy Lee]

P.P.S.  Never mind, passing f = 0.12345678901234567 is a counterexample.  So 
the answer is no, you won't get a bitwise equivalent if you do a 
stringValue-floatValue round trip.

--Andy

On Dec 12, 2009, at 1:25 PM, Andy Lee wrote:

> On Dec 12, 2009, at 1:07 PM, Andy Lee wrote:
>> If I understand the question, it's not about converting an arbitrary decimal 
>> string to a float, but specifically a string that was generated from a float 
>> in the first place.
>> 
>> As glenn pointed out, that string most certainly *can* be a string that can 
>> be converted back to a bitwise equivalent of the original float.  Ben's 
>> question was whether in practice it is guaranteed to be so, or whether 
>> stringValue uses a maximum number of decimal places that would lead to 
>> rounding error.  I can't tell from a quick look at the docs.
> 
> P.S.  If the answer is no, it seems to me there should be an easy 
> counterexample, but my math isn't good enough to figure one out.  I've tried 
> the following code with f = 0.1, 0.11, and 0.12345, but I always get back 
> a bitwise match for the original float, even when stringValue returns a 
> rounded string.
> 
> - (void)testFloat:(float)f
> {
> NSString * s = [[NSNumber numberWithFloat:f] stringValue];
> float f2 = [s floatValue];
> NSLog(@"%.20f, %@, %.20f", f, s, f2);
> char *cp1 = (char *)(&f);
> char *cp2 = (char *)(&f2);
> int i;
> for (i = 0; i < sizeof(float); i++)
> {
> NSLog(@"byte %d %@", i, (cp1[i] == cp2[i] ? @"MATCHES" : @"DOES NOT 
> match"));
> }
> }
> 
> --Andy
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[Andy Lee]

On Dec 12, 2009, at 1:07 PM, Andy Lee wrote:
> If I understand the question, it's not about converting an arbitrary decimal 
> string to a float, but specifically a string that was generated from a float 
> in the first place.
> 
> As glenn pointed out, that string most certainly *can* be a string that can 
> be converted back to a bitwise equivalent of the original float.  Ben's 
> question was whether in practice it is guaranteed to be so, or whether 
> stringValue uses a maximum number of decimal places that would lead to 
> rounding error.  I can't tell from a quick look at the docs.

P.S.  If the answer is no, it seems to me there should be an easy 
counterexample, but my math isn't good enough to figure one out.  I've tried 
the following code with f = 0.1, 0.11, and 0.12345, but I always get back a 
bitwise match for the original float, even when stringValue returns a rounded 
string.

- (void)testFloat:(float)f
{
NSString * s = [[NSNumber numberWithFloat:f] stringValue];
float f2 = [s floatValue];
NSLog(@"%.20f, %@, %.20f", f, s, f2);
char *cp1 = (char *)(&f);
char *cp2 = (char *)(&f2);
int i;
for (i = 0; i < sizeof(float); i++)
{
NSLog(@"byte %d %@", i, (cp1[i] == cp2[i] ? @"MATCHES" : @"DOES NOT 
match"));
}
}

--Andy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[Andy Lee]

On Dec 12, 2009, at 12:51 PM, David Rowland wrote:
> On Dec 12, 2009, at 9:32 AM, Ben Haller wrote:
> 
 You should not compare floating point numbers for equality in most cases. 
 This is true of any language on any platform.
>>> 
>>> Indeed, some floating-point numbers (such as the one represented by the 
>>> integer 0x7fc0) will compare as not equal to themselves:
>> 
>> I think what the OP really wanted to know (and I'm interested in the answer 
>> too) is whether going out to the stringValue and back to the doubleValue is 
>> guaranteed to yield a float that is bitwise identical to the original float, 
>> or whether there is "drift" in the least significant bit or two due to the 
>> changes in representation.  Anyway, even if that's not the OP meant, that's 
>> what I'd like to ask.  :->
>> 
> 
> The problem with floating point is that the binary form almost always uses 
> binary arithmetic. That means that a number like 0.1 has an infinitely 
> repeating binary form. It is likely that converting the string "0.1" to a 
> float and then back will yield "0.1" because it will be rounded, but there 
> are marginal cases where you won't get what you put in.
> 
> Also, the string can carry more information than the float. "8.336" is 
> different from "8.336000". The latter implies that you know the precision to 
> six decimal places, the former does not.

If I understand the question, it's not about converting an arbitrary decimal 
string to a float, but specifically a string that was generated from a float in 
the first place.

As glenn pointed out, that string most certainly *can* be a string that can be 
converted back to a bitwise equivalent of the original float.  Ben's question 
was whether in practice it is guaranteed to be so, or whether stringValue uses 
a maximum number of decimal places that would lead to rounding error.  I can't 
tell from a quick look at the docs.

--Andy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[David Rowland]

On Dec 12, 2009, at 9:32 AM, Ben Haller wrote:

You should not compare floating point numbers for equality in most  
cases. This is true of any language on any platform.


Indeed, some floating-point numbers (such as the one represented by  
the integer 0x7fc0) will compare as not equal to themselves:


 I think what the OP really wanted to know (and I'm interested in  
the answer too) is whether going out to the stringValue and back to  
the doubleValue is guaranteed to yield a float that is bitwise  
identical to the original float, or whether there is "drift" in the  
least significant bit or two due to the changes in representation.   
Anyway, even if that's not the OP meant, that's what I'd like to  
ask.  :->




The problem with floating point is that the binary form almost always  
uses binary arithmetic. That means that a number like 0.1 has an  
infinitely repeating binary form. It is likely that converting the  
string "0.1" to a float and then back will yield "0.1" because it will  
be rounded, but there are marginal cases where you won't get what you  
put in.


Also, the string can carry more information than the float. "8.336" is  
different from "8.336000". The latter implies that you know the  
precision to six decimal places, the former does not.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[glenn andreas]

 
On Saturday, December 12, 2009, at 11:32AM, "Ben Haller" 
 wrote:
>>> You should not compare floating point numbers for equality in most  
>>> cases. This is true of any language on any platform.
>>
>> Indeed, some floating-point numbers (such as the one represented by  
>> the integer 0x7fc0) will compare as not equal to themselves:
>
>   I think what the OP really wanted to know (and I'm interested in  
>the answer too) is whether going out to the stringValue and back to  
>the doubleValue is guaranteed to yield a float that is bitwise  
>identical to the original float, or whether there is "drift" in the  
>least significant bit or two due to the changes in representation.   
>Anyway, even if that's not the OP meant, that's what I'd like to  
>ask.  :->
>

It is absolutely not guaranteed to work - see 
.

To be able to convert base 2 (the binary representation) to base 10 (the 
textual representation) without a loss of precision is possible (since 2 is a 
factor of 10), though it potentially requires at least 17 digits (quick back of 
the envelope calculation of how many digits are in 1/2**24, given that a float 
has a 24 bit mantissa), and stringValue isn't documented as providing any 
specific number of digits of precision.

Going the other way, 0.1 (base 10) isn't possible to be represented exactly as 
a floating point number.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[Ben Haller]

You should not compare floating point numbers for equality in most  
cases. This is true of any language on any platform.


Indeed, some floating-point numbers (such as the one represented by  
the integer 0x7fc0) will compare as not equal to themselves:


  I think what the OP really wanted to know (and I'm interested in  
the answer too) is whether going out to the stringValue and back to  
the doubleValue is guaranteed to yield a float that is bitwise  
identical to the original float, or whether there is "drift" in the  
least significant bit or two due to the changes in representation.   
Anyway, even if that's not the OP meant, that's what I'd like to  
ask.  :->


Ben Haller
Stick Software

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[Andrew Farmer]

On 11 Dec 2009, at 21:14, Bryan Henry wrote:
> You should not compare floating point numbers for equality in most cases. 
> This is true of any language on any platform.

Indeed, some floating-point numbers (such as the one represented by the integer 
0x7fc0) will compare as not equal to themselves:

{
union { float f; long i; } u;
u.i = 0x7fc0;
if(u.f == u.f)
printf("As expected.\n");
else
printf("How strange.\n");
}___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNumber stringValue

[Bryan Henry]

You should not compare floating point numbers for equality in most cases. This 
is true of any language on any platform.

See 
http://www.cygnus-software.com/papers/comparingfloats/Comparing%20floating%20point%20numbers.htm

- Bryan

On Dec 10, 2009, at 10:02:23 PM, RedleX Support wrote:

> Hi,
> 
> I need to output a double into a text file and then read it back with 100% 
> accuracy, will using NSNumber stringValue and then using NSString doubleValue 
> give me good results?
> 
> For example, if I write the following:
> 
> double a,b;
> 
> a=some number;
> 
> b=[[[NSNumber numberWithDouble:a] stringValue] doubleValue];
> 
> will a==b
> 
> TIA
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/bryanhenry%40mac.com
> 
> This email sent to bryanhe...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSNumber stringValue

[RedleX Support]

Hi,

I need to output a double into a text file and then read it back with  
100% accuracy, will using NSNumber stringValue and then using NSString  
doubleValue give me good results?


For example, if I write the following:

double a,b;

a=some number;

b=[[[NSNumber numberWithDouble:a] stringValue] doubleValue];

will a==b

TIA

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com