and there is no such thing as "the same bottom" right ? On Thu, 10 Jan 2008 11:13:05 +0200, Ketil Malde wrote:

"Cristian Baboi" 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

On Thu, 10 Jan 2008 11:23:51 +0200, Yitzchak Gale 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

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 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.

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

John Meacham 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.

David Roundy wrote:

On Thu, Jan 10, 2008 at 09:24:34PM +0100, Achim Schneider wrote:

...

John Meacham 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.

David Roundy wrote:

On Thu, Jan 10, 2008 at 09:41:53PM +0100, Achim Schneider wrote:

...

David Roundy wrote:

...

On Thu, Jan 10, 2008 at 09:24:34PM +0100, Achim Schneider wrote:

...

John Meacham wrote:

...

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...

Prelude> 1/(-0) -Infinity

You need to use the / operator, if you want to do floating-point division.

Yes, exactly, integers don't have +-0 and +-infinity... only (obviously) a kind of nan. It's just that with the stuff I do I know I have some logical problem in my formulas when I get any special floating point value anywhere, and using --excess-precision can only make the numbers more precise. Said differently: I don't know a thing about floats or numerics. -- (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.

Ketil Malde wrote:

Achim Schneider writes:

...

...

You need to use the / operator, if you want to do floating-point division.

...

Yes, exactly, integers don't have +-0 and +-infinity... only (obviously) a kind of nan.

No, failure (exception, bottom) is different from NaN, which is just another value in the domain - admittedly one which behaves rather strangely.

s/a kind of/not entirely unlike a/

...

Said differently: I don't know a thing about floats or numerics.

Perhaps it helps to think of floating point values as intervals? If +0 means some number between 0 and the next possible representable number (and similar for -0), it may make more sense to have 1/+0 and 1/-0 behave differently.

Hmmm... ah. +-0 / +-0 is always NaN 'cos you can't tell which one is bigger and thus can't decide between positive and negative Infinity, and it isn't both, either. But then there's +0/0 and -0/0, which would be +Infinity and -Infinity, and +0 > 0 > -0. AFAIK there are no floats with three zero values, though. -- (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.

David Roundy wrote:

Prelude> let x=1e-300/1e300 Prelude> x 0.0 Prelude> x/x NaN

The "true" answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN.

Weeeeeeeelllllllll...... math philosophy, Ok. You can't divide something in a way that uses no slices. You just don't cut, if you cut zero times. Which is what you do when you divide by one, mind you, not when you divide by zero. Division by [1..0] equals multiplication by [1..]. You can't get to the end of either spectrum, just axiomatically dodge around the singularities to axiomatically connect the loose ends. There is no true answer here, the question is wrong. And you're using floats where only rationals can tackle the problem. I was wrong in claiming that

...

But then there's +0/0 and -0/0, which would be +Infinity and -Infinity, and +0 > 0 > -0. AFAIK there are no floats with three zero values, though. , both are NaN.

