[erlang-bugs] : : Math library defect?
Raimo Niskanen
raimo+erlang-bugs@REDACTED
Tue May 20 09:35:12 CEST 2008
On Mon, May 19, 2008 at 05:47:36PM +0200, Matthias Lang wrote:
> Raimo Niskanen writes:
>
> > I can not reproduce the original problem.
> > Using R12B-2:
>
> Ok, and the original poster just (an hour or two ago) told us that
> he's using "erl5.5.5" which is probably R11B-5 on _windows_.
>
Sorry about that oversight. I was very tired yesterday,
should not have answered at all...
> And here's what I get on an XP machine with service pack 2, Hollywood
> Content Protection System 9, Anti-Virus 15.871, SCO licence #7:
Ehm?
>
> 1> init:script_id().
> {"OTP APN 181 01","R11B"}
> 2> io:fwrite("~f\n", [math:pow(2,57)]).
> 144115188075855870.000000
>
> Raimo:
> > 2> io:format("~f~n", [math:pow(2,57)]).
> > 144115188075855872.000000
>
> So, Windows, at least that particular variant on that particular
> machine, seems to behave slightly differently. I don't have a C
> compiler for Windows and I don't know if math library source is even
> available.
I can now confirm that OTP R12B-3 beta behaves the same,
at least on XP probably SP 2.
Eshell V5.6.3 (abort with ^G)
1> f(F), F = math:pow(2, 57).
144115188075855870.0
2> erlang:term_to_binary(F, [{minor_version, 1}]).
<<131,70,67,128,0,0,0,0,0,0>>
3> round(F).
144115188075855872
4> trunc(F).
144115188075855872
5> io:format("~f~n", [F]).
144115188075855870.000000
ok
6> io:format("~.22e~n", [F]).
1.441151880758558700000e+17
ok
7> io:format("~.22g~n", [F]).
1.441151880758558700000e+17
ok
Since the bit pattern of the float is correct as well as
the values from round/1 and trunc/1; it is most probably
C library sprintf(, "%.20e", ) that behaves differently
from Unixes.
>
> Matt
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-bugs
mailing list