[Haskell-cafe] Re: pi
On 2007-10-11, Jonathan Cast [EMAIL PROTECTED] wrote: Yes. I am very eager to criticize your wording. To wit, I'm still failing to understand what your position is. Is it fair to say that your answer to my question, why pi has no default implementation, is `in fact, pi shouldn't be a method of Floating anyway'? That was how I was reading him. Btw: I am arguing that I (still) don't understand why the line pi = acos (-1) or something like it doesn't appear at an appropriate point in the Standard Prelude, given that the line pi :: a appears nearby said point. I am eager to be enlightened. But I haven't been, yet. You would have to ask the committee. But I think it's a bad idea to have such a default (or 4 * atan 1, or ...) because of calculational issues. It's not a useful default, except for toy uses. Yeah, it works fine for float and double on hardware with FPUs. But I want to be told that I haven't implemented it, rather than it getting a really awful default. Most of the defaulting in other classes are minor wrappers, such as converting between (=) and compare, not actual algorithmic implementations, which can pull in strongly less efficient implementations. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Thu, 2007-10-11 at 07:57 +, Aaron Denney wrote: On 2007-10-11, Jonathan Cast [EMAIL PROTECTED] wrote: Yes. I am very eager to criticize your wording. To wit, I'm still failing to understand what your position is. Is it fair to say that your answer to my question, why pi has no default implementation, is `in fact, pi shouldn't be a method of Floating anyway'? That was how I was reading him. Btw: I am arguing that I (still) don't understand why the line pi = acos (-1) or something like it doesn't appear at an appropriate point in the Standard Prelude, given that the line pi :: a appears nearby said point. I am eager to be enlightened. But I haven't been, yet. You would have to ask the committee. But I think it's a bad idea to have such a default (or 4 * atan 1, or ...) because of calculational issues. It's not a useful default, except for toy uses. Yeah, it works fine for float and double on hardware with FPUs. But I want to be told that I haven't implemented it, rather than it getting a really awful default. Most of the defaulting in other classes are minor wrappers, such as converting between (=) and compare, not actual algorithmic implementations, which can pull in strongly less efficient implementations. Fair enough. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
[EMAIL PROTECTED] wrote: Yitzchak Gale writes: Dan Piponi wrote: The reusability of Num varies inversely with how many assumptions you make about it. A default implementation of pi would only increase usability, not decrease it. Suppose I believe you. (Actually, I am afraid, I have doubts.) Can you provide some examples of this increased usability? If possible, with a *relevant* context, which shows that PI should belong by default to the class Floating (whatever we mean by that...) Somehow I do not only think that the default implementation would be good for nothing, but that putting PI into Floating as a class member, serves nobody. Putting 'pi' in the same class as the trigonometric functions is good design. I would be happy to learn that I am mistaken, but if it is just to save 5 seconds of a person who wants to pass smoothly between floating numbers of single and double precision... Jerzy Karczmarczuk Moving smoothly from single to double precision was much of the motivation to invent a mechanism like type classes in the first place. There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. And I would bet that some of the custom mathematical prelude replacements do this. If you do not want 'pi' in a class named Floating then you have to move all the transcendental stuff with it. If you do not want 'pi' in any class, then you cannot reasonably put any of the transcendental functions in a class. This would really degrade the API. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
ChrisK writes: Putting 'pi' in the same class as the trigonometric functions is good design. If you wish so... But: Look, this is just a numeric constant. Would you like to have e, the Euler's constant, etc., as well, polluting the name space? What for? Moving smoothly from single to double precision was much of the motivation to invent a mechanism like type classes in the first place. Pardon? I think I remember the time when type classes have been introduced. The motivation you mention is not very visible, if at all... Actually, the numerical hierarchy was - as the French would say - bricolée with plenty of common sense, but without a decent methodology... The type classes is a splendid invention, much beyond any numerics. Besides, most people who *really* need FlP numerics use only the most precise available, the single precision stuff is becoming obsolete. There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... If you do not want 'pi' in a class named Floating then you have to move all the transcendental stuff with it. I would survive without moving anything anywhere, I assure you. If you do not want 'pi' in any class, then you cannot reasonably put any of the transcendental functions in a class. This would really degrade the API. What?? But it is just a numerical constant, no need to put it into a class, and nothing to do with the type_classing of related functions. e is not std. defined, and it doesn't kill people who use exponentials. Jerzy Karczmarczuk PS. One of the US Army folklore slogans say: if it's ain't broken, don't fix it. I would say: if what you need is one good exemplar, don't overload it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
On 2007-10-10, [EMAIL PROTECTED] wrote: ChrisK writes: Putting 'pi' in the same class as the trigonometric functions is good design. If you wish so... But: Look, this is just a numeric constant. Would you like to have e, the Euler's constant, etc., as well, polluting the name space? What for? It's there in the form (exp 1), after all. Yeah, you can get pi from (log i), but the multi-valuedness is annoying. Not an issue with exp. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... Yes, this is an issue. I wish there were a serious plan for reworking the numeric hierarchy for Haskell', but no one seems to interested. I've thought about writing something up, but with it not entirely clear what subset of MPTCs, FunDeps, and ATs will be in, that makes a design a bit trickier. class Exponential a where (^) :: (Integral b) = a - b - a What?? But it is just a numerical constant, no need to put it into a class, and nothing to do with the type_classing of related functions. e is not std. defined, and it doesn't kill people who use exponentials. As I said above, it effectively is. And, after all, 1, 2, 3, are constants of the typeclass Integral a = a, and 0.0, 1.348, 2.579, 3.7, etc. are in Floating a = a. So why not pi? -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
On 2007-10-10, [EMAIL PROTECTED] wrote: Oh yes, everybody in the world uses in ONE program several overloaded versions of pi, of the sine function, etc. They don't have to be in the same program for overloaded versions to be semantically useful. They're not strictly necessary, but so? Having different programs use compatible conventions really is a win. 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...) Oh, just about never. But the defaults are the issue, not the simultaneously overloaded pi and trig functions. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, Oct 10, 2007 at 12:29:07PM +0200, [EMAIL PROTECTED] wrote: ChrisK writes: There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... I suppose you're unfamiliar with the (^) operator, which does what you describe? It seems that you're arguing that (**) is placed in the correct class, since it's with the transcendental functions, and is implemented in terms of those transcendental functions. Where is the abomination here? -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
David Roundy wrote: On Wed, Oct 10, 2007 at 12:29:07PM +0200, [EMAIL PROTECTED] wrote: ChrisK writes: There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... I suppose you're unfamiliar with the (^) operator, which does what you describe? and (^^) which allows even negative integer exponents (at the price of requiring it to be possible to take the reciprocal of the base type) Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, 10 Oct 2007, David Roundy wrote: On Wed, Oct 10, 2007 at 12:29:07PM +0200, [EMAIL PROTECTED] wrote: ChrisK writes: There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... I suppose you're unfamiliar with the (^) operator, which does what you describe? It seems that you're arguing that (**) is placed in the correct class, since it's with the transcendental functions, and is implemented in terms of those transcendental functions. Where is the abomination here? (**) should not exist, because there is no sensible definition for many operands for real numbers, and it becomes even worse for complex numbers. The more general the exponent, the more restricted is the basis and vice versa in order to get sound definitions. http://www.haskell.org/pipermail/haskell-cafe/2006-April/015329.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, 10 Oct 2007, Henning Thielemann wrote: (**) should not exist, because there is no sensible definition for many operands for real numbers, and it becomes even worse for complex numbers. The more general the exponent, the more restricted is the basis and vice versa in order to get sound definitions. http://www.haskell.org/pipermail/haskell-cafe/2006-April/015329.html I've put it on the Wiki: http://www.haskell.org/haskellwiki/Power_function ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, Oct 10, 2007 at 08:53:22PM +0200, Henning Thielemann wrote: On Wed, 10 Oct 2007, David Roundy wrote: It seems that you're arguing that (**) is placed in the correct class, since it's with the transcendental functions, and is implemented in terms of those transcendental functions. Where is the abomination here? (**) should not exist, because there is no sensible definition for many operands for real numbers, and it becomes even worse for complex numbers. The more general the exponent, the more restricted is the basis and vice versa in order to get sound definitions. Would you also prefer to eliminate sqrt and log? We've been using these functions for years (in other languages) without difficulty, and I don't see why this has changed. I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, 10 Oct 2007, David Roundy wrote: On Wed, Oct 10, 2007 at 08:53:22PM +0200, Henning Thielemann wrote: On Wed, 10 Oct 2007, David Roundy wrote: It seems that you're arguing that (**) is placed in the correct class, since it's with the transcendental functions, and is implemented in terms of those transcendental functions. Where is the abomination here? (**) should not exist, because there is no sensible definition for many operands for real numbers, and it becomes even worse for complex numbers. The more general the exponent, the more restricted is the basis and vice versa in order to get sound definitions. Would you also prefer to eliminate sqrt and log? No, why? We've been using these functions for years (in other languages) without difficulty, and I don't see why this has changed. You mentioned these functions - not me. I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. It would better to disallow negative bases completely for (**), because integers should be explicitly typed as integers and then (^^) can be used. I have already seen (x**2) and (e ** x) with (e = exp 1) in a Haskell library. Even better would be support for statically checked non-negative numbers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
Henning Thielemann wrote: It would better to disallow negative bases completely for (**), because integers should be explicitly typed as integers and then (^^) can be used. I have already seen (x**2) and (e ** x) with (e = exp 1) in a Haskell library. Even better would be support for statically checked non-negative numbers. Um... Data.Word? (Now if you'd said strictly positive, that's harder...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
David Roundy: jerzy.karczmarczuk: The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... I suppose you're unfamiliar with the (^) operator, which does what you describe? Sorry for being imprecise. I know (^), certainly, I wanted to suggest that the power should THEN belong to Num; if a multiplication is defined, surely the integer power as well, although this is somewhat delicate, since (*) defines a semi-group. That's why (^) for negative exponent, yells. And that's why we have also (^^) for Fractionals, which calls recip for the negative exponent. ... Where is the abomination here? Having THREE different power operators, one as a class member, others as normal functions. Do you think this is methodologically sane? === Other message: Would you also prefer to eliminate sqrt and log? We've been using these functions for years (in other languages)... I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. As you wish. But, since this is an overloaded class member, making it sensitive to the exponent being integer or not, is awkward. And perhaps I would *like* to see the result being complex, non NaN? Oh, you will say that it would break the typing. NaN also does it, in a sense. And this suggests that the type a-a-a is perhaps a wrong choice. Of course, this implies a similar criticism of log and sqrt... (One of my friends embeds the results of his functions in a generalization of Maybe [with different Nothings for different disasters], and a numerical result, if available, is always sound.) I am not sure whether Henning's ideas convince me entirely, and his statement In mathematical notation we don't respect types seems to be perhaps too strong (unless 'notation' means just the notation, which doesn't respect anything), but the relation between mathematical domains and the type system should one day be sanitized. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, Oct 10, 2007 at 10:32:55PM +0200, Henning Thielemann wrote: On Wed, 10 Oct 2007, David Roundy wrote: I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. It would better to disallow negative bases completely for (**), because integers should be explicitly typed as integers and then (^^) can be used. I have already seen (x**2) and (e ** x) with (e = exp 1) in a Haskell library. Even better would be support for statically checked non-negative numbers. I agree. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, Oct 10, 2007 at 10:52:36PM +0200, [EMAIL PROTECTED] wrote: ... Where is the abomination here? Having THREE different power operators, one as a class member, others as normal functions. Do you think this is methodologically sane? It's a bit odd, but I prefer it to having one hyper-overloaded power operator that you hope will be efficient for small integer arguments. I suppose if I designed the hierarchy I'd probably have two power operators, both as class members. But then again, this would slow down some code, and it'd be nice to avoid that. Would you also prefer to eliminate sqrt and log? We've been using these functions for years (in other languages)... I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. As you wish. But, since this is an overloaded class member, making it sensitive to the exponent being integer or not, is awkward. And perhaps I would *like* to see the result being complex, non NaN? Oh, you will say that it would break the typing. NaN also does it, in a sense. And this suggests that the type a-a-a is perhaps a wrong choice. Of course, this implies a similar criticism of log and sqrt... (One of my friends embeds the results of his functions in a generalization of Maybe [with different Nothings for different disasters], and a numerical result, if available, is always sound.) There are certainly other options, but the only fast option that I'm aware of is to use IEEE floating point arithmetic (or rather, the approximation thereof which is provided by modern CPUs). It's awkward treating things specially based on whether the argument is an integer, but also provides a rather dramatic optimization for those who don't know it's better to use (^) or (^^). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
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?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
Someone wrote about pi: | But it is just a numerical constant, no need to put it into a class, and nothing to do with the type_classing of related functions. e is not std. defined, and it doesn't kill people who use exponentials. But it *isn't* A numerical constant. It is a *different* constant for each instance of Floating. In this respect, it's not unlike floatRange, which is just a constant (a pair of integers), but is different for each RealFloat instance. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, 2007-10-10 at 12:29 +0200, [EMAIL PROTECTED] wrote: ChrisK writes: Putting 'pi' in the same class as the trigonometric functions is good design. If you wish so... But: Look, this is just a numeric constant. Would you like to have e, the Euler's constant, etc., as well, polluting the name space? What for? Moving smoothly from single to double precision was much of the motivation to invent a mechanism like type classes in the first place. Pardon? I think I remember the time when type classes have been introduced. The motivation you mention is not very visible, if at all... Actually, the numerical hierarchy was - as the French would say - bricolée with plenty of common sense, but without a decent methodology... The type classes is a splendid invention, much beyond any numerics. Besides, most people who *really* need FlP numerics use only the most precise available, the single precision stuff is becoming obsolete. There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... Check out the type of (^). It's a different operator, but they exist... jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
David Benbennick wrote: On 10/10/07, Dan Weston [EMAIL PROTECTED] wrote: Actually, it is a constant: piDecimalExpansion :: String. Where is this constant defined? A translation from piDecimalExpansion :: String to pi :: Floating a = a is already well defined via read :: Read a = String - a Any definition of pi in the Floating class that differs from (read piDecimalExpansion) is erroneous. I propose the above as the default definition of pi. piDecimalExpansion, if defined, would be an infinite length string. It would need to be added. The fact that it has infinite length is no problem. It is countable infinite, and algorithms exist to compute this lazily. The expression read $ 0. ++ repeat '1' :: Double is Bottom. So even if you had piDecimalExpansion, it isn't clear how to use that to define pi. Ouch. Why is that bottom? Any finite dense numeric type can depend on only a finite number of digits. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On 10/10/07, Dan Weston [EMAIL PROTECTED] wrote: Actually, it is a constant: piDecimalExpansion :: String. Where is this constant defined? A translation from piDecimalExpansion :: String to pi :: Floating a = a is already well defined via read :: Read a = String - a Any definition of pi in the Floating class that differs from (read piDecimalExpansion) is erroneous. I propose the above as the default definition of pi. piDecimalExpansion, if defined, would be an infinite length string. The expression read $ 0. ++ repeat '1' :: Double is Bottom. So even if you had piDecimalExpansion, it isn't clear how to use that to define pi. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On 11 Oct 2007, at 1:34 pm, Dan Weston wrote: Actually, [pi] is a constant: piDecimalExpansion :: String. No, that's another constant. A translation from piDecimalExpansion :: String to pi :: Floating a = a is already well defined via read :: Read a = String - a Wrong. piDecimalExpansion would be infinite. pi is, after all, a transcendental number. It can be computed incrementally by a finite algorithm, true. The problem is that read has to read *all the way to the end*, and there is no end. (More precisely, either to the end of the string or to the first character that is not part of a floating point literal.) Any definition of pi in the Floating class that differs from (read piDecimalExpansion) is erroneous. In effect, you are proposing that the only non-erroneous definition of pi is bottom. I don't think that is very helpful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
Come on people! This discussion is absurd. The numeric classes in Haskell have a lot of choices that are somewhat arbitrary. Just live with it. If pi has a default or not has no practical consequences. -- Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
