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

[jerzy.karczmarczuk at info.unicaen.fr]

Luke Palmer dialog with myself: 

> On Jan 15, 2008 12:29 AM,  <jerzy.karczmarczuk at info.unicaen.fr> wrote:

>> When math says that something is undefined, in my little brain I 
>> understand that there is no answer.

> I'm not sure if I'm agreeing or disagreeing with you here.  Depends on 
> exactly what you mean by no answer.

Yes, this is a doctrinal problem. Since *any* concrete reaction, e.g., an
error message is a kind of answer, the only - unusable as it is - way of
not providing it is to fail the termination... 

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

What I see faulty here is that your students were not given, or could not
grasp the only "serious" word in the problem statement, the word *limit*.
In engineering, physics, etc., sometimes math is conveyed a bit approxima-
tively, swallowing some touchy points, and relying on intuition. This is
unavoidable, question of time. I taught math to physics students a bit and
there is no free lunch here. But a true mathematician lecturing to genuine
math students *here* makes the things clear as crystal. And what I learnt
then was exactly that: undefined means no answer. 

I may be wrong, but it is possible that in such "state of spirit" of the
Creators the Haskell <<undefined>> object arose into "being". 

Whether you say that: 

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

or use such words as "illegal", "forbidden", etc., this is a question of
philosophy more than math. At least: semantics. For Leibniz (or his eternal
foe, Spinoza) it could even belong to ethics...
We, or whoever might speculate until the solution of the non-termination
problem whether math forbids anything, or what is the sense of a question,
or the sense of the sense.
Mathematicians I crossed in my life (plenty of them; same building...), at
least some of them, *did* say that undefined means no answer. 

Your example with the King on the chessboard goes along the doctrine
professed by Achim S., "forbidding" something. But this word, "legality",
etc. is a juridic term, something not so meaningful in math. OK, you are
forbidden to try 0/0. But you DO. So what?
You claim that math doesn't say "undefined", mathematicians do, etc.
Now, does MATH say "Hey! there is no sense in what you are doing!"? But
math as an abstract domain, does it have "built-in" the notion of sense
neither. You say: "you are out of system/sense". I say "you get no answer".
I believe that my standpoint is more operational. 

> Personally, I loathe the existence of NaN and +-Infinity in floating
> point types.

I conclude that you live far from the numeric world. But I was raised as
physicist, and without them, the implementation of several algorithms
would be extremely difficult. 

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

Once more, last time...
The interval interpretation is a bit pulled out of thin air. It might be
thought of, as the last bit rounding has sth. to do with "fuzzy" arith.,
but I don't think that this is the issue. 

I believe that if we wanted to be as close to math as we would be happy
with, the only way is to extend the typing of numbers. There are numbers,
and there are NaNs and infinities. PERFECTLY decent objects, with concrete
representations (or families of). The arith. ops may generate those types,
and if applied to them, the disease propagates. Simple as that. 

For many, many numerical library procedures which use automatic search
through some domains, for vectorized computations, etc., bombing is almost
as bad as non-termination. It provides you gratuitously with a waste of
time. Absolutely inacceptable for engineering reasons. In games it might
happen as well, when, e.g., a collision handling module finds a pathological
geometrical situation, with a singularity so close that math bombs. Then,
a possible solution is to output /some/ random value, and not break the
game. In other words., accept NaNs and infinities, and do with them what
your program requires. YOU take the responsability of raising an exception,
not the system. 

Jerzy Karczmarczuk