Skip to main content

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

  • From: Jonathan Fuerth < >
  • To:
  • Subject: [json-processing-spec users] Re: BigDecimal for equals()/hashCode()
  • Date: Thu, 24 Jan 2013 20:59:57 -0500

On 2013-01-24, at 3:12 PM, Jitendra Kotamraju wrote:

> On 01/24/2013 08:13 AM, Jonathan Fuerth wrote:
>
>
>> 1. JsonNumber should explicitly specify that it preserves the full 
>> precision of the value it was constructed from (this is potentially 
>> relevant for any JsonNumber constructed from a
> We clearly specify how long, double, int, BigInteger, String -> BigDecimal 
> conversion in javadoc. The semantics of BigDecimal are used for all other 
> purposes. What else do you want me to specify in javadoc ? I can do that if 
> there is better way to document it.

If, in the end, we decide to stay with the existing plan (that is, tie 
JsonNumber semantics to BigDecimal) then we can revisit this.

>>   I submit that it goes against all reasonable expectations that a 
>> JsonNumber received on the wire as "10" would not compare equal to a 
>> JsonNumber received on the wire as "10.0" or "10.00". Leading and trailing 
>> zeroes that don't contribute to the number's magnitude should be 
>> disregarded for the purposes of equality. I think specifying otherwise in a
> Should you want this to be limited to equality/hashCode or want to use for 
> toString represenation ?

I think toString should always return what went in, verbatim. The JsonNumber 
implementations, when constructed from a string, should verify that they have 
been constructed with a valid JSON numeric value. We'd further specify that 
in case the number was constructed from a BigDecimal, trailing zeroes and 
appear in this string too.

This is just a tightening of the existing specification of 
JsonNumber.toString(), which promises to produce a valid JSON representation 
of the number.

> Say JsonNumber num1 is constructed with double 10.0d, JsonNumber num2 is 
> constructed with integer 10, do you want num1 and num2 to be equal ? What 
> about representation, are you ok with both being written on the wire as 10 
> ? If that's the case,

Yes, new JsonNumberImpl(10.0).equals(new JsonNumberImpl(10)) should be true.

> then your suggestion would be as follows:
> long, double, int, BigInteger, String -> BigDecimal -> 
> BigDecimal#stripTrailingZeros() and use the last BigDecimal in the chain 
> for toString(), equals(), hashCode(), getNumberType()

Yes, that looks like a valid way to implement what I'm suggesting. But the 
point would be that another implementation could achieve identical results 
with careful use of String.

> The other option you are suggesting is:
> int, long, double, BigInteger, BigDecimal, String -> String and use for 
> toString(), equals(), hashCode(), getNumberType(), getXXValue() methods 
> etc. To get that right is not easy while taking care of exponential 
> notation, and conversions. If you have the algorithms(or sample JsonNumber 
> impl) for that, it would be easy to understand what cases would work and 
> what cases wouldn't.

I think I can sneak in the time to work on this tomorrow. If not, Saturday. 
I'll follow up when I have something.

But again, my real desire isn't to yank BigDecimal out of the org.glassfish 
reference implementation; what I'm really saying is that I don't think we 
should force other implementations to use BigDecimal. It should be possible 
to implement JsonNumber without resorting to BigDecimal for toString(), 
hashCode(), and equals().

-Jonathan

> 
>> Java-JavaScript communication library constitutes a hidden trap.
>
>> So now that we're all (hopefully!) discussing the same topic, I'm keen to 
>> hear your insights.
>
>> -Jonathan
>
>> On 2013-01-24, at 12:07 AM, Jitendra Kotamraju wrote:
>
>>> Martin proposed different algorithm for JsonNumber equals()/hashCode() in 
>>> his review [1]. I am including Joe's response on this.
>>> 
>>> I am also ccing him, please include him in replies as he is not on the 
>>> users mailing list. His response is as follows:
>>> -----
>>> In general, it is essentially unpredictable from inspection which decimal 
>>> strings are exactly representable as double floating-point value.  Yes, 
>>> there are many cases which are easy, but quick, pick which one of these 
>>> two values is exactly representable as double:
>>> 
>>> 4.940656458412465441765687928682213723650598026143247644255856825006755
>>> 0727020875186529983636163599237979656469544571773092665671035593979639
>>> 8774796010781878126300713190311404527845817167848982103688718636056998
>>> 7307230500063874091535649843873124733972731696151400317153853980741262
>>> 3856559117102665855668676818703956031062493194527159149245532930545654
>>> 4401127480129709999541931989409080416563324524757147869014726780159355
>>> 2386115501348035264934720193790268107107491703332226844753335720832431
>>> 9360923828934583680601060115061698097530783422773183292479049825247307
>>> 7637592724787465608477820373446969953364701797267771758512566055119913
>>> 1504891101451037862738167250955837389733598993664809941164205702637090
>>> 279242767544565229087538682506419718265533447265625e-324
>>> 
>>> 4.940656458412465441765687928682213723650598026143247644255856825006755
>>> 0727020875186529983636163599237979656469544571773092665671035593979639
>>> 8774796010781878126300713190311404527845817167848982103688718636056998
>>> 7307230500063874091535649843873124733972731696151400317153853980741262
>>> 3856559117102665855668676818703956031162493194527159149245532930545654
>>> 4401127480129709999541931989409080416563324524757147869014726780159355
>>> 2386115501348035264934720193790268107107491703332226844753335720832431
>>> 9360923828934583680601060115061698097530783422773183292479049825247307
>>> 7637592724787465608477820373446969953364701797267771758512566055119913
>>> 1504891101451037862738167250955837389733598993664809941164205702637090
>>> 279242767544565229087538682506419718265533447265625e-324
>>> 
>>> Need more time?  Did you correctly pick the first one?
>>> 
>>> Using BigDecimal as the numerical back store removes the concern for this 
>>> and many other numerical anomalies at the cost of the "10.0" is not 
>>> always equivalent to "10" issue.  However, the latter problem is 
>>> manageable whereas predicting string to double conversion is much less so.
>>> 
>>> The equals / hashCode contracts of BigDecimal and long-standing and 
>>> should by built-upon by the JSON API.  You can define an alternative 
>>> equals / hashCode definition (the hashcode in the pdf isn't quite right, 
>>> the a numeric zero needs to be handled separately), but that introduces 
>>> other kinds of anomalies.
>>> ----------
>>> [1] http://crazyjavahacking.org/jsonProcessingReview.pdf
> 



[json-processing-spec users] BigDecimal for equals()/hashCode()

Jitendra Kotamraju 01/24/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jonathan Fuerth 01/24/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jitendra Kotamraju 01/24/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jonathan Fuerth 01/25/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jonathan Fuerth 01/25/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jörn Horstmann 01/24/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jitendra Kotamraju 01/24/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jonathan Fuerth 01/25/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jonathan Fuerth 01/28/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jonathan Fuerth 01/28/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jitendra Kotamraju 01/29/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jonathan Fuerth 01/29/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jitendra Kotamraju 01/29/2013

[json-processing-spec users] Re: BigDecimal for equals()/hashCode()

Jonathan Fuerth 01/29/2013
 
 
Close
loading
Please Confirm
Close