Dylan Thurston wrote: [snip] > > No. As has been pointed out, this is a bad idea numerically because > > it will give the wrong answer for sinh x for very small values of > > x. As a matter of fact, you will also get the wrong answer for very large > > values of x, where exp(x) can overflow even though sinh x and cosh x don't, > > meaning you get an incorrect answer of positive infinity. > > Err, what? Surely sinh x is at least 1/2 of exp x, leaving only a > very narrow range for this to happen. Behaviour of sinh x near 0 is > more important, unless I'm missing something? If we are planning to introduce bugs into the Haskell standard, I am not going to argue about which bug is more important than which other bug. Personally I think we should avoid all bugs. > > > I suggest saying as little about the transcendental functions as > > possible, rather than forcing incorrect rules on the implementor. > > The suggestions are for default methods, which force nothing on > anybody. They would be suggestions, in case anyone writes their own > instances of these classes; the question should be whether they are > useful suggestions. For instance, if you have a class of computable > reals (increasingly good approximations), the default definitions of > sinh and cosh are excellent. I would like to see such an implementation. The definition of sinh/cosh requires the number to be an instance of Floating, which requires Fractional, which requires Num, which requires Eq. Testing equality for computable reals is equivalent to solving the Turing Halting Problem, which would have wide-ranging applications for computer science . . .
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 . . . > > I don't think it's worth worrying about much. This is a good argument for leaving things as they are. [snip] _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell