Re: [Haskell-cafe] pi
My last word (promise!) on the subject, especially addressed to Jonathan Cast, who writes: To wit, I'm still failing to understand what your position is. I quote the Master: Lennart: 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. My position is: don't put rubbish into the Prelude! Swelling the standard environment with useless stuff has two consequences, it pollutes the name space, and slows down the learning process of the language, since many newbies will try to learn those useless quirks. So, no default, and no class membership. But, as LA says, we can live with, we have more important sorrows, all of us... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Thu, 2007-10-11 at 11:22 +0200, [EMAIL PROTECTED] wrote: My last word (promise!) on the subject, especially addressed to Jonathan Cast, who writes: To wit, I'm still failing to understand what your position is. I quote the Master: Lennart: 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. My position is: don't put rubbish into the Prelude! Swelling the standard environment with useless stuff has two consequences, it pollutes the name space, and slows down the learning process of the language, since many newbies will try to learn those useless quirks. So, no default, and no class membership. But, as LA says, we can live with, we have more important sorrows, all of us... Clear enough. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
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. If you need a specialized definition of pi in your instance, you would provide it, just as you do now. If pi makes no sense in your instance and you need it to be an error, you would define pi = error pi in your face, just as you do now. And in the most common case, you would do nothing, instead of redifining pi in the obvious way, as you need to do now. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
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. 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Wed, 10 Oct 2007, Yitzchak Gale wrote: 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. As the others have shown, you can compute PI in many ways. Which one is appropriate for the general case? Do you have so much types that you want to make instances of Floating, that manually defining 'pi' annoys you? Not giving a default implementation can even improve code because people have to think about a good implementation rather than relying on the default one. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Jules Bean writes: jerzy.karczmarczuk: 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. Are you aware that it already is in the Floating class? A very interesting question. What do you think: do I know it or not, in view of the preceding discussion? 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. 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. 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...) Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
[EMAIL PROTECTED] wrote: 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. Are you aware that it already is in the Floating class? 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? 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: \t - sin t -- polymorphic \t - sin (t*pi) -- monomorphic ? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
[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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Jules Bean said: 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. Maybe this is the wrong point of view, but I think of defaults as impementations that are meant to be correct, but not necessarily the best way of doing things, leaving you the option to provide something better. For the case of power series as an instance of Num, using 4*atan 1 gives me the wrong thing as it triggers an infinite summation, whereas I'd want pi to simply equal the constant power series. Now you could counter that by saying that power series are an esoteric case. But apart from code in the libraries, most code I've seen that provides an instance of Num is doing something mildly esoteric. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Wed, Oct 10, 2007 at 08:49:56AM -0700, Dan Piponi wrote: Jules Bean said: 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. Maybe this is the wrong point of view, but I think of defaults as impementations that are meant to be correct, but not necessarily the best way of doing things, leaving you the option to provide something better. For the case of power series as an instance of Num, using 4*atan 1 gives me the wrong thing as it triggers an infinite summation, whereas I'd want pi to simply equal the constant power series. Now you could counter that by saying that power series are an esoteric case. But apart from code in the libraries, most code I've seen that provides an instance of Num is doing something mildly esoteric. It sounds like what you're actually saying is atan is buggy in these cases, since it leads to an infinite summation. Programmers who define a buggy atan would certainly be punished by this default for pi, but those who recognize that there is no reason to define a buggy atan at all and leave it undefined would have the same result as when there is no default for pi. -- 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] pi
On 11 Oct 2007, at 4:49 am, Dan Piponi wrote: Maybe this is the wrong point of view, but I think of defaults as impementations that are meant to be correct, but not necessarily the best way of doing things, leaving you the option to provide something better. The example of tanh in the report (page 106) shows that this view cannot be sustained. As an algorithm for computing tanh, it cannot be defended, producing NaN in a vast range of cases where 1.0 is the easily obtained correct answer. For the case of power series as an instance of Num, using 4*atan 1 gives me the wrong thing as it triggers an infinite summation, whereas I'd want pi to simply equal the constant power series. So if you have a default for pi in Float, you still have to provide your own definition for power series. Without a default for pi, you have to provide your own definition for power series. It doesn't sound as though providing a default makes anything worse. One alternative would of course be to simply provide a definition with say 64 digits, to be rounded as appropriate by the compiler. That would be as accurate as 4*atan 1 for Float, Double, and Complex based on them, even for 128-bit floats. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Wed, 2007-10-10 at 10:40 +0200, [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...) pi /is/ a method of class Floating. It just doesn't have a default implementation. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Jonathan Cast adds 'something' to a discussion about pi. I commented the statement of Yitzchak Gale, who answered some point of Dan Piponi: A default implementation of pi would only increase usability, not decrease it. I said: 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...) pi /is/ a method of class Floating. It just doesn't have a default implementation. Now, do you have anything to propose, or you just want to criticise my wording? If I ask why should I be a nice fellow, and you say that I am a nice fellow, this makes me happy, but doesn't answer my question... Mind you, we are discussing possible solutions, not just the status quo. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Thu, 2007-10-11 at 02:11 +0200, [EMAIL PROTECTED] wrote: Jonathan Cast adds 'something' to a discussion about pi. I commented the statement of Yitzchak Gale, who answered some point of Dan Piponi: A default implementation of pi would only increase usability, not decrease it. I said: 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...) pi /is/ a method of class Floating. It just doesn't have a default implementation. Now, do you have anything to propose, or you just want to criticise my wording? 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'? If not, I can only beg for a precise, careful statement of exactly what it is you are arguing for. 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. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
jonathanccast: I just noticed that pi doesn't have a default definition in the standard prelude, according to the Haddock docs. Why is this? $ ghci Prelude :t pi pi :: (Floating a) = a Prelude pi 3.141592653589793 It's in the Floating class. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Jonathan Cast reacts to Don Stewart statement about PI: It's in the Floating class. Yes. But it doesn't have a default implementation. That strikes me as odd, considering the mathematical and actual correctness of class Floating sigma where pi = acos (-1) ... So, you assume that acos should have a *default* implementation in the Floating class? Propose it, please. Note, BTW that from the viewpoint of actual correctness, it would be better to have PI as exact as possible, while acos, well, it is a trans- cendental function, whose representations are usually approximate... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On 10/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So, you assume that acos should have a *default* implementation in the Floating class? Propose it, please. I don't think the proposal makes any such assumption. It implies only that *if* you provide acos, pi will be provided for you automatically if you want. Note, BTW that from the viewpoint of actual correctness, it would be better to have PI as exact as possible, while acos, well, it is a trans- cendental function, whose representations are usually approximate... pi is a transcendental number, same argument applies. I wouldn't want pi defined in terms of a transcendental function because people often use the Num type class to represent things that aren't actually numbers, eg. power series or ASTs for an embedded language. The reusability of Num varies inversely with how many assumptions you make about it. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Dan Piponi writes: jerzy.karczmarczuk wrote: So, you assume that acos should have a *default* implementation in the Floating class? Propose it, please. I don't think the proposal makes any such assumption. It implies only that *if* you provide acos, pi will be provided for you automatically if you want. Yes, sorry, I slipped... I was so against the acos(-1) /or atan(...)/ solution, that I wrote anything... Note, BTW that from the viewpoint of actual correctness, it would be better to have PI as exact as possible, while acos, well, it is a trans- cendental function, whose representations are usually approximate... pi is a transcendental number, same argument applies. No. There is a difference between one constant which can be represented with the maximum precision possible, and a procedure which necessarily uses some approximations, and whose local precision for some argument will be typically much lower than the machine one. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On 10/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yes, sorry, I slipped... I was so against the acos(-1) /or atan(...)/ solution, that I wrote anything... +1, Honest -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
