Subject: adding NaN to Verilog-AMS
From: Martin O'Leary (oleary@cadence.com)
Date: Mon May 13 2002 - 14:31:43 PDT
I asked someone here, Steve Sharp, who was on Verilog-2001 committee about
using NaN as a kind of real X (unknown).
Here is his feedback;
I don't know of any languages that have found the need to be able to
reference the value of NaN explicitly. There is not much point in
assigning it explicitly, since it will arise naturally in arithmetic
situations where the IEEE standard calls for it. And trying to compare
a value to it doesn't work, since NaN does not compare equal to
anything, including NaN. So (r == NaN) is false even if r is NaN.
That seriously limits the usefulness of having it available as a
constant.
Converting X to a real is probably rare enough that it wouldn't cause
severe backward compatibility problems. However, if NaN is considered
to be the floating point equivalent of X, shouldn't reals have an
initial value of NaN at the start of simulation to match non-real
variables which start at X? But that would cause severe backward
compatibility issues. There is probably plenty of code that relies
on reals to be initialized to zero (or at least to a value that doesn't
contaminate everything computed from it, potentially creating closed
loops of computation stuck at NaN). NaN behaves more pessimistically
than X, since it represents mathematical impossibility, rather than
just uncertainty between valid possibilities.
I don't think it makes sense to spend a lot of time worrying about NaN.
It seldom comes up in normal programming, and the usual action when
it does come up is to fix the bug in the code so that it doesn't. Note
that there is no mention of it anywhere in the Verilog standard. It
just isn't important to a user. Only hardcore numerical algorithms need
to worry about it, and the users of the algorithms generally don't care
as long as it was done right so they know whether their results are valid.
This archive was generated by hypermail 2b28 : Mon May 13 2002 - 14:33:39 PDT