-- (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.

On 11 Jan 2008, at 10:12 AM, Achim Schneider wrote:

David Roundy wrote:

...

Prelude> let x=1e-300/1e300 Prelude> x 0.0 Prelude> x/x NaN

The "true" answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN.

Didn't catch this the first time around, but: only to a physicist. (I mean no disrespect to the author of darcs, but nevertheless the point stands). Back in the real world, 0 / 0 may be defined arbitrarily, or left undefined. (Defining it breaks the wonderful property that, if lim (xn) = x, lim (yn) = y, and x/y = z, then lim (xn / yn) = z. This is considered a Bad Thing by real mathematicians). In fact, in integration theory 0 * inf = 0 for certain 'multiplications', which gives the lie to 0 / 0.

...

Weeeeeeeelllllllll...... math philosophy, Ok.

You can't divide something in a way that uses no slices. You just don't cut, if you cut zero times. Which is what you do when you divide by one, mind you, not when you divide by zero. Division by [1..0] equals multiplication by [1..].

Right. (Although 0 * inf is defined by fiat, as noted above).

You can't get to the end of either spectrum, just axiomatically dodge around the singularities to axiomatically connect the loose ends.

`Axiomatically' --- you mean by re-defining standard notation like * and / to mean what you need in this case. I think this is a different thing than setting up ZFC so everyone agrees on what a `set' is from henceforth.

There is no true answer here, the question is wrong.

Exactly. jcc

Achim Schneider wrote:

whereas lim( 0 ) * lim( inf ) is anything you want

Indeed I suppose that »lim inf«, which is a notation I'm not familiar with, is not actually defined to mean anything? Kalman ---------------------------------------------------------------------- Find out how you can get spam free email. http://www.bluebottle.com/tag/3

On Sat, 12 Jan 2008, Achim Schneider wrote:

Kalman Noel wrote:

...

Achim Schneider wrote:

...

whereas lim( 0 ) * lim( inf ) is anything you want

Indeed I suppose that »lim inf«, which is a notation I'm not familiar with, is not actually defined to mean anything?

It's an ad-hoc expression of "as the slices approach zero size, their number approaches infinity". It's more an observation than anything else. I have no idea how a professional mathematician would formalise it.

In Haskell you could professionally formalize it, if you would have a function, which computes the limit of a sequence: limit :: [Real] -> Real (Cf. "Why functional progrmaming matters" http://www.math.chalmers.se/~rjmh/Papers/whyfp.html) let xs = iterate (1+) 1 -- example for "lim (inf)" ys = map recip xs -- example for "lim (0)" in limit (zipWith (*) xs ys) If 'limit xs' and 'limit ys' are defined, then it holds limit (zipWith (*) xs ys) == limit xs * limit ys but in your case 'limit xs' does not exist. You can imagine it as infinity, but to make it formally safe, you need something non-standard analysis.

Achim Schneider wrote:

Actually, lim( 0 ) * lim( inf ) isn't anything but equals one, and the anything is defined to one (or, rather, is _one_ anything) to be able to use the abstraction. It's a bit like the difference between eight pens and a box of pens. If someone knows how to properly formalise n = 1, please speak up.

Sorry if I still don't follow at all. Here is how I understand (i. e. have learnt) lim notation, with n ∈ N, a_n ∈ R. (Excuse my poor terminology, I have to translate this in my mind from German maths language ;-). My point of posting this is that I don't see how to accommodate the lim notation as I know it with your term. The limit of infinity? What is the limit of infinity, and why should I multiplicate it with 0? Why should I get 1? (1) lim a_n = a (where a ∈ R) (2) lim a_n = ∞ (3) lim a_n = − ∞ (4) lim { x → x0 } f(x) = y (where f is a function into R) (1) means that the sequence of reals a_n converges towards a. (2) means that the sequence does not converge, because you can always find a value that is /larger/ than what you hoped might be the limit. (3) means that the sequence does not converge, because you can always find a value that is /smaller/ than what you hoped might be the limit. (4) means that for any sequence of reals (x_n ∈ dom f) converging towards x0, we have lim f(x_n) = y. For this equation again, we have the three cases above. Kalman ---------------------------------------------------------------------- Find out how you can get spam free email. http://www.bluebottle.com/tag/3

We agree that the absolute freedom to discuss the issue of how many angels could dance on the head of a pin is very important, but - must it hold on *this* list? The problem was there: the incapacity of Haskell to deal with the complexity of the floating-point computations. Important issue. Now you are juggling with infinities "as such", speculating on what are limits of non-converging sequences, etc. It becomes sad. Normal people - of course - just throw away all these messages without reacting. I react, because I feel that diluting an important problem in a scholastic discussion discourages people to think how to solve the true question... Jerzy Karczmarczuk

Cristian Baboi:

Suppose lim a_n = a , lim b_n = b, c_2n = a_n, c_2n+1 = b_n.

What is lim c_n ?

If my intuition was of any importance here, it would claim that c_n diverges, because if I roughly approximate c_n by the sequence c' = ⟨a,b,a,b,...⟩, then I note that c' oscillates, so c_n »roughly oscillates«. Kalman ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com/tag/1

Cristian Baboi wrote:

...

Cristian Baboi:

...

Suppose lim a_n = a , lim b_n = b, c_2n = a_n, c_2n+1 = b_n. What is lim c_n ?

If my intuition was of any importance here, it would claim that c_n diverges, because if I roughly approximate c_n by the sequence c' = ⟨a,b,a,b,...⟩, then I note that c' oscillates, so c_n »roughly oscillates«.

You mean something like this x=a:b:x ?

Ah, you try to be on-topic by using Haskell syntax :) Obviously though, I really forgot to consider the case a = b... But that's enough OT for today, I guess. Kalman ---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com/tag/2

On 12 Jan 2008, at 3:33 AM, Cristian Baboi wrote:

On Sat, 12 Jan 2008 13:23:41 +0200, Kalman Noel wrote:

...

Achim Schneider wrote:

...

Actually, lim( 0 ) * lim( inf ) isn't anything but equals one, and the anything is defined to one (or, rather, is _one_ anything) to be able to use the abstraction. It's a bit like the difference between eight pens and a box of pens. If someone knows how to properly formalise n = 1, please speak up.

Sorry if I still don't follow at all. Here is how I understand (i. e. have learnt) lim notation, with n ∈ N, a_n ∈ R. (Excuse my poor terminology, I have to translate this in my mind from German maths language ;-). My point of posting this is that I don't see how to accommodate the lim notation as I know it with your term. The limit of infinity? What is the limit of infinity, and why should I multiplicate it with 0? Why should I get 1?

(1) lim a_n = a (where a ∈ R) (2) lim a_n = ∞ (3) lim a_n = − ∞ (4) lim { x → x0 } f(x) = y (where f is a function into R)

(1) means that the sequence of reals a_n converges towards a.

(2) means that the sequence does not converge, because you can always find a value that is /larger/ than what you hoped might be the limit. (3) means that the sequence does not converge, because you can always find a value that is /smaller/ than what you hoped might be the limit.

(4) means that for any sequence of reals (x_n ∈ dom f) converging towards x0, we have lim f(x_n) = y. For this equation again, we have the three cases above.

Suppose lim a_n = a , lim b_n = b, c_2n = a_n, c_2n+1 = b_n.

What is lim c_n ?

If a = b, lim c_n = a = b. Otherwise lim c_n is undefined, in the sense that there is no number c such that the assertion lim c_n = c is true. The `=' in this assertion isn't an equality; it's just a bit of math syntax, used in the special case where it isn't overly confusing. jcc

On 12 Jan 2008, at 4:06 AM, Achim Schneider wrote:

Kalman Noel wrote:

...

Achim Schneider wrote:

...

Actually, lim( 0 ) * lim( inf ) isn't anything but equals one, and the anything is defined to one (or, rather, is _one_ anything) to be able to use the abstraction. It's a bit like the difference between eight pens and a box of pens. If someone knows how to properly formalise n = 1, please speak up.

Sorry if I still don't follow at all. Here is how I understand (i. e. have learnt) lim notation, with n ∈ N, a_n ∈ R. (Excuse my poor terminology, I have to translate this in my mind from German maths language ;-). My point of posting this is that I don't see how to accommodate the lim notation as I know it with your term. The limit of infinity? What is the limit of infinity, and why should I multiplicate it with 0? Why should I get 1?

n * n = 1 where

lim lim n -> 0 n -> oo

wtf?

You don't get 1, you start off with it.

If you start off with anything, you can often end up with it as well. Enlightenment comes when you realize that sometimes you don't, and you acquire the ability to change your mind.

If you want to find the area of a function,

Under, not of.

you slice 1^2 into infinitely many parts and then look how much every single slice differs from lim( 0 ) * 1

Beg pardon? lim(0) = 0. lim(0) * 1 = 0.

, all that lim( inf ) many times.

You can't do this. lim(inf) = inf is an extended real number, and is completely unrelated to aleph_0 = the least upper bound of N. inf is not a cardinality and cannot be a number of times.

When you've finished counting pebble, you know how to scale this 1^2 to match it with your "normal" value of 1.

n = 12 n = 1 * n

now, 1 is twelve. QED: The wrath of algebra.

`Algebra'

"One" as a pure concept is a very strange beast, as it can mean anything.

To you. Mathematicians assign a different meaning to the concept.

jcc

On 12 Jan 2008, at 3:23 AM, Kalman Noel wrote:

Achim Schneider wrote:

...

Actually, lim( 0 ) * lim( inf ) isn't anything but equals one, and the anything is defined to one (or, rather, is _one_ anything) to be able to use the abstraction. It's a bit like the difference between eight pens and a box of pens. If someone knows how to properly formalise n = 1, please speak up.

Sorry if I still don't follow at all.

That's ok, neither does he.

Here is how I understand (i. e. have learnt) lim notation, with n ∈ N, a_n ∈ R. (Excuse my poor terminology, I have to translate this in my mind from German maths language ;-).

OK so far. I actually had a professor in uni who would randomly switch to German during lectures; I'll do my best to follow your notation :)

My point of posting this is that I don't see how to accommodate the lim notation as I know it with your term. The limit of infinity? What is the limit of infinity,

If you extend your concept of `sequence' to include sequences of extended real numbers, the limit of the sequence that is identically inf is inf. Otherwise, the notation isn't really meaningful.

and why should I multiplicate it with 0? Why should I get 1?

(1) lim a_n = a (where a ∈ R) (2) lim a_n = ∞ (3) lim a_n = − ∞ (4) lim { x → x0 } f(x) = y (where f is a function into R)

(1) means that the sequence of reals a_n converges towards a.

(2) means that the sequence does not converge,

To a value in R. Again, inf is a perfectly well defined extended real number, and behaves like any other element of R u {-inf, inf}. (Although that structure isn't quite a field --- 0 * inf isn't defined, nor is inf - inf).

because you can always find a value that is /larger/ than what you hoped might be the limit.

(3) means that the sequence does not converge, because you can always find a value that is /smaller/ than what you hoped might be the limit.

(4) means that for any sequence of reals (x_n ∈ dom f) converging towards x0, we have lim f(x_n) = y. For this equation again, we have the three cases above.

jcc

Ben Franksen wrote:

Kalman Noel wrote:

...

(2) lim a_n = ∞

[...]

...

(2) means that the sequence does not converge, because you can always find a value that is /larger/ than what you hoped might be the limit.

(2) usually rather mean that for each positive limit A there is a number N such that a_N > A for /all/ n > N.

You're right here. I tried to come up with a more wordy, informal description, but failed on that.

Your definition of (2) is usually termed as '(a_n) contains a subsequence that tends toward +infinity'.

May you elaborate? I don't see where a subsequence comes into play here. Kalman ---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com/tag/2

Ben Franksen wrote:

Kalman Noel wrote:

...

Ben Franksen wrote:

...

Kalman Noel wrote:

...

(2) means that the sequence does not converge, because you can always find a value that is /larger/ than what you hoped might be the limit.

Your definition of (2) is usually termed as '(a_n) contains a subsequence that tends toward +infinity'. I'll show (2) <=> (2'), where

(2'): (a_n) contains a subsequence that tends toward +infinity

Only now did I understand that your point was to explain why and how my definition (2) is incorrect. It's clear to me now. Kalman ---------------------------------------------------------------------- Finally - A spam blocker that actually works. http://www.bluebottle.com/tag/4

On 11 Jan 2008, at 11:25 PM, Achim Schneider wrote:

Jonathan Cast wrote:

...

On 11 Jan 2008, at 10:12 AM, Achim Schneider wrote:

...

David Roundy wrote:

...

Prelude> let x=1e-300/1e300 Prelude> x 0.0 Prelude> x/x NaN

The "true" answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN.

Didn't catch this the first time around, but: only to a physicist. (I mean no disrespect to the author of darcs, but nevertheless the point stands). Back in the real world, 0 / 0 may be defined arbitrarily, or left undefined. (Defining it breaks the wonderful property that, if lim (xn) = x, lim (yn) = y, and x/y = z, then lim (xn / yn) = z. This is considered a Bad Thing by real mathematicians). In fact, in integration theory 0 * inf = 0 for certain 'multiplications', which gives the lie to 0 / 0.

whereas lim( 0 ) * lim( inf ) is anything you want, or, more precisely, the area of the thing you started with.

I think you're thinking of the Riemann integral (I was thinking of the Lebesgue integral, and in particular the definition of the integral for step functions). That integral can be informally characterized as the sum of infinitely many terms, each zero (it's a limit of finite sums, where the largest (in the sense of absolute value) term in each sum goes to 0 as the sequence proceeds). That's scarcely a rigorous characterization, and it overlooks a ton of issues (like the fact that neither an infinite sum nor a sum identically 0 terms is actually involved), and it's scarcely relevant to the numerical analysis question of what 0/0 should return except to point out that any definition is going to make *somebody*'s algorithm silently go wrong... jcc

On 14 Jan 2008, at 9:56 AM, David Roundy wrote:

On Fri, Jan 11, 2008 at 07:10:20PM -0800, Jonathan Cast wrote:

...

On 11 Jan 2008, at 10:12 AM, Achim Schneider wrote:

...

David Roundy wrote:

...

Prelude> let x=1e-300/1e300 Prelude> x 0.0 Prelude> x/x NaN

The "true" answer here is that x/x == 1.0 (not 0 or +Infinity), but there's no way for the computer to know this, so it's NaN.

Ah. My apologies. Must remember to read first, then flame... You are right that, in Ratio Integer, you get this result. But you can't get that answer in Double. jcc

On Thu, 10 Jan 2008 10:48:51 +0200, Benja Fallenstein wrote:

Hi Mitar,

On Jan 10, 2008 9:22 AM, Mitar 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

Benja Fallenstein wrote:

On Jan 10, 2008 9:22 AM, Mitar 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."

In Mathematics one usually avoids comparing undefined values. If one does the result is undefined, too, of course. IOW, the whole calculation is worthless scribble. Cheers Ben

cristi:

On Thu, 10 Jan 2008 10:22:03 +0200, Mitar 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

cristi:

On Fri, 11 Jan 2008 08:34:10 +0200, Don Stewart 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

On Thu, 2008-01-17 at 03:16 +0100, Mitar wrote:

Hi!

On Jan 11, 2008 7:30 AM, Cristian Baboi 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.