[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf PM: Integer NaN?

A long time ago, I was a developer on a general statistical 
analysis system.  One of the concepts designed
in (and hardly original to the system in particular) was a 
"unknown value".  In doing statistical analyses, there are occasionally
holes in the data, and in some cases it is vital that any operation
where an unknown value was an operand produce an unknown value. 
Thus the effects of missing values propagate throughout the
calculation, and you _know_ if your results are unreliable, and
what part of your results are tainted.  

The idea of a NaN in the policy mib language is similar, and 
more like an "unknown value" than like a floating point NaN.

There are two upsides I can think of offhand:

.  You know what you don't know.  If something has failed, you
   don't inadvertently take its value to be zero, and have that
   error propagated throughout your whole calculation.

.  If you are willing to put in the additional care to address
   situations where this can occur, it can conveniently prevent
   programs from halting during critical calculations/configuration

The downsides:

.  The script writer has to be very aware of the behaviors associated
   with a NaN/unknown value, and code accordingly.  Many programmers
   with a non-numerical background find the whole concept to be foreign
   and make false assumptions about the origin and behavior
   of NaNs in calculations (please don't read this as addressed
   to anyone involved in this issue).

.  Requires additional language design, implementation time, and
   coding complexity.

Steve has nicely and, and with only one minor omission that I can
see, covered the design issues.

The question that bothers me most is "under what circumstances can
a NaN-valued var enter a calculation".  I can only see the following:

.   divide by zero

.   toInteger(a-string-that-does-not-represent-an-integer)

As Jeff Case mentioned in an earlier message, the addition of
a isInteger(string) function will handle the second case.
Careful coding will in general handle the first.  Given 
an isInteger() accessor function to check the string before
converting it, and its proper use, any other situations giving
rise to these conditions should be regarded as an exception, I think.
For this limited number of cases, proper script coding would
probably be less onerous than the additional consideration required
for addressing NaNs.

While I will happily argue the utility of the NaN concept, 
unless there are more cases where NaNs can enter the system,
I don't think the additional utility will not make up for the cost.
Should more cases be found, I can easily be convinced otherwise.

Steve, thanks for giving the whole issue a patient hearing.

        - Steve
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
moulton@snmp.com     Knoxville, TN 37920-9716 USA  http://www.snmp.com