[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