Re: [Haskell-cafe] 0/0 1 == False
Hi! On Jan 11, 2008 7:30 AM, Cristian Baboi [EMAIL PROTECTED] wrote: NaN is not 'undefined' Why not? What is a semantic difference? I believe Haskell should use undefined instead of NaN for all operations which are mathematically undefined (like 0/0). NaN should be used in a languages which does not support such nice Haskell features. Because if Haskell would use undefined such error would propagate itself to higher levels of computations, with NaN it does not. if bigComputation 1 then ... else ... Would be evaluating else semantically correct if bigComputation returns NaN? No, it is not. With undefined this is correctly (not)evaluated. Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 2008-01-17 at 03:16 +0100, Mitar wrote: Hi! On Jan 11, 2008 7:30 AM, Cristian Baboi [EMAIL PROTECTED] wrote: NaN is not 'undefined' Why not? What is a semantic difference? I believe Haskell should use undefined instead of NaN for all operations which are mathematically undefined (like 0/0). NaN should be used in a languages which does not support such nice Haskell features. Because if Haskell would use undefined such error would propagate itself to higher levels of computations, with NaN it does not. if bigComputation 1 then ... else ... Would be evaluating else semantically correct if bigComputation returns NaN? No, it is not. With undefined this is correctly (not)evaluated. For the love of Pete, floating point numbers are not real numbers. 0/0 is mathematically defined for floating point numbers to be NaN. If you don't want to use IEEE floating point numbers, use a different type as was suggested early in this thread. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Jan 16, 2008 11:30 PM, Derek Elkins [EMAIL PROTECTED] wrote:
For the love of Pete, floating point numbers are not real numbers. 0/0
is mathematically defined for floating point numbers to be NaN. If you
don't want to use IEEE floating point numbers, use a different type as
was suggested early in this thread.
In fact, you can be happy just by using Rational
Prelude 0/0 :: Rational
*** Exception: Ratio.%: zero denominator
or creating a newtype
newtype ZeroUndef a = Z {unZ :: a}
instance Eq a = Eq (ZeroUndef a) where
Z a == Z b = a == b
Z a /= Z b = a /= b
instance Show a = Show (ZeroUndef a) where
...
instance Num a = Num (ZeroUndef a) where
...
instance Fractional a = Fractional (ZeroUndef a) where
...
Z a / Z 0 = error ...
Z a / Z b = Z (a / b)
so that ZeroUndef Double, ZeroUndef Float, ZeroUndef Matrix and all
friends do work like you want.
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 0/0 1 == False
Hi! Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 10 Jan 2008 10:22:03 +0200, Mitar [EMAIL PROTECTED] wrote: Hi! Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? Mitar I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) 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] 0/0 1 == False
Hi Mitar, On Jan 10, 2008 9:22 AM, Mitar [EMAIL PROTECTED] wrote: I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. My understanding is that common mathematical practice is that comparing an undefined value to anything (including itself) always yields false; x /= x is sometimes used to formalize x is undefined. If you have access to JSTOR, this article contains an overview of different fields' perspectives on dealing with undefinedness: http://links.jstor.org/sici?sici=0022-4812(199009)55%3A3%3C1269%3AAPFVOC%3E2.0.CO%3B2-T - Benja ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 10 Jan 2008 10:48:51 +0200, Benja Fallenstein [EMAIL PROTECTED] wrote: Hi Mitar, On Jan 10, 2008 9:22 AM, Mitar [EMAIL PROTECTED] wrote: I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. My understanding is that common mathematical practice is that comparing an undefined value to anything (including itself) always yields false; x /= x is sometimes used to formalize x is undefined. Why let a = a in a /= a is not False ? 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] 0/0 1 == False
On Thu, 10 Jan 2008 10:48:51 +0200, Benja Fallenstein [EMAIL PROTECTED] wrote: Hi Mitar, On Jan 10, 2008 9:22 AM, Mitar [EMAIL PROTECTED] wrote: I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. My understanding is that common mathematical practice is that comparing an undefined value to anything (including itself) always yields false; x /= x is sometimes used to formalize x is undefined. How about this: f 1 = 1 f 2 = 2 f 3 /= f 3 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] 0/0 1 == False
Mitar wrote: Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? Like nearly all programming languages, Haskell implements the standard IEEE behavior for floating point numbers. That leads to some mathematical infelicities that are especially irking to us in Haskell, but the consensus was that it is best to follow the standard. That is why NaN==NaN, NaNNaN, and NaNNan are all False, The special case of 1/0 is less clear, though. One might decide that it should be an error rather than NaN, as some languages have. Cristian Baboi wrote: I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) This does not violate referential transparency. f 0 is always the same value. (==) is a function like any other; in this case, it does not satisfy the mathematical laws we would like it to in order to conform to standard floating point behavior. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
and there is no such thing as the same bottom right ? On Thu, 10 Jan 2008 11:13:05 +0200, Ketil Malde [EMAIL PROTECTED] wrote: Cristian Baboi [EMAIL PROTECTED] writes: I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) I think you are wrong. Referential transparency says that you can replace any occurence of 'f 0' with another expression of the same value, it does not say anything about the behaviour of (==). -k 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] 0/0 1 == False
Cristian Baboi wrote: and there is no such thing as the same bottom right ? Yes and no. Semantically, every bottom is the same. However, the Haskell Report makes bottom an explicit exceptional case. Compilers are allowed to do whatever they want with bottoms, including different results for different bottoms. There isn't any choice, really. In order to behave the same for every bottom, you would first have to solve the Halting Problem. Or hang forever on every bottom, which I don't think you would want. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Cristian Baboi [EMAIL PROTECTED] writes: I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) I think you are wrong. Referential transparency says that you can replace any occurence of 'f 0' with another expression of the same value, it does not say anything about the behaviour of (==). -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] 0/0 1 == False
On Thu, 10 Jan 2008 11:23:51 +0200, Yitzchak Gale [EMAIL PROTECTED] wrote: Cristian Baboi wrote: and there is no such thing as the same bottom right ? Yes and no. Semantically, Yes and No is bottom ? 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] 0/0 1 == False
Yitzchak Gale wrote: Mitar wrote: Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? Like nearly all programming languages, Haskell implements the standard IEEE behavior for floating point numbers. That leads to some mathematical infelicities that are especially irking to us in Haskell, but the consensus was that it is best to follow the standard. Nitpick: I think the haskell standard doesn't force you to implement IEEE floating point. Rather the haskell standard, for efficiency, permits you to reuse the native floating point of your host system. Since most of us are using haskell on top of IEEE C libraries / FPUs, most of us have IEEE floating point behaviour. Practically speaking, if you want different semantics from what the bare metal gives you, you have to wrap all kinds of things which would otherwise be directly compiled to opcodes, which robs you of any chance of getting the good performance you would hope for. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Cristian Baboi wrote: and there is no such thing as the same bottom right ? I wrote: Yes and no. Semantically, Yes and No is bottom ? Yes and no. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Cristian Baboi wrote: I think this should be put this way: Bottom is a part of the semantic domain which is not Haskell. Rather, something outside Haskell that describes what Haskell programs mean. Yes. In the semantic domain there is one bottom. In Haskell there are many expressions that represent bottom. One cannot test those for equality. Yes. The result of a Haskell function applied to some arguments cannot be bottom. I think you mean that they cannot be bottom if you want to compare them for equality. Yes. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
I wrote: Like nearly all programming languages, Haskell implements the standard IEEE behavior for floating point numbers. That leads to some mathematical infelicities that are especially irking to us in Haskell, but the consensus was that it is best to follow the standard. Jules Bean wrote: Nitpick: I think the haskell standard doesn't force you to implement IEEE floating point. Not a nitpick. I should have written Haskell compilers implement, not Haskell implements. Thanks for the correction, and for the additional illumination. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Yitzchak Gale [EMAIL PROTECTED] writes: In the semantic domain there is one bottom. In Haskell there are many expressions that represent bottom. One cannot test those for equality. If we are being pedantic, I can define data Foo = Foo instance Eq Foo where _ == _ = True (undefined :: Foo) == Foo -- True The result of a Haskell function applied to some arguments cannot be bottom. This function is bottom for any argument: f x = undefined I think you mean that they cannot be bottom if you want to compare them for equality. Yes. See above. What is the precise term for describing this? Structural equality? On the other hand, some bottoms are exceptions, you may be able to catch them and do something useful with them after all, no? How does that fit in? -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] 0/0 1 == False
On Thu, 10 Jan 2008, Ketil Malde wrote: I think you mean that they cannot be bottom if you want to compare them for equality. Yes. See above. What is the precise term for describing this? Structural equality? On the other hand, some bottoms are exceptions, you may be able to catch them and do something useful with them after all, no? How does that fit in? Catching errors is a hack: http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, Jan 10, 2008 at 11:17:18AM +0200, Yitzchak Gale wrote: The special case of 1/0 is less clear, though. One might decide that it should be an error rather than NaN, as some languages have. It is neither, 1/0 = Infinity -1/0 = -Infinity At least on IEEE style floating point systems. (this isn't mandated by the haskell standard though I believe) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 10 Jan 2008 10:22:03 +0200, Mitar [EMAIL PROTECTED] wrote: Hi! Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? NaN is not 'undefined' (0/0) /= (0/0) is True (0/0) == (0/0) is False You can use these to test for NaN. 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] 0/0 1 == False
cristi: On Thu, 10 Jan 2008 10:22:03 +0200, Mitar [EMAIL PROTECTED] wrote: Hi! Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? NaN is not 'undefined' (0/0) /= (0/0) is True (0/0) == (0/0) is False You can use these to test for NaN. You can also use isNaN :) Prelude isNaN (1/0) False Prelude isNaN (0/0) True -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Fri, 11 Jan 2008 08:34:10 +0200, Don Stewart [EMAIL PROTECTED] wrote: NaN is not 'undefined' (0/0) /= (0/0) is True (0/0) == (0/0) is False You can use these to test for NaN. You can also use isNaN :) Prelude isNaN (1/0) False Prelude isNaN (0/0) True Not true in Hugs. 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] 0/0 1 == False
cristi: On Fri, 11 Jan 2008 08:34:10 +0200, Don Stewart [EMAIL PROTECTED] wrote: NaN is not 'undefined' (0/0) /= (0/0) is True (0/0) == (0/0) is False You can use these to test for NaN. You can also use isNaN :) Prelude isNaN (1/0) False Prelude isNaN (0/0) True Not true in Hugs. Report it to the Hugs guys (iirc they use their own math lib). P.S. Why are you using Hugs? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
