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.