What happened?
Doubles in conjure-java failed for some numbers that should've been supported: palantir/conjure-java#1006. While discussing the fix we realized we haven't defined how we expect conjure to handle doubles, specifically around lossiness in deserialization.
What did you want to happen?
The following questions should be answered:
- Should the deserialization behavior of an integral JSON number (
\d+) be identical to a floating point JSON number w/ a zero decimal value (\d+\.0)? E.g. should 9007199254740993 result in the same behavior as 9007199254740993.0?
- Are any "losses" acceptable? Examples (received value, returned value)
9007199254740993 -> 9007199254740992.09007199254740993.0 -> 9007199254740992.09007199254740992.1 -> 9007199254740992.00.30000000000000004 -> 0.300000000000000040.30000000000000003 -> 0.300000000000000040.30000000000000002 -> 0.300000000000000040.30000000000000001 -> 0.3
Note that these results are a bit misleading. Floating points technically don't actually describe a single value, but a range (e.g. 0.3 is actually 0.29999999999999996... - 0.30000000000000001..., the center point is ~ 0.29999999999999998; when a double gets printed, it'll emit the number in that range with the shortest decimal representation; this is also the cause of the classic 0.1 + 0.2 = 0.30000000000000004).
What happened?
Doubles in conjure-java failed for some numbers that should've been supported: palantir/conjure-java#1006. While discussing the fix we realized we haven't defined how we expect conjure to handle doubles, specifically around lossiness in deserialization.
What did you want to happen?
The following questions should be answered:
\d+) be identical to a floating point JSON number w/ a zero decimal value (\d+\.0)? E.g. should9007199254740993result in the same behavior as9007199254740993.0?9007199254740993->9007199254740992.09007199254740993.0->9007199254740992.09007199254740992.1->9007199254740992.00.30000000000000004->0.300000000000000040.30000000000000003->0.300000000000000040.30000000000000002->0.300000000000000040.30000000000000001->0.3Note that these results are a bit misleading. Floating points technically don't actually describe a single value, but a range (e.g.
0.3is actually0.29999999999999996...-0.30000000000000001..., the center point is ~0.29999999999999998; when a double gets printed, it'll emit the number in that range with the shortest decimal representation; this is also the cause of the classic0.1 + 0.2 = 0.30000000000000004).