That was surprising!
(BigDecimal)1.9D is same as new BigDeicmal(1.9D) (through *castToType*)
While
1.9D as BigDecimal is same as new BigDecimal(1.9D.toString())
Here is the source:
public static BigDecimal toBigDecimal(Number self) {
// Quick method for scalars.
if ((self instanceof Long)
|| (self instanceof Integer)
|| (self instanceof Short)
|| (self instanceof Byte))
{
return BigDecimal.valueOf(self.longValue());
}
*return new BigDecimal(self.toString());*
}
It's always safer to create an object of BigDecimal from String than from a
double.
Thanks!
On Fri, Jan 8, 2016 at 6:08 PM, Alessio Stalla <[email protected]>
wrote:
> How do you verify that the two values are different?
>
> On 8 January 2016 at 13:34, Naresha K. <[email protected]> wrote:
>
>> Value 1.9 will be of type BigDecimal.
>> Why are you using D?
>>
>>
>> On Fri, Jan 8, 2016 at 5:45 PM, Alberto Vilches <[email protected]>
>> wrote:
>>
>>> Hi everybody! We have an issue in our application, and we realized these
>>> two lines have differents results. We wonder why because we think it should
>>> calls to the DefaultGroovyMethods.asType(Number self, Class<T> c). But it
>>> seems only the explicit call to "as" finally calls to the asType and the
>>> casting do a different thing (just a new BigDecimal(1.9D), but we wonder in
>>> which part of Groovy is happening)
>>>
>>> (BigDecimal)1.9D //
>>> "1.899999999999999911182158029987476766109466552734375" ->
>>> 1.9D as BigDecimal // "1.9"
>>>
>>> In fact, we tried to put these two lines in the Groovy console and see
>>> the AST in all the phases. But in all of them shows the same code:
>>>
>>> public java.lang.Object run() {
>>> ((1.9) as java.math.BigDecimal)
>>> return ((1.9) as java.math.BigDecimal)
>>> }
>>>
>>> Somebody please could give some light? Thank you very much and happy new
>>> year :)
>>>
>>> --
>>> Un saludo.
>>> Alberto Vilches
>>>
>>
>>
>
