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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Thu, 10 Jan 2008 10:22:03 +0200, Mitar <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Mitar
Hi Mitar,
On Jan 10, 2008 9:22 AM, Mitar <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Thu, 10 Jan 2008 10:48:51 +0200, Benja Fallenstein
<[hidden email]> wrote: > Hi Mitar, > > On Jan 10, 2008 9:22 AM, Mitar <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Cristian Baboi-2
"Cristian Baboi" <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Benja Fallenstein
On Thu, 10 Jan 2008 10:48:51 +0200, Benja Fallenstein
<[hidden email]> wrote: > Hi Mitar, > > On Jan 10, 2008 9:22 AM, Mitar <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Cristian Baboi-2
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, NaN<NaN, and NaN>Nan 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Ketil Malde-3
and there is no such thing as "the same bottom" right ?
On Thu, 10 Jan 2008 11:13:05 +0200, Ketil Malde <[hidden email]> wrote: > "Cristian Baboi" <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Thu, 10 Jan 2008 11:23:51 +0200, Yitzchak Gale <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Yitzchak Gale
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Cristian Baboi-2
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Yitzchak Gale
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Jules Bean
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Yitzchak Gale
"Yitzchak Gale" <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Yitzchak Gale
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
John Meacham <[hidden email]> wrote:
> 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 > 1/-0 = -Infinity? -1/-0 = Infinity? If you don't have two separate values for nothing, one approaching from negativeness and one from positiveness, defining the result to be infinite instead of NaN makes no sense IMHO. -- (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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Thu, Jan 10, 2008 at 09:24:34PM +0100, Achim Schneider wrote:
> John Meacham <[hidden email]> wrote: > > 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 > > Just out of curiosity: > > 1/-0 = -Infinity? > -1/-0 = Infinity? Yes. (You could have tried this for yourself, you know... but I suppose haskell-cafe isn't a bad interactive Haskell interpreter, perhaps more user friendly than ghci.) -- David Roundy Department of Physics Oregon State University _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
David Roundy <[hidden email]> wrote:
> On Thu, Jan 10, 2008 at 09:24:34PM +0100, Achim Schneider wrote: > > John Meacham <[hidden email]> wrote: > > > 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 > > > > Just out of curiosity: > > > > 1/-0 = -Infinity? > > -1/-0 = Infinity? > > Yes. (You could have tried this for yourself, you know... but I > suppose haskell-cafe isn't a bad interactive Haskell interpreter, > perhaps more user friendly than ghci.) > *** Exception: divide by zero That's it. One just shouldn't just extrapolate and think you didn't mean GHC but IEEE... -- (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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |