On 12 Feb 2008, at 5:14 pm, [EMAIL PROTECTED] wrote:
Would you say that *no* typical floating-point software is reliable?
With lots of hedging and clutching of protective amulets around the
word "reliable", of course not. What I *am* saying is that
(a) it's exceptionally HARD to make reliable because although the
operations
are well defined and arguably reasonable they do NOT obey the
laws that
school and university mathematics teach us to expect them to obey
(b) "reliable" in each case needs to be defined with some care; it will
almost never mean "gives answers accurate to machine precision for
any legal input" and probably won't mean "gives sensible answers
for
any legal input" either. With luck, it will mean "gives answers
accurate
to a specified tolerance for an input that differs from the
input you
actually provided by no more than a specified tolerance for inputs
that are neither too big nor too small, a stated range". (Note
that
the problem that gets almost solved may only be almost your
problem.)
(c) practical advice is to use reputable packaged software whenever you
possibly can rather than writing your own, and always check that
the
answers make physical sense before putting any trust with them;
if (or
should I say when) things go weird, seek the help of an expert.
(d) if you trust the output of a certain popular spreadsheet program, I
have a bridge you might be interested in buying...
This is leaving aside all sorts of machine strangeness, like the student
whose neural net program started running hundreds of times slower than
he expected. I advised him to replace
s = 0;
for (i = 0; i < n; i++) s += x[i]*x[i];
by
s = 0;
for (i = 0; i < n; i++)
if (fabs(x[i]) > 1e-19)
s += x[i]*x[i];
and the problem went away. Dear reader: do you know why I expected this
problem, what it was, and why this is NOT a general solution?
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
