Cristian Baboi writes after my long political speech on numerics:
Well, Haskell has this "referential transparency" thing which say that a
function is a function and you will never be able to build anything else
:-)
What do you want to say/claim/suggest/propose/deny??
All these speculations about NaN==NaN, and other disgraceful exceptions
don't convey anything which would really break the referential transparency,
unless you outlaw yourself.
Travesting a US military saying:
If 'em things are not comparable, don't!
We can formalize this attitude, e.g. by extending/modifying the Num (and
the Eq and Ord) classes to take into account the specificity of the
non-standard arithmetic, but in general this contains plenty of traps.
It will be eventually done, but perhaps not tomorrow...
Ketil Malde reacts to:
The bombing of NaN *might* be a profound compilation option, but for
people who really do numerical work, this is a blessing NOT to have
it.
I don't understand this. Are you worried users will edit the
language pragmas in your code, and complain about NaN errors?
I do not worry about anything. I signal that the philosophy of crashing
the program as soon as an exceptional number is created (or even used),
is not the only one possible.
Back when I *was* using the abbreviation FP for 'Floatin Point', I
often got NaNs due to programming errors. Given the NaN's nature of
contaminating subsequent results, getting an exception at the first
occurrence would aid in tracking it down.
- Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful
for many purposes.
...and ditto for this. The usefulness of one case in no way justifies
sabotagin all other cases.
As I said, the exceptional treatment of exceptional values might be
a compilation option, as it was in some Fortrans I used long time ago.
You want your programs to react histerically to all difficulties in math,
since you are afraid of propagating NaNs, etc. And *then* you will have to
sit down and correct your code. If there is no exception, your program
may run happily, and produce rubbish, yes?
I am more conservative. If you are afraid of rubbish, protect your code
by appropriate checks *before* the errors occur. What you call a "sabotage"
I call the programmers negligence. You say that the usage of NaN as "empty"
is a <<poor man's way of spelling "Maybe Double">>. I presume you want
to say "Nothing". In a sense yes, but not "poor man". It is a way of
admitting that we have a hidden extended type, Nums, and other stuff, such
as NaNs and infinities. Floating-point numbers seem not to be a *one*
pure, primitive type, but a variant one. The problem is that this new type
values may come out of computations on normal values, so the static type
system of Haskell *in its actual shape* seems to be a bit too weak.
Instead of making a mess with the existing structures, please, propose
a non-standard Num class, and the appropriate instancing, which distinguish
between normal, and anormal numbers. Be free to bomb, or to react silently
to exceptional values.
The difference between you (and/or Wolfgang J.) and myself is that I enjoy
more my freedom, even if I have to pay with a little more work. You want
to enforce rigid reactions of the system. You should be free to do it on
*your* machine, not on mine.
Jerzy Karczmarczuk
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
