Sorry, bad example, 1.1F + 0.1F doesn't involve conversion to BigDecimal.
But println 1.1F + 0.1F as BigDecimal --> 1.200000025331974
Bottomline, you shouldn't use floats at all if you need precision.


On Feb 9, 2010, at 6:56 PM, Ronny Løvtangen wrote:

> 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
>
>


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

  http://xircles.codehaus.org/manage_email