On 12 Feb 2008, at 5:14 pm, jerzy.karczmarczuk@info.unicaen.fr 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?