[Haskell-cafe] Re: pi
ok
ok at cs.otago.ac.nz
Wed Oct 10 19:07:48 EDT 2007
Let's be clear what we are talking about, because I for one am
getting very confused by talk about "putting PI into FLoating as
a class member serves nobody" when it already IS there.
From the report:
class (Fractional a) => Floating a where
pi :: a
exp, log, sqrt :: a -> a
(**), logBase :: a -> a -> a
sin, cos, tan :: a -> a
asin, acos, atan :: a -> a
sinh, cosh, tanh :: a -> a
asinh, acosh, atanh :: a -> a
-- Minimal complete definition:
-- pi, exp, log, sin, cos, sinh, cosh
-- asin, acos, atan
-- asinh, acosh, atanh
x ** y = exp (log x * y)
logBase x y = log y / log x
sqrt x = x ** 0.5
tan x = sin x / cos x
tanh x = sinh x / cosh x
(1) Mathematically,
sinh x = (exp x - exp (negate x)) / 2
cosh x = (exp x + exp (negate x)) / 2
tanh x = sinh x / cosh x
for all types where exp is defined. It is most peculiar that
one of these definitions is provided as a default rule but the
other two not. Does anyone know why there are no default
definitions for sinh and cosh? Do not cite numerical accuracy
as a reason. sinh 1000 = cosh 1000 = +Infinity in IEEE
arithmetic, so the default definition gives tanh 1000 = NaN,
when for abs x >= {- about -} 41, tanh x = 1.0 (in IEEE 64-bit).
Is it something to do with branch cuts? Then Complex is the
right place to put overriding defaults that get them right.
(2) Other omissions can mostly be understood by thinking about
Complex. I find it deeply regrettable that atan2 isn't there,
because asin, acos, and atan are almost always the wrong
functions to use. But atan2 doesn't make sense for Complex.
(If someone could prove me wrong I would be delighted.)
(3) The question before us is whether there should be a default
definition for pi, and if so, what it should be.
I note that in at least one version of Hugs, there *is* a
default definition, namely
pi = 4 * atan 1
So we have evidence that one *can* have a default definition in
Floating without a plague of boils striking the blasphemers.
Unlike a numeric literal, this automatically adapts to the size
of the numbers. It may well not be as precise as a numeric
literal could be, but then, the report is explicit that defaults
can be overridden with more accurate versions.
None of the reasons for omitting other defaults seem to apply,
and providing a default for pi would not seem to do any harm.
So why not provide a default for pi?
More information about the Haskell-Cafe
mailing list