> My guess is it's because .000001 cannot be expressed exactly as a
> float. Like base 10 cannot express 1/3, IEEE floats have trouble with
> 1/10 and derivatives.
>
> Steve
Yes, that's right, 0.000001f is not exactly representable with an IEEE
floating point number. I suspect that the OP's original 9.9534e-7 is the
closest a 64 bit FP number can get to 0.000001f. Its one reason why you
must be very careful with expressions like:
if (fpnumber == 0.000001f) then
And, of course, the original java.lang.Float gets converted to a JS
equivalent which is (almost) the same as a java.lang.Double in JS - but
will still have the same precision when emulated in hosted mode - so,
beware!
In my code I rarely, if ever, use floats anymore, especially if I think
that they are going to be used in GWT. The issues of additional
serialization payload are best solved by compression.
Alan
>
>
> On Feb 8, 9:54 am, Andrey Korzhevskiy<a.korzhevs...@gmail.com> wrote:
>> Hello everyone,
>>
>> I found interesting issue. Suppose I have this java code:
>>
>> float f = 0.000001f;
>> someFunc(f)
>>
>> which is generated by GWT into js code, something like that
>>
>> someFunc(9.9534e-7)
>>
>> So my question is: if GWT sees constant in code why it processes this
>> constant so strange? I expect to see in generated js this call:
>> someFunc(0.000001)
>> Is there some complex float numbers processing in gwt-dev?
>>
>> Thank you,
>> Andrew
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment