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

Re: snmpconf PM: Integer NaN?

At 07:41 PM 3/14/2001 -0500, Steve Moulton wrote:

>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.

Yes. I think the concept of an "unknown" and/or "error" value is very 
useful in certain environments. I am not against the concept in general. 
I'm just not convinced that it is the best thing for the Policy language.

>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.

The only disagreement I have with this is use of the term "calculation."  A 
statistical package performs a series of calculations in which an unknown 
value may enter and where it is very useful to propagate that value to an 
eventual result with value "unknown."  In a scripting language, however, 
the value of an expression will often be used to control an if-statement or 
while-loop. The actions inside the if-statement will often be much more 
than just more calculation. Even if they are just calculations, the error 
value could easily be lost, leading to incorrect code:

           var y;
         var x = some-expression-returning-NaN;
         if (x > 5)
           y = 1;
           y = 0;
         setvar("ifStatus", y, INTEGER);

In the above code, the if conditional will always evaluate to NaN which 
converts to FALSE. The setvar() at the end does not see the NaN 
value.  Scripts are not just calculations.  This is fixable (by having 
special rules for conditional expressions), but is it worth the added 
language complexity? What is the chance that we'll miss some other 
important situation that I haven't thought up yet?

>.  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
>    operations/whatever.
>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.

Thank you, Steve, for your thoughtful response.

>         - 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

- Pablo
Pablo Halpern                                    phalpern@newview.org