[MLton-user] Re: MLton-user digest, Vol 1 #117 - 2 msgs

[Stephen Weeks]

> > The issue with many of the floating point operations is that the
> > Standard ML Basis Library (www.standardml.org/Basis) is quite
> > specific on the behavior of these operations when the arguments are
> > INF, NAN, etc.  Unfortunately, the math libraries for C often do not
> > match the semantics required by the Basis, so we resort to
> > specifically querying the class of the arguments and behave
> > accordingly.
> 
> Actually, I don't believe that this claim is true. When designing
> the semantics of the floating-point and Math library functions, we
> followed the C floating-point standard fairly closely (which has
> since been rolled into the C99 specification).  Are there specific
> examples where the specifications diverge?

I don't know about that, but Matthew's claim was about the behavior of
actual C libraries, not the C spec.  In our regression testing as
we've ported MLton to new platforms, we've encountered many places
where C math libraries don't agree with the SML spec.

Looking at our latest sources implementing the Real<N> structures:

  http://mlton.org/cgi-bin/viewsvn.cgi/mlton/trunk/basis-library/real/real.fun?rev=4078&view=markup

I see several comments indicating that either C libraries or processor
instructions don't get various things right.  Here are the functions
indicated.

  Real.split
  Real.Math.{acos,asin,exp,ln,log10,pow}

I suspect that there are many more problematic functions that aren't
commented, but for which I see explicit calls to Real.class.