Integral double values are encoded as integers

[arschles]

if I run this code:

static NSString * key = @"doubleKey";
NSNumber * doubleNumber = [NSNumber numberWithDouble:22];
NSMutableDictionary * dict = [NSMutableDictionary dictionary];
[dict setObject:doubleNumber forKey:key];
NSLog("%@", [dict JSONString]);

I get this json:

{"doubleKey":22}

I'm not intimately familiar with the JSON spec, but this encoding was causing me some problems where I expected a double to come back on decode, but an int came back.

I implemented a possible fix locally, but I'd like to hear feedback before I fork and submit a pull request. The fix is to change the format string at https://github.com/johnezang/JSONKit/blob/master/JSONKit.m#L2755, which is currently "%.17g" to "%#.17g" in order to force trailing zeroes for double values that are also whole numbers.

[johnezang]

This is a sticky corner case. It is, however, documented behavior in the README.md (queue trumpets blaring). The passage in particular is:

Floating-point numbers are converted to their decimal representation using the printf format conversion specifier %.17g. Theoretically this allows up to a float, or IEEE 754 Single 32-bit floating-point, worth of precision to be represented. This means that for practical purposes, double values are converted to float values with the associated loss of precision. The RFC 4627 standard is silent on how floating-point numbers should be dealt with and the author has found that real world JSON implementations vary wildly in how they handle this issue. Furthermore, the %g format conversion specifier may convert floating-point values that can be exactly represented as an integer to a textual representation that does not include a . or e– essentially silently promoting a floating-point value to an integer value (i.e, 5.0 becomes 5). Because of these and many other issues surrounding the conversion and manipulation of floating-point values, you should not expect or depend on floating point values to maintain their full precision, or when round tripped, to compare equal.

The very short answer: You're pretty much screwed. Fundamentally and throughly.

From the printf documentation, I note the following (wrt/ # modifier):

For g and G conversions, trailing zeros are not removed from the result as they would otherwise be.

Yuck. So basically every single floating point number becomes 17 digits long. The cure is worst than the disease...

I'm sympathetic, but there's no obvious Right Thing(tm) to do, or way to handle it. :(

[arschles]

Hey John,

I understand and agree with pretty much everything you said, except that the cure is worse than the disease. I think that it's only slightly better than the disease, but my opinion may change :). I'm going to fork and make the change to add the # modifier for now.

[arschles]

Thanks for your response, by the way