[Haskell-cafe] Re: Why purely in haskell?

[Luke Palmer]

On Jan 15, 2008 12:29 AM,  <jerzy.karczmarczuk at info.unicaen.fr> wrote:
> Ben Franksen writes:
>
> > jerzy.karczmarczuk at info.unicaen.fr 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