0/0 > 1 == False

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

0/0 > 1 == False

Mitar
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Cristian Baboi-2
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Benja Fallenstein
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Cristian Baboi-2
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Ketil Malde-3
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Cristian Baboi-2
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Yitzchak Gale
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Cristian Baboi-2
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Yitzchak Gale
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Cristian Baboi-2
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Jules Bean
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Yitzchak Gale
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Yitzchak Gale
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Yitzchak Gale
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Ketil Malde-3
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Henning Thielemann

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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

John Meacham
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Achim Schneider
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?

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
Reply | Threaded
Open this post in threaded view
|

Re: Re: 0/0 > 1 == False

David Roundy-2
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
Reply | Threaded
Open this post in threaded view
|

Re: 0/0 > 1 == False

Achim Schneider
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.)
>
Prelude> 1 `div` 0
*** 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
1234