ok, I'll buy the argument for "as", although if you want a BigDecimal of exactly 0.1 you should probably use "'0.1' as BigDecimal", as the JDK explains in the constructors for BigDecimal. Or better; 0.1G. Trusting truncation is optimistic, especially for floats. In Groovy 1.1 + 0.1 == 1.2, but 1.1F + 0.1F == 1.200000025331974.
Anyway..

But why shouldn't double.toBigDecimal() do a full precision conversion, like new BigDecimal(double) and BigDecimal b = double?

Ronny

On Feb 9, 2010, at 6:11 PM, Jim White wrote:

> new BigDecimal(double) is Java API and does a full precision conversion.
>
> double.toBigDecimal() is a GDK method and goes through "groovy" conversion via toString() and thus truncates. It is used by "as".
>
> If you want full precision use new BigDecimal or a cast. If not, use "as" (or double.toBigDecimal).
>
> The change (and there must be a JIRA somewhere and I'm pretty sure I made the change) was that the cast used to do rounding, which is a Bad Thing for doing arithmetic and was inconsitent with new BigDecimal(double).
>
> The jira: http://jira.codehaus.org/browse/GROOVY-3171
>
> There are of course many other related issues and discussion in the past, but I'm pretty sure we've got it (at least more) correct now.
>
> Jim
>
> Ronny Løvtangen wrote:
>
>> I would expect d.toBigDecimal() to preserve as much precision as possible.
>> If this is not the case, I think at least the javadoc should say so. Current javadoc says "Transform a Number into a BigDecimal"
>> I still find it hard to believe that d.toBigDecimal() and new BigDecimal(d) intentionally should produce different result.
>> Ronny
>> On Feb 9, 2010, at 4:35 PM, Jim White wrote:
>>> Ronny Løvtangen wrote:
>>>
>>>
>>>> Yes, I would expect all variants to produce the same result, so I guess it's not intended. I also tried with new BigDecimal(d)
>>>> In both 1.6.5, 1.6.6 an 1.7.0, the result is 0.1411200080598672135234750157906091772019863128662109375.
>>>
>>> I don't recall whether there was a change at 1.6.5 or not, although I have a faint memory of doing something in that area.
>>>
>>> I don't agree though that all forms of coercion should give the same result.
>>>
>>> The assignment is doing a cast rather than a "groovy" (typical expected human-friendly result) conversion that "as" does and is full precision.
>>>
>>> When doing calculations there must be a way to get that, and I'm thinking there was a change for just that purpose.
>>>
>>> Unfortunately I can't look into this deeper at the moment. Perhaps someday we can just have a FAQ that points to the relevant paragraph in the spec...
>>>
>>> Jim
>>>
>>>
>>>> Ronny
>>>> On Feb 8, 2010, at 11:00 PM, Paul King wrote:
>>>>
>>>>> I suspect it isn't intended but haven't yet checked the related
>>>>> Jiras that occurred around that time.
>>>>>
>>>>> Paul.
>>>>>
>>>>> Ronny Løvtangen wrote:
>>>>>
>>>>>
>>>>>> Is this change in behavior from Groovy 1.6.5 to 1.6.6 and later intended, or not?
>>>>>> Double d = Math.sin(3)
>>>>>> BigDecimal b1 = d.toBigDecimal()
>>>>>> BigDecimal b2 = d as BigDecimal
>>>>>> BigDecimal b3 = d
>>>>>> println d
>>>>>> println b1
>>>>>> println b2
>>>>>> println b3
>>>>>> Result, Groovy 1.6.5:
>>>>>> 0.1411200080598672
>>>>>> 0.1411200080598672
>>>>>> 0.1411200080598672
>>>>>> 0.1411200080598672
>>>>>> Result, Groovy 1.6.6 and 1.7.0:
>>>>>> 0.1411200080598672
>>>>>> 0.1411200080598672
>>>>>> 0.1411200080598672
>>>>>> 0.1411200080598672135234750157906091772019863128662109375
>>>>>> Ronny
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>  http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email