[EMAIL PROTECTED] wrote:
This discussion is not about adding it, but about whether or not it
should have a default.
Are you suggesting pi should be removed from the Floating class?
Then, what type would you give pi?
First, I don't care whether it is there or not. When I use it, I define
a particular instance (double, a constant formal series, a constant element
of some differential algebra I enjoy personally, etc. No default would
help me anyway).
And then, I give it the type it deserves.
Evidently you use pi in more 'serious' programs than I do. I use pi
simply for geometric reasons, when I wish to specify circular or
elliptic paths or similar constructions. For this I am pleased that the
language libraries give me pi, because they save me the work of defining it.
Given that pi is often used with sin, as in "sin (t * pi)" it would
seem very odd if pi forced that to be monomorphic:
Oh yes, everybody in the world uses in ONE program several overloaded
versions of pi, of the sine function, etc. Well, perhaps not everybody,
for example I don't. And I use numerics quite often.
I like to write a complex function which might use multiple trig
functions and pi, to describe the kind of thing about. I might want to
use that function at Double, or GLdouble, or GLfloat, for various
reasons. I don't particularly want to have to think about that kind of
thing more than I have to.
How often *you* needed simultaneously overloaded pi and trigs in such a way
that a default could help you? Answer sincerely (if you wish to answer at
all...)
The default wouldn't help me at all. The default would help a (putative)
designer of a new Floating instance, and I have never been one of those.
If it is true of many Floating instances that (atan 1 * 4) is an
accurate way to calculate pi (and it appears to be 'accurate enough' for
Float and Double, on my computer) then adding it as a default doesn't
appear to do any harm.
I can't say I think it's very important either.
Jules
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
