Browse thread
[Caml-list] string_of_float less accurate than sprintf "%f" ?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2002-05-02 (13:28) |
From: | David Chase <chase@w...> |
Subject: | Re: [Caml-list] string_of_float less accurate than sprintf "%f" ? |
At 10:44 PM 5/2/2002 +1000, John Max Skaller wrote: >Beck01, Wolfgang wrote: > >>while doing some time measurements with Unix.gettimeofday() I >>discovered a problem with string_of_float: >> >># string_of_float 123456789.123456789;; >>- : string = "123456789.123" >There's another problem too: > ># string_of_float 42.0;; >- : string = "42" > >The result isn't an ocaml float literal. I'm new to Caml, but I did manage to slog through the sources enough to determine that Caml does it "wrong", at least as measured against what is possible and freely available. A version of the Java rules would be appropriate here -- as many digits as necessary to disambiguate from any other machine double/float, or at least one fractional digit, whichever is shorter. David Gay wrote some code to do this (gdtoa) that is available at netlib, and (having glued this code to a Java VM) I can provide some guidance in using it, if you would like. You can also use gdtoa to get other sorts of formatting -- n digits past the point, that sort of thing. Similarly, the transcendental functions available in fdlibm (Freely Distributable libm) are almost as fast as hardware (on those machines where there is hardware), but avoid the stupid input limits (e.g., |x| < 2**64) and also use a large enough value of PI to always deliver a result that is within 1 ulp, usually within 1/2 ulp (I have studied this problem more than I care to). The results will be fast, portable across all platforms, and as correct as you are likely to get, certainly as good as you are likely to get for free. Note: where available, hardware sqrt and log are usually usable, though I have not checked carefully in those portions of domain where their derivative is > 1. If someone decides to do this, please contact me, I have a list of fixes necessary for correct compilation of fdlibm under Microsoft's incorrect C compilers. Some ninny thought that the distributive law held true for machine FP, and they don't constant propagate "funny values" (NaN, -0) properly. yours, David Chase ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners