# [MLton] Re: Hppa

**Stephen Weeks
**
MLton@mlton.org

*Tue, 21 Dec 2004 20:06:29 -0800*

>* #define FLT_MIN 1.17549435e-38
*>* I read up on this and this is the smallest unnormalized float: 2^-125.
*
Minor quibble: 1.18e-38 is approximately 2^-126.
>* 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.
*
Again, that should be 2^-126.
>* 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.
*
Makes sense.
>* 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...
*
It looks like there's a problem in the MLton basis library
implementation too. The regresion test displays reals using Real.fmt
StringCvt.EXACT. According to the basis spec, this is equivalent to
IEEEReal.toString o Real.toDecimal. The spec for Real.toDecimal says
that it "should produce only as many digits as are necessary for
fromDecimal to convert back to the same number". Since MLton
implements Real32.toDecimal by converting to a double, it is producing
too many digits for most floats. The only fix I see is to change
runtime/basis/Real/gdtoa.c to make Real32_gdtoa use the gdtoa library
directly modeled on g_ffmt, just as Real64_gdtoa uses the gdtoa
library modeled on g_dfmt. If we're in agreement, I'll do that after
applying your c99 patch.
With that fix, we still may have regression problems with the last
digit. If so, I think the right thing is to tweak the regression to
simply drop the last digit.