groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Schalk Cronjé <ysb...@gmail.com>
Subject Re: Casting Double to BigDecimal
Date Tue, 12 Jan 2016 00:45:27 GMT
I did not know there was even a difference. I tend to prefer 'as TYPE' 
for IMO it reads better than '(TYPE)'. Maybe it is also left-over from 
my C++ days where the latetr style cast was inherited from C and frowned 
upon.

Is this 'cheap & fast' casting only affecting native types or is it 
casting in general?

On 12/01/2016 00:39, Jochen Theodorou wrote:
>
> Well, cheap and fast is of course relatively spoken ;)
>
> Anyway... the general path is ScriptBytecodeAdapter.castToType. But in 
> many cases we do actually emit direct code for transformation, if we 
> have enough information to do that.
>
> As of why asType uses the toString path... that would be 
> https://issues.apache.org/jira/browse/GROOVY-3171 not sure if the 
> reason is really valid though I must say... someone is always 
> surprised and I don't know if newbies will us "as"
>
> bye Jochen
>
>
> Am 11.01.2016 um 15:48 schrieb Alberto Vilches:
>> Interesting! now I have more doubts about this:
>>
>> 1 Where is this cheap & fast implementation of the Java-like casting? Is
>> it in GDK or it is implemented at low-level by the Groovy compiler? I
>> only know the asType method in DefaultGroovyMethods.
>> 2 Why the "asType" method use the expensive way new
>> BigDecimal(d.toString()) instead the fast?
>>
>> Thank you Jochen. :)
>>
>> On Mon, Jan 11, 2016 at 2:00 PM, Jochen Theodorou <blackdrag@gmx.org
>> <mailto:blackdrag@gmx.org>> wrote:
>>
>>     We tryied to have two different kinds of casts. The normal one, that
>>     is more in the style of Java, which tries the cheapest way. And the
>>     "as" version, which calls into asType is customizable and usually
>>     does more expensive operations. The fallback for asType is the
>>     normal cast. That's why we see asType as an extended cast. But don't
>>     expect asType simply as something that allows for more cases than
>>     the normal cast. I can have different conversion logic.
>>
>>     Now
>>
>>     new BigDecimal(d)
>>
>>     is much cheaper than
>>
>>     new BigDecimal(d.toString())
>>
>>     That those two do not match is actually because of d.toString(),
>>     which does simply give 1.9 here, instead of the exact double value.
>>     That this toString() methods behaves in this way has not always been
>>     the case afaik.
>>
>>     bye Jochen
>>
>>     Am 11.01.2016 um 10:57 schrieb Alberto Vilches:
>>
>>         Yes, I know the "1.9" literal in Groovy results in a BigDecimal.
>>         That's
>>         why I'm trying to force the double using the "d", but maybe is
>>         still a
>>         bigdecimal. So, let's try again:
>>
>>               Double d = 1.9
>>               println((BigDecimal)d)
>>
>>         prints "1.899999999999999911182158029987476766109466552734375"
>>
>>         and
>>
>>               Double d = 1.9
>>               println d as BigDecimal
>>
>>         prints "1.9"
>>
>>
>>
>>         On Fri, Jan 8, 2016 at 1:34 PM, Naresha K. <naresha.k@gmail.com
>>         <mailto:naresha.k@gmail.com>
>>         <mailto:naresha.k@gmail.com <mailto:naresha.k@gmail.com>>>

>> 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
>>         <vilches@gmail.com <mailto:vilches@gmail.com>
>>              <mailto:vilches@gmail.com <mailto:vilches@gmail.com>>>

>> 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
>>
>>
>>
>>
>>
>>         --
>>         Un saludo.
>>         Alberto Vilches
>>
>>
>>
>>
>> -- 
>> Un saludo.
>> Alberto Vilches


-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r


Mime
View raw message