Re: [Haskell-cafe] Re: Why purely in haskell?
On Jan 15, 2008 12:29 AM, [EMAIL PROTECTED] wrote: Ben Franksen writes: [EMAIL PROTECTED] wrote: ... Does *MATH* answer the question what is: (0/0)==(0/0) ? Nope! Exactly. So why try to give an answer in Haskell? MATH says: the expression 0/0 is undefined, thus comparing (0/0)==(0/0) is undefined, too. I would expect Haskell to say the same. I don't know whether you are serious, or you are pulling my leg... Let's suppose that it is serious. When math says that something is undefined, in my little brain I understand that there is no answer. NO answer. I'm not sure if I'm agreeing or disagreeing with you here. Depends on exactly what you mean by no answer. When I was a TA for calculus 2, students were presented with something like the following problem: Find the limit: lim (sin x / x) x-0 And proceeding, they would reduce this to: sin 0 / 0 0 / 0 Look in the book that said 0/0 is undefined, and write undefined on the paper as if that were the answer. For the calculus uninclined (I figure that is a vast minority on this list), the answer is 1. In that case, undefined meant you did the problem wrong. And the error was precisely when they wrote 0 on the bottom of the division sign. To me, when math says undefined... let me stop there. Math doesn't say undefined. Instead, when mathematicians say undefined, they usually mean not that the question has no answer, but that the question you're asking doesn't even make sense as a question. For example, division is only defined when the denominator is not 0. Asking what the answer to 0/0 is is like asking what happens when I move the king across the board in chess?. That operation doesn't even make sense with those arguments. However, Haskell is not blessed (cursed?) with dependent types, so it is forced to answer such questions even though they don't make sense. But looking to math (at least with a classical interpretation of numbers) is just not going to work. Personally, I loathe the existence of NaN and +-Infinity in floating point types. Someone here made an enlightinging point encouraging us to think of floating point numbers not as numbers but as intervals. That makes me slightly more okay with the infinities, but NaN still bugs me. I'd prefer an error: Haskell's way of saying you did the problem wrong. That would be most useful in the kinds of things I do with floating point numbers (games). But there are probably other areas where the IEEE semantics are more useful. Well... that paragraph was just a long-winded way of saying I have an opinion, but I don't think it's very important Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Thu, 10 Jan 2008 19:38:07 +0200, Tillmann Rendel [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Prelude sum [1..100] *** Exception: stack overflow Not true in Hugs. Prelude Data.List.foldl' (+) 0 [1..100] 5050 Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 09:16:12 +0200, Lennart Augustsson [EMAIL PROTECTED] wrote: Thank you Duncan, you took the words out of my mouth. :) On Jan 10, 2008 5:42 PM, Duncan Coutts [EMAIL PROTECTED] wrote: So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n So you're suggesting that: ones == ones = True but ones' == ones' = _|_ Well if that were the case then it is distinguishing two equal values and hence breaking referential transparency. We can fairly trivially prove that ones and ones' are equal so == is not allowed to distinguish them. Fortunately it is impossible to write == above, at least using primitives within the language. If one can prove ones == ones = True with some method, why that method cannot be made to work on ones' ? Are you thinking about repeat (f x) by any chance ? Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Am Freitag, 11. Januar 2008 08:11 schrieb Lennart Augustsson: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). -- Lennart But class methods are expected to fulfill some axioms. I’d suppose that (==) should be an equivalence relation. Of course, this is not implementable because of infininte data structures. But one could relax the axioms such that it’s allowed for (==) to return _|_ instead of the expected value. Differentiating between data and codata would of course be the better solution. However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 09:11:52 +0200, Lennart Augustsson [EMAIL PROTECTED] wrote: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). I think that confusion came from the fact that the type of == is called (Eq a)= a - a - Bool and not (Bla a) = a - a - Binary and not realizing it's just an overloaded polimorphic function. Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. In my opinion it is the better than yielding True. 0/0 doesn't make sense. So it can't be compared to anything else which doesn't make sense. Whether == should yield False at all is another matter. It may be better to yield some kind of bottom (undefined?), but then compatibility with IEEE 754 might be an issue, hence using external libraries like BLAS, gmp, ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 09:11:52 +0200, Lennart Augustsson [EMAIL PROTECTED] wrote: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n (==) :: Eq a = a - a - Bool -- what is (y (y) ) by the way ? -- how about ( y id ) ? y f = f (y f). ones :: Num a = [a] ones = y (1 :) repeat :: a - [a] repeat = \n - y (n:) ones' :: Num a = [a] ones' = repeat 1 = (\n-y(n:)) 1 = y (1 : ) To be able to test them for equality, we must have Eq a. So, the reason we cannot test them for equality is that we cannot test y (a : ) == y (a : ) where a == a is testable. Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Jan 11, 2008 7:47 AM, Miguel Mitrofanov [EMAIL PROTECTED] wrote: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. Just for the record: the following is from Firebug (JavaScript debugger for Firefox) session: a = 0/0 NaN a == a false a === a false Another thing for the record: Goldberg says The introduction of NaNs can be confusing, because a NaN is never equal to any other number (including another NaN), so x = x is no longer always true. In fact, the expression x /= x is the simplest way to test for a NaN if the IEEE recommended function Isnan is not provided. Furthermore, NaNs are unordered with respect to all other numbers, so x = y cannot be defined as not x y. Since the introduction of NaNs causes floating-point numbers to become partially ordered, a compare function that returns one of , =, , or unordered can make it easier for the programmer to deal with comparisons. Goldberg, David. What Every Computer Scientist Should Know About Floating-Point Arithmetic. http://docs.sun.com/source/806-3568/ncg_goldberg.html . As GNU is not Unix, NaN is not a number, so what is standard about numbers doesn't work for them. I don't think there's a compeling reason about changing this behavior, specially because it's what's specified in the IEEE 754. However you can always define something like newtype NotADouble = N Double ... instance Eq NotADouble where N x == N y = (isNaN x isNaN y) || (x == y) ... -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. Just for the record: the following is from Firebug (JavaScript debugger for Firefox) session: a = 0/0 NaN a == a false a === a false ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
As GNU is not Unix, NaN is not a number, Since NaN /= NaN, I think, we should decipher NaN as Not a NaN instead. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Wolfgang Jeltsch [EMAIL PROTECTED] writes: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Achim Schneider wrote: The list instance for Eq might eg. know something about the structure of the lists and be smart enough not to get caught in the recursion of x = 1:1:x and y = 1:1:1:y so it could successfully compare x == y to True in six compares. This would not be something about the structure of lists This would be somethign about the structure of thunks. Thunks are not supposed to be observable. If you augment the language to make thunks observable and comparable, you will break referential transparency. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 13:29:35 +0200, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Freitag, 11. Januar 2008 10:54 schrieb Wilhelm B. Kloke: Wolfgang Jeltsch [EMAIL PROTECTED] schrieb: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn?t adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. You forget, that the intention of NaN is denial of membership of any set of numbers. This doesn’t matter. The Set data type I’m talking about would not know about NaN and would therefore allow multiple NaNs in a set. This is a good thing because one can define natural numbers with such sets :-) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Am Freitag, 11. Januar 2008 11:33 schrieben Sie: Wolfgang Jeltsch [EMAIL PROTECTED] writes: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. The IEEE floating point equivalence test has to yield false when comparing NaN with NaN. Haskell’s (==) has to yield True or undefined when comparing a value with itself. So Haskell’s (==) just has to be different from the IEEE floating point equivalence test. What about providing a separate function for the latter? As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) This would be far better (and far more Haskell-like). -k Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Am Freitag, 11. Januar 2008 10:54 schrieb Wilhelm B. Kloke: Wolfgang Jeltsch [EMAIL PROTECTED] schrieb: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn?t adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. You forget, that the intention of NaN is denial of membership of any set of numbers. This doesn’t matter. The Set data type I’m talking about would not know about NaN and would therefore allow multiple NaNs in a set. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Ketil Malde [EMAIL PROTECTED] writes: The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it. I'll expand a bit of this, after I've checked with Wikipedia. Please correct me (and it) if I'm wrong, but: 1) Intel CPUs generate exceptions, not NaNs (unless a NaN is already involved), so NaNs are introduced by choice in the run-time system. 2) IEE754 supports both 'signaling' and 'quiet' NaNs, so it seems the standard is not blessed in this regard. And, in Haskell, I'd consider using NaNs for missing values slightly abusive of the system, this is just a poor man's way of spelling Maybe Double. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 11 Jan 2008 14:21:45 +0200, [EMAIL PROTECTED] wrote: Ketil Malde: Wolfgang Jeltsch: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) People, you are monsters. First, despite the *common, well known* truth that Haskell is not Mathematics, this illusion seems to be extremely persistent! Haskell is a victim - no, some users are victims of its success as a formal language, not just as a coding tool... They *want* to have Eq as they imagine the equality, including the comparison between incomparable. This is BTW a long standing philosophical problem. For centuries some speculative guys tried to analyse such assertions as God == God, or death==death. Or myself==myself. Of course, even if they produced some cute conclusions, they had no whatsoever sense for the others. Now we have the modern variants of it: NaN == NaN, bottom == bottom ... Well, Haskell has this referential transparency thing which say that a function is a function and you will never be able to build anything else :-) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Wolfgang Jeltsch wrote: Am Freitag, 11. Januar 2008 11:33 schrieben Sie: Wolfgang Jeltsch [EMAIL PROTECTED] writes: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. The IEEE floating point equivalence test has to yield false when comparing NaN with NaN. Haskell’s (==) has to yield True or undefined when comparing a value with itself. So Haskell’s (==) just has to be different from the IEEE floating point equivalence test. What about providing a separate function for the latter? I wonder where the requirement on (==) you mention above is specified. I can't find it in the report but maybe I just overlooked it. OTOH, the report does say: The Ord class is used for totally ordered datatypes. IEEE comparisons are not a total ordering so in principle, they can't be used in the Ord methods. Also, comparing IEEE-like numbers for equality is practically always a mistake (the cases where it isn't are exceedingly rare) so the Eq instance for Float and Double doesn't actually provide any meaningful functionality. Anyway, having correct but inefficient implementations of Eq and Ord method for floating-point numbers sounds like a good idea to me, provided that the fast comparisons are still available. Personally, I'd be fine with not having those instances at all but that's just me, I guess. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) This would be far better (and far more Haskell-like). No, it would be far more Haskell-like not to use Float and Double (nor Int, for that matter) for things they shouldn't be used for. If all you want are fractions use Rational. Float and Double are (or should be) only for high-performance computations and people implementing those ought to know what they are doing. If they don't, they'll have much bigger problems than NaNs not being equal to themselves. BTW, some algorithms depend on silent NaNs and many depend on infinity. As an aside, I'd recommend http://citeseer.ist.psu.edu/goldberg91what.html as an introduction to some of the problems with floating point. The paper also talks about some uses for silent NaNs. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
That would give you a language with a semantics I don't want to touch. Sometimes useful, yes, but far to intensional for my taste. -- Lennart On Jan 11, 2008 5:59 AM, Achim Schneider [EMAIL PROTECTED] wrote: Yes, thanks. I actually do think that many things would be easier if every recursion would be translated to its fixpoint, making the term tree completely finite and defining y internal, as it's arcane, black magic. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] writes: The difference between you (and/or Wolfgang J.) and myself is that I enjoy more my freedom, even if I have to pay with a little more work. You want to enforce rigid reactions of the system. You should be free to do it on *your* machine, not on mine. You are putting words in my mouth! I do not want to enforce rigid reactions on the system, I want the option to enforce them on my programs. As I said, the exceptional treatment of exceptional values might be a compilation option, as it was in some Fortrans I used long time ago. *I* proposed a compile-time option, *you* responded that it is a blessing NOT to have it. You want your programs to react histerically to all difficulties in math, since you are afraid of propagating NaNs, etc. If you consider halting execution to be a hysterical reaction, arithmetic errors to be all difficulties in math, and wishing for accurate error messages to be afraid, I guess the answer is 'yes'. And *then* you will have to sit down and correct your code. If there is no exception, your program may run happily, and produce rubbish, yes? Yes. I am more conservative. If you are afraid of rubbish, protect your code by appropriate checks *before* the errors occur. I've written a bit of checking code in my time. The problem is that you quickly end up with more checking code than 'real' code, that the checking code paths are rarely used, and thus even more bug prone than the rest of the code, and that usually, there is little you can sensibly do other than halt execution anyway. The nice thing about checking for integer overflow and arithmetic exception is that they can be added with no cost in code size or complexity, and (at least on some architectures) no cost in performance - perhaps even improvements, for signaling NaNs. My Haskell programs tend to be rather Spartan, and I think this makes them more readable, and thus more likely to actually be correct. What you call a sabotage I.e. the insistence on wrap-around Ints (a minority use case!) and quiet NaNs as the One True Way, disallowing all other approaches. I call the programmers negligence. I'll pleade guilty to the charge of being negiligent and not checking intermediate results for errors and overflows. But the only reason for using Int (and not Integer) and arguably floating point, is performance. Wrapping everything in checks will be laborious, and I am fairly certain that performance will suffer by magnitudes. So yes, I am lazy, I use Int and cross my fingers. (I'm not alone; I've read a fair bit of Haskell code (starting with the Prelude), I must just have been unfortunate to miss all the code written by the industrious and serious people who actually check their Int operations...) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Jan 11, 2008 9:27 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn't adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. Here's another thing that makes me want to throw up. Prelude let nan :: Double = 0/0 Prelude compare nan nan GT Prelude nan nan False Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
If you talk to anyone who uses floating point numbers for real they would find (0/0)==(0/0) perfectly natural. It disobeys some axioms that Eq instances don't fulfill anyway, but changing it would make a lot of people surprised too. In general, the floating point instances break almost all axioms that you might think exist for numbers. -- Lennart On Jan 11, 2008 1:27 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Freitag, 11. Januar 2008 08:11 schrieb Lennart Augustsson: Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). -- Lennart But class methods are expected to fulfill some axioms. I'd suppose that (==) should be an equivalence relation. Of course, this is not implementable because of infininte data structures. But one could relax the axioms such that it's allowed for (==) to return _|_ instead of the expected value. Differentiating between data and codata would of course be the better solution. However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn't adhere to any meaningful axiom set for Eq. So I think that this behavior should be changed. Think of a set implementation which uses (==) to compare set elements for equality. The NaN behavior would break this implementation since it would allow for sets which contain NaN multiple times. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Am Freitag, 11. Januar 2008 13:21 schrieb [EMAIL PROTECTED]: Ketil Malde: Wolfgang Jeltsch: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) People, you are monsters. First, despite the *common, well known* truth that Haskell is not Mathematics, this illusion seems to be extremely persistent! Haskell is a victim - I was arguing from a software technology point of view: if (==) yields false when comparing a value with itself, this can break code (like a set implementation) which relies on certain guarantees. The fact that Haskell allows to define (==) rather arbitrarily doesn’t mean that the use of arbitrary definitions of (==) is what we want. It’s just that the language is to weak to express axioms. My impression is that staying close to math is good from a software technology point of view. And it has the advantage of less confusion for the user. […] Then, I see here, and on some other lists some tendency to speculate on the numerics by people who really don't need it, and don't use it. Even if I don’t use numerics, I do care about the Haskell language as a whole. […] I would suggest to Wolfgang Jeltsch a little more of reserve before making sharp categorical proposals concerning the fl. point computations (and also acknowledge that NaN is not a unique entity). It is easy to propose - in the name of purity to massacre existing structures; several religious sects and political doctrines were born in such a way. The result was usually horrible... I don’t see what’s so extreme about suggesting that IEEE floating point comparison should maybe be a seperate operator. And I think, it is really inappropriate to compare this to horrible sects and doctrines. Do you really want to argue that someone who insists on a rather clean language is dangerous? Than more or less everyone on this list would be dangerous—from a C programmer’s point of view. The Num hierarchy in Haskell is bad, we know it, especially for people who do some more formal mathematics. There are more interesting problems to solve than organising a crusade against IEEE, illegalizing the Ord instance for numbers, etc. Please don’t suggest that “illegalizing” some Ord instance is similar to killing people out of religious motives. Jerzy Karczmarczuk Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] writes: People, you are monsters. Well, bring on the torches and the pitchforks (although the image in my mind is more like a mob carrying lenses and bananas). no, some users are victims of its success as a formal language, not just as a coding tool I think Haskell's theoretical basis is part of its success as a coding tool. ... They *want* to have Eq as they imagine the equality, including the comparison between incomparable. In an ideal world, yes, but I think the monster to which you respond was fairly clear on being 'practical' here? The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it. I don't understand this. Are you worried users will edit the language pragmas in your code, and complain about NaN errors? Back when I *was* using the abbreviation FP for 'Floatin Point', I often got NaNs due to programming errors. Given the NaN's nature of contaminating subsequent results, getting an exception at the first occurrence would aid in tracking it down. - Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful for many purposes. ...and ditto for this. The usefulness of one case in no way justifies sabotagin all other cases. I'd wager Ints see wider use in settings where the silent 'mod' is harmful, than where this effect is desired. Again, the current behavior causes errors that are very hard to track down. IMHO, these are two very different types, and I'm sligtly baffled that the fact is not reflected in Haskell. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
The thing is that y already is a *builtin* function in Haskell. On Fri, 11 Jan 2008 15:59:50 +0200, Achim Schneider [EMAIL PROTECTED] wrote: Cristian Baboi [EMAIL PROTECTED] wrote: So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n (==) :: Eq a = a - a - Bool -- what is (y (y) ) by the way ? -- how about ( y id ) ? y f = f (y f). ones :: Num a = [a] ones = y (1 :) repeat :: a - [a] repeat = \n - y (n:) ones' :: Num a = [a] ones' = repeat 1 = (\n-y(n:)) 1 = y (1 : ) To be able to test them for equality, we must have Eq a. So, the reason we cannot test them for equality is that we cannot test y (a : ) == y (a : ) where a == a is testable. Yes, thanks. I actually do think that many things would be easier if every recursion would be translated to its fixpoint, making the term tree completely finite and defining y internal, as it's arcane, black magic. Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
If you can't stomach the weirdness of floating point then perhaps you should try to define your own type that obeys all the expected laws? :) On Jan 11, 2008 3:36 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Freitag, 11. Januar 2008 11:03 schrieb Felipe Lessa: Another thing for the record: Goldberg says The introduction of NaNs can be confusing, because a NaN is never equal to any other number (including another NaN), so x = x is no longer always true. In fact, the expression x /= x is the simplest way to test for a NaN if the IEEE recommended function Isnan is not provided. Furthermore, NaNs are unordered with respect to all other numbers, so x = y cannot be defined as not x y. Since the introduction of NaNs causes floating-point numbers to become partially ordered, a compare function that returns one of , =, , or unordered can make it easier for the programmer to deal with comparisons. Goldberg, David. What Every Computer Scientist Should Know About Floating-Point Arithmetic. http://docs.sun.com/source/806-3568/ncg_goldberg.html . As GNU is not Unix, NaN is not a number, so what is standard about numbers doesn't work for them. I don't think there's a compeling reason about changing this behavior, specially because it's what's specified in the IEEE 754. There is a really compelling reason: If the order on floating point numbers is partial then there is no meaningful Ord instance for them. And what do Hugs and GHCi say? Their answers are plain horror: Hugs, version 20050308: compare (0 / 0) (0 / 0) = EQ 0 / 0 == 0 / 0 = False GHCi 6.8.2: compare (0 / 0) (0 / 0) = GT 0 / 0 0 / 0 = False Anyone interested in filing bug reports? […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On 11 Jan 2008, at 5:13 AM, Achim Schneider wrote: Jonathan Cast [EMAIL PROTECTED] wrote: What kind of mathematics? I don't know of any mathematics where algebraic simplifications are employed without proof of the underlying equations (in some denotational model). Mathematics as, as my professor put it, Solving by staring. Professor of what? I would have been flunked for such an approach. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Jan 10, 2008 3:36 PM, Achim Schneider [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Niko Korhonen writes: ... Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. [1..] == [1..] , for assumed operational semantics of ones own axiomatic semantics. Bugs are only a misunderstanding away. It has nothing to do with laziness, but with using an algebraic function (==) with a codata structure (stream). If Haskell kept laziness but enforced separation of data and codata such code wouldn't compile. Lazy lists or streams never are a problem, but you can't (generically) fold codata. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. Best regards, Daniel Yokomizo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] wrote: Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Prelude sum [1..100] *** Exception: stack overflow Prelude Data.List.foldl' (+) 0 [1..100] 5050 Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
rendel: [EMAIL PROTECTED] wrote: Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Prelude sum [1..100] *** Exception: stack overflow Prelude Data.List.foldl' (+) 0 [1..100] 5050 See, http://hackage.haskell.org/trac/ghc/ticket/1997 Strictness for for atomic numeric types is inconsitently applied across the base library. Fixing the inconsitencies would let fix a range of similar issues. Note the strictness analyser handles this in compiled code, but doesn't run in ghci. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Thu, Jan 10, 2008 at 10:10:21AM -0800, Don Stewart wrote: rendel: [EMAIL PROTECTED] wrote: Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Prelude sum [1..100] *** Exception: stack overflow Prelude Data.List.foldl' (+) 0 [1..100] 5050 See, http://hackage.haskell.org/trac/ghc/ticket/1997 Strictness for for atomic numeric types is inconsitently applied across the base library. Fixing the inconsitencies would let fix a range of similar issues. Having followed this discussion, I agree with your analysis, but also think that rendel has chosen a good example of a pretty obscure bug caused by laziness in code written by folks who are actually decent Haskell programmers. It's unfortunate that there's no way to include strictness behavior in function types (at least that I'm aware of), so one has to rely on possibly-undocumented (and certainly never checked by a compiler) strictness behavior of many functions in order to write truly correct code. I wish there were a nice way around this issue (but can't really even imagine one). -- 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: Why purely in haskell?
Achim Schneider wrote: [1..] == [1..] [some discussion about the nontermination of this expression] The essence of laziness is to do the least work necessary to cause the desired effect, which is to see that the set of natural numbers equals the set of natural numbers, which, axiomatically, is always computable in O(1) by equality by identity. This would make sense if Haskell had inbuild equality and (==) where part of the formal semantics of Haskell, wich it isn't. (==) is a library function like every other library function. How could the language or a system implementing the language decide wether this or any other library function returns True without actually running it? Haskell is a programming language, not a theorem prover. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
G'day all. Quoting [EMAIL PROTECTED]: Perhaps another example is more relevant, the tradeoffs space-time in the optimized version of the powerset generator... Yeah, I was going to bring up that topic. I've been lazy programming for 15 or so years, and the only bugs that I can think of are: 1. Indirect black holes that are not expressible in a strict language. You generally have to be doing something bizarre for this to occur, and it doesn't take too long before you can accurately predict when they constitute a likely risk. 2. Space leaks. This is the one thing that really bites hard, because a space leak is a global property of a lazy program, and hence can't be reasoned about locally. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Jan 11, 2008 12:09 AM, [EMAIL PROTECTED] wrote: 1. Indirect black holes that are not expressible in a strict language. You generally have to be doing something bizarre for this to occur, and it doesn't take too long before you can accurately predict when they constitute a likely risk. What do you mean by black hole here? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
G'day all. Quoting Luke Palmer [EMAIL PROTECTED]: What do you mean by black hole here? A black hole is what happens when evalation of something recursively depends on its own evaluation in such a way that no useful work can be done. An example is: let omega = omega + 1 in omega In previous GHCs, that triggered am error which used the phrase black hole. Now, I think it just consumes the heap and/or stack. On my 2005-era Hugs, it causes a seg fault. Most examples of black holes aren't so blatant. In all cases, they are genuine bugs in the program (i.e. the program is incorrect), but programs containing bugs like this are not even expressible in a strict language. So I claim this is a class of (admittedly rare) bug that is only a problem because of laziness. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 2008-01-11 at 01:12 +0100, Achim Schneider wrote: Tillmann Rendel [EMAIL PROTECTED] wrote: Achim Schneider wrote: [1..] == [1..] [some discussion about the nontermination of this expression] The essence of laziness is to do the least work necessary to cause the desired effect, which is to see that the set of natural numbers equals the set of natural numbers, which, axiomatically, is always computable in O(1) by equality by identity. This would make sense if Haskell had inbuild equality and (==) where part of the formal semantics of Haskell, wich it isn't. (==) is a library function like every other library function. How could the language or a system implementing the language decide wether this or any other library function returns True without actually running it? The list instance for Eq might eg. know something about the structure of the lists and be smart enough not to get caught in the recursion of x = 1:1:x and y = 1:1:1:y so it could successfully compare x == y to True in six compares. So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n So you're suggesting that: ones == ones = True but ones' == ones' = _|_ Well if that were the case then it is distinguishing two equal values and hence breaking referential transparency. We can fairly trivially prove that ones and ones' are equal so == is not allowed to distinguish them. Fortunately it is impossible to write == above, at least using primitives within the language. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On 10 Jan 2008, at 7:55 AM, Achim Schneider wrote: Daniel Yokomizo [EMAIL PROTECTED] wrote: On Jan 10, 2008 3:36 PM, Achim Schneider [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Niko Korhonen writes: ... Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. [1..] == [1..] , for assumed operational semantics of ones own axiomatic semantics. Bugs are only a misunderstanding away. It has nothing to do with laziness, but with using an algebraic function (==) with a codata structure (stream). If Haskell kept laziness but enforced separation of data and codata such code wouldn't compile. Lazy lists or streams never are a problem, but you can't (generically) fold codata. Exactly. Denotationally it hasn't, but axiomatically it has. Because it looks like mathematical terms one can easily get lost in believing it reduces like mathematics, too. What kind of mathematics? I don't know of any mathematics where algebraic simplifications are employed without proof of the underlying equations (in some denotational model). jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Some people seem to think that == is an equality predicate. This is a big source of confusion for them; until they realize that == is just another function returning Bool they will make claims like [1..]==[1..] having an unnatural result. The == function is only vaguely related to the equality predicate in that it is meant to be a computable approximation of semantic equality (but since it's overloaded it can be anything, of course). -- Lennart On Jan 10, 2008 10:34 AM, [EMAIL PROTECTED] wrote: Achim Schneider: jerzy.karczmarczuk asks what's wrong with: [1..] == [1..] Whatever you may say more, this is neither obscure nor a bug. I still wait for a relevant example. But I don't insist too much... It's not an example of a bug, but of a cause. A cause of WHAT?? This is a perfect, nice, runaway computation, which agrees with all dogmas of my religion. Now, if somebody says that the fact that some people find it difficult to grasp the essence of laziness, and THIS is a source of bugs, I may believe. But not the laziness itself. (For some people the (==) operator seems to be a permanent source of bugs.) The difference between fold and stricter fold' won't convince me either. People who want to use laziness must simply read the documentation... On the other hand, what Don Stewart pointed out, the inconsistency between enumFrom and enumFromTo, and the difference of behaviours when one passes from Int to Integer, now, this is another story, worrying a little... Thanks. Perhaps another example is more relevant, the tradeoffs space-time in the optimized version of the powerset generator... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Thank you Duncan, you took the words out of my mouth. :) On Jan 10, 2008 5:42 PM, Duncan Coutts [EMAIL PROTECTED] wrote: On Fri, 2008-01-11 at 01:12 +0100, Achim Schneider wrote: Tillmann Rendel [EMAIL PROTECTED] wrote: Achim Schneider wrote: [1..] == [1..] [some discussion about the nontermination of this expression] The essence of laziness is to do the least work necessary to cause the desired effect, which is to see that the set of natural numbers equals the set of natural numbers, which, axiomatically, is always computable in O(1) by equality by identity. This would make sense if Haskell had inbuild equality and (==) where part of the formal semantics of Haskell, wich it isn't. (==) is a library function like every other library function. How could the language or a system implementing the language decide wether this or any other library function returns True without actually running it? The list instance for Eq might eg. know something about the structure of the lists and be smart enough not to get caught in the recursion of x = 1:1:x and y = 1:1:1:y so it could successfully compare x == y to True in six compares. So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n So you're suggesting that: ones == ones = True but ones' == ones' = _|_ Well if that were the case then it is distinguishing two equal values and hence breaking referential transparency. We can fairly trivially prove that ones and ones' are equal so == is not allowed to distinguish them. Fortunately it is impossible to write == above, at least using primitives within the language. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
