Skip to main content

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

  • From: Jonathan Fuerth < >
  • To: Jonathan Fuerth < >
  • Cc: , Joe Darcy < >
  • Subject: [json-processing-spec users] Re: BigDecimal for equals()/hashCode()
  • Date: Thu, 24 Jan 2013 21:01:08 -0500

Sorry for the double post; I forgot to copy Joe on the reply.

On 2013-01-24, at 8:59 PM, Jonathan Fuerth wrote:

> 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