Thank you Charlie. This seems like a bug in JS, more than just the way it handles float. Because I'm not doing any calculations on the GWT (JS) side, I'm just printing what comes from the server. So if 15.2 if printed as 15.2000000000, that would be ok, but to be printed as 15.199999809265136 is really weired. Am I right or am I missing something?
Sending the floats from the server as Strings should fix it for now. But in the future, I want to plot this date, on GWT, so I might have to use gwt-math. Thank you. On Feb 24, 10:05 am, Charlie Collins <[email protected]> wrote: > On the "GWT Browser" they are still Java (hosted mode). In actual > browsers they are JavaScript. > > You will get different results in browsers because JavaScript only has > 64 bit floats. > > The GWT docs put it this way: > > " * Intrinsic types: Primitive types (boolean, byte, char, short, > int, long, float, and double), Object, String, arrays, user-defined > classes, etc. are all supported, with a couple of caveats. > o Arithmetic: In JavaScript, the only available numeric type > is a 64-bit floating point value. All Java primitive numeric types > (except for long, see below), are therefore implemented in web mode as > if on doubles. Primarily, that means overflowing an integral data type > (byte, char, short, int) will not wrap the underlying value as Java > specifies. Instead, the resulting value will outside of the legal > range for that data type. Operations on float are performed as double > and will result in more-than-expected precision. Integer division is > implemented to explicitly round to the correct value. > o long: JavaScript has no 64-bit integral type, so long > needs special consideration. Prior to GWT 1.5, the long type was was > simply mapped to the integral range of a 64-bit JavaScript floating- > point value, giving long variables an actual range less than the full > 64 bits. As of GWT 1.5, long primitives are emulated as a pair of 32- > bit integers, and work reliably over the entire 64-bit range. Overflow > is emulated to match the expected behavior. There are a couple of > caveats. Heavy use of long operations will have a performance impact > due to the underlying emulation. Additionally, long primitives cannot > be used in > JSNI code > because they are not a native JavaScript numeric type. " > > http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=goog... > > You might want to try to use different types, or format - or if you > need the precision, and don't want it to vary, try something like gwt- > math -http://code.google.com/p/gwt-math/. > > On Feb 24, 9:52 am, "tony.p.." <[email protected]> wrote: > > > Hello everyone, > > > I'm getting strange behavior for float numbers. I'm processing data on > > the server, reading it from a file. The data consists of strings, > > floats and integers. I read them all as Strings, then process their > > actual values. Then when I display them, on the GWT client, via RPC, I > > get this: > > > -15.2 becomes -15.199999809265136 > > 1.2 becomes 1.2000000476837158 > > 0.2 becomes 0.20000000298023224 > > 1.4 becomes 1.399999976158142 > > > on FF/IE/Chrome on Windows and FF on Linux. They are only displayed > > correctly on the GWT browser. > > > If you know what is causing this or how I can fix it, please let me > > know. > > > Thank you, > > Tony --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
