[Issue 1681] cast(real) ulong.max == 0

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1681


baryluk at mpi.int.pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baryluk at mpi.int.pl




------- Comment #4 from baryluk at mpi.int.pl  2008-01-20 09:13 -------
writefln("ulong.max      %-30d", ulong.max);
writefln("real ulong.max %-30f", cast(real)ulong.max);

gdc (GCC) 4.1.3 20080114 (prerelease gdc 0.25 20071124, using dmd 1.022)
(Debian 0.25-4.1.2-19)

ulong.max      18446744073709551615          
real ulong.max 18446744073709551615.000000   

dmd 1.025:

ulong.max      18446744073709551615          
real ulong.max 18446744073709551615.000000  

This can depend on processor (some processors aren't strictly following IEEE
754, especially in extented precission). Also real isn't nacassary 80bit, real
can be double on some architectures and processors. As far as I known Intel
processors do real extended precission operations (in fact they use internally
128 bit precission).


Tested machines:
Debian GNU/Linux etch, Pentium III (Coppermine) 733MHz
Debian GNU/Linux unstable, Intel(R) Pentium(R) 4 CPU 2.80GHz
Debian GNU/Linux etch, AMD Duron 1200MHz (Unknown model)


Unfortunetly example from first post gives 0 in dmd (gdc works), so it is a
bug.


The largest integer real which gives nonzero result after cast is
18446744073709550591.000000   
18446744073709549568
but as you can see it gives wrong result. Then it is skiping every 2048 (11
bits), with some values correct:
18446744073709549568.000000
18446744073709549568
but most not.

Largest continues interval with correct answers:
0.0 ... 8744073709552616.000000  (about 2**53, so doubles are involved not
real!)

(similar in decimal expansion 18446744073709551615.000000, but probably
coincidence)


--