[MLton] Re: Hppa

[Wesley W. Terpstra]

On Tue, Dec 21, 2004 at 12:12:47AM -0800, Stephen Weeks wrote:
> > I've attached a log of the regression tests.
> > I am a bit disturbed by how only half of the digits in 'real' agree.
> 
> I am also disturbed.  The problem is not trigonometric functions.  All
> of the failures are on Real32.{+,-}.  As you mention -- the failures
> are not just in the few lowest-order digits.  Here are the failures
> (as computed on my x86) with the different result on HPPA underneath
> each one.  Essentially there are only two failures, up to reordering
> of arguments and sign changes.

#define FLT_MIN 1.17549435e-38
I read up on this and this is the smallest unnormalized float: 2^-125.

The results of some calculations are smaller than this and therefore must
be expressed as 'denormalized numbers'. These are numbers where you have 
only 23 bits of precision to represent 0.xxxxx * 2^-125.

If you punch 2^23 into a calculator, you'll see it's 8388608.
That's how many digits can be significant (7) in the part following the 
decimal when the exponent is 2^-127 =~ e-38.

>  = 0.5877471754111438E~38
> <> 0.5877470352812973E~38
       1234567
... you see? All the digits beyond this point are meaningless.

For bigger numbers, we have 2^24 bits which is about 8 digits of precision,
regardless of the exponent. These are 'normalized' and have a leading 1.

>  = 0.11754942106924411E~37
> <> 0.11754940705625946E~37
       12345678
... yep!

> Hopefully this additional data inspires someone to figure out the problem.

Yep, hppa is fine. =)

The unit test is in error; for a floating point number printed into decimal,
no more than 8 digits should be printed for normalized numbers. Furthermore,
no digits with a base 10 exponent less than 10^-45 should be printed (b/c
that's where unnormalized numbers take over and they can't represent below
that point either). Even then, the last digit might differ a little...

-- 
Wesley W. Terpstra