RE: Haskell 98 - Standard Prelude - Floating Class
Fpr the Revised Haskell 98 report, Russell O'Connor suggests: | Also, I understand you are reluctant to make library changes, | but sinh and cosh can easily be defined in terms of exp | | sinh x = (exp(x) - exp(-x))/2 | cosh x = (exp(x) + exp(-x))/2 | | (source: Calculus Third Edition by Michael Spivak, page 349, | or any decent calculus book) | | I suggest removing sinh and cosh from the minimal complete | definition, and add the above defaults. This looks pretty reasonable to me. We should have default methods for anything we can. Comments? Simon
Simon Peyton-Jones:
Russell O'Connor suggests:
| but sinh and cosh can easily be defined in terms of exp | | sinh x = (exp(x) - exp(-x))/2 | cosh x = (exp(x) + exp(-x))/2
| I suggest removing sinh and cosh from the minimal complete | definition, and add the above defaults.
This looks pretty reasonable to me. We should have default methods for anything we can.
Comments?
Three. 1. Actually, I wouldn't even call that "default definitions". These ARE definitions of sinh and cosh. 2. So, they hold for the Complex numbers as well. The gymnastics with complex sinh and cosh seems to be redundant. 3. The above code is less than useful for a person who really needs it. I would propose rather the most obvious sinh x = (u-recip u)/2 where u=exp x etc. Jerzy Karczmarczuk
----- Original Message ----- From: "Jerzy Karczmarczuk" <karczma@info.unicaen.fr> ...
Simon Peyton-Jones:
Russell O'Connor suggests:
| but sinh and cosh can easily be defined in terms of exp | | sinh x = (exp(x) - exp(-x))/2 | cosh x = (exp(x) + exp(-x))/2
| I suggest removing sinh and cosh from the minimal complete | definition, and add the above defaults.
This looks pretty reasonable to me. We should have default methods for anything we can.
Comments?
Three.
1. Actually, I wouldn't even call that "default definitions". These ARE definitions of sinh and cosh.
Mathematically, yes. Numerically, no. Even if 'exp' is implemented with high accuracy, the suggested defaults may return a very inaccurate (in ulps) result. Take sinh near zero. sinh(x) with x very close to 0 should return x. With the above 'default' sinh(x) will return exactly 0 for a relatively wide interval around 0, which is the wrong result except for 0 itself. In general, this is why LIA-2 (Language Independent Arithmetic, part 2, "Elementary numerical functions", ISO/IEC 10967-2:2001) rarely attempts to define one numerical operation in terms of other numerical operations. That is done only when the relationship is exact (even if the operations themselves are inexact). That is not the case for the abovementioned operations. But it is the case for the relationship between the complex sin operation and the complex sinh operation, for instance. (Complex will be covered by LIA-3.) Kind regards /Kent Karlsson
participants (3)
-
Jerzy Karczmarczuk -
Kent Karlsson -
Simon Peyton-Jones