Standard Prelude - Floating Class

[George Russell]

I wrote
> I'm afraid that I have very little faith in the numerical analysis
> expertise of the typical Haskell implementor, so I think it is dangerous
> to give them an incorrect "default" implementation.  I am reminded of
> the notorious ASCII C (very)-pseudo-random number generator . . .
Dylan wrote
> > I don't think it's worth worrying about much.
I wrote
> This is a good argument for leaving things as they are.
Jerzy Karczmarczuk wrote
> Absolutely NO. Unless you don't care at all about the potential scientific 
> users of the language. Leaving the details which are of utmost importance for
> professional applications is killing the language. Most  readers of this forum
> are very far away from numerics, and this is normal. But languages live through
> their libraries. At least 4 times a year somebody on this list complains about
> lack of such a support even if the actual libraries are already quite
> impressive.
The potential scientific users of the language are not going to be well served
if the language includes *incorrect* implementations of mathematical functions.
This is my point.
> 
> So, I would encourage to organize one day a group - not necessarily a "task
> force"
> like the GUI people - of people who would test all the numerics, and at least
> give to the freshmen some implementation prototypes, e.g. Padés for small
> arguments
> of sinh, etc
Yes, in the ideal world, we would form a group of numerically-knowledgable
Haskell people who would test things out properly.  Well, perhaps.  I would
like to be on this group.  I at least know what a Pad'e approximation is, and
perhaps I could even remember how you find them.  I have implemented sinh
properly in ML based on the netlib specification.  Still, I am not a numerical
analyst, and I am not sure we are going to be able to find it easy to assemble
a group of numerical analysts willing to give time to define the transcendental
functions properly.  I also doubt if this is going to be possible.  At the moment
for example, Haskell cannot even require IEEE arithmetic, because virtually no
platform supports it completely.  (Intel has too much precision which needs to
be artificially clobbered if we want IEEE, Alpha doesn't do underflows properly
unless you are very careful with inserting traps to fix things up.)  So getting
a standard which specifies exactly what Haskell transcendental functions should
do (be accurate within 0.8ULP for example, though when you think about it that
is horrendously complicated to guarantee in some instances . . .) is going to
be tricky, to say the least.
> 
> And what is this: "typical Haskell implementor"? Do you know many of them? Do
> you
> think really that some fellow totally inconscious in the domain of STANDARD
> numeric
> maths, somebody who never heard about IEEE etc. will NOW engage in implementing
> Haskell? What is the rationale behind your little faith, Man of Little Faith?
I think numerical analysis is a prime example of "A little learning is a dangerous
thing".  I think I would like a Haskell implementor to be either totally ignorant
of numerical analysis, and simply call out to C routines written by an expert,
such as the excellent ones available at netlib.  Or else a Haskell implementor should 
be a skilled numerical analyst.  Unfortunately expecting writers of functional 
compilers to be an s.n.a. seems to me rather like expecting them to be brain surgeons; 
it just isn't so.  On the other hand, they have enough mathematical learning
to know about sinh(x)=(exp(x)-exp(-x))/2, so they erroneously introduce it into their
code, having forgotten whatever they learnt in bright college days about never
subtracting two nearly-equal floating-point numbers.  Standard ML/NJ and Microsoft
Excel (when I tested it a couple of years ago) both get sinh wrong, so I think my
pessimism is well-grounded.

Incidentally, another fruitful example of ALLIADT is random number generators.  I have
yet to see a language standard which defined a random number generator which wasn't
completely pathetic.