On Monday, 20 August 2012 at 19:28:33 UTC, Peter Alexander wrote:
On Sunday, 19 August 2012 at 22:22:28 UTC, Walter Bright wrote:
> I find it more likely that the NaN will go unnoticed and
> cause rare bugs.
NaNs in your output are pretty obvious. For example, if your
accounting program prints "NAN" for the amount on the payroll
cheques, someone is guaranteed to notice. But if it's a few
cents off in your disfavor, it might take you years to
discover there's a problem.
Critical systems also would find a NaN command a lot easier to
detect than an off-by-two command, and would be able to shut
down and engage the backup.
The problem is that it's easy for even NaN's to be filtered out.
float x = 0.0f;
float y; // oops
float z = min(x, y); // NaN has disappeared, unnoticed!
My argument is that conservative compile time errors on
uninitialised variables are more likely to catch these errors.
I just tried this:
float a, b = 10;
writeln(min(a, b), ", ", fmin(a, b));
Result:
nan, 10
I think that is incorrect - both should give NaN. The scientific
viz software I use at work returns NaN for any numerical
operation on NaN values, means, smoothing, etc.
