Actually, it may be a second bug. I'm tired and am ready to give up for
the day.
-- Sean
On 9/10/15 1:30 PM, Sean Gilligan wrote:
> Adding 'L' produces the same result. I actually discovered this issue
> a while back and even wrote some unit tests for it (see link in my
> previous email). It's embarrassing that I didn't recognize it immediately.
>
> I wish I had the time and ability to submit a fix.
>
> -- Sean
>
>
> On 9/10/15 1:26 PM, corneil.duples...@gmail.com wrote:
>> Try adding L to your long constants.
>> I ran into a similar problem the other days where my calculation of
>> date difference in milliseconds produced an overflow and a negative
>> number.
>>
>> assert 100000000000000016L == (({ BigDecimal it ->
>> it})(100000000000000010L))
>>
>>
>> --
>> Corneil du Plessis
>> https://about.me/corneil
>>
>> <https://about.me/corneil?promo=email_sig>
>>
>>
>> On 10 September 2015 at 22:15, Sean Gilligan <s...@msgilligan.com
>> <mailto:s...@msgilligan.com>> wrote:
>>
>> A one line assert which PASSES and shouldn't:
>>
>> assert 100000000000000016 == (({ BigDecimal it ->
>> it})(100000000000000010))
>>
>>
>> More detail (all asserts pass):
>>
>> def val = 100000000000000010
>> assert val.class == Long
>> def closure = { BigDecimal it -> it}
>> def bdVal = closure(val)
>> assert bdVal.class == BigDecimal
>> assert bdVal == 100000000000000016
>> def bdCastVal = (BigDecimal) val
>> assert bdCastVal.class == BigDecimal
>> assert bdCastVal == 100000000000000010
>>
>> So, converting to BigDecimal with a cast or with an `as` seems to
>> work.
>> But having Groovy do it automatically for a function or closure
>> parameter fails.
>>
>> Am I missing something? Is this a known issue?
>>
>> Thanks,
>>
>> Sean
>>
>>
>>
>
