Subject: Re: snmpconf PM: Integer NaN?

From: Jeff Case <[email-masked]>
Date: Tue, 13 Mar 2001 13:19:48 -0500 (EST)

most of the concepts in your note are based on an assumption:

	In the future, it seems certain that floating point numbers
	will be added to the set of SNMP data types.

i think it is far from certain that floating point numbers will be added

the fact that adding floating point was carefully condidered in
	1987, and it was agreed that doing so is a bad idea
	1988, and it was agreed that doing so is a bad idea
	1990, and it was agreed that doing so is a bad idea
	1992, and it was agreed that doing so is a bad idea
	1995, and it was agreed that doing so is a bad idea
	etc

i know that there are voices calling for a new look at floating point
and perhaps it is appropriate to re-examine past decisions ... while
doing so, we have to remember that this is the internet *_engineering_* task
force ... if we make our decisions based on good engineering principles,
it is unlikely that floating point data types will be added

therefore, i disagree with your premise

however, i do not disagree with your conclusion

i have no problem with having divide-by-zero terminating a script with a
run-time exception

i have no problem with ToString() terminating a script with a run-time
exception upon failure

i think adding an IsInteger() function is required

right answers, wrong reasons

regards,
jdc

----------
From: Pablo Halpern <[email-masked]>
To: [email-masked]
Date: Tue, 13 Mar 2001 12:20:41 -0500
Subject: snmpconf PM: Integer NaN?

One thing that troubles me greatly about the current draft of the Policy 
MIB is that the policy language introduces the notion of an integer NaN 
(not-a-number). In no other language have I seen NaN represent an integer 
value. Every place I have seen it NaN has been a floating-point value. The 
purpose for introducing NaN is very dubious to me and seems have come about 
through an uncritical cut-and-past of ECMAScript Number semantics. 
(ECMAScript Numbers are floats.)  In the future, it seems certain that 
floating point numbers will be added to the set of SNMP data types. At that 
time, the Policy language will probably be extended to including floating 
point types as well. Introducing NaN for integers now will confuse matters 
when true floating-point NaN is needed later.  Let me, then break the issue 
into two parts:

1. Should we have NaN for integers?
2. If so, should it be called "NaN" or something else?

My opinion is that we should *not* have NaN for integers. One of our goals 
was to stick to existing language concepts was much as possible. The policy 
language is mostly C++ with a bit of ECMAScript (JavaScript) thrown in to 
make it better for scripting.  An integer NaN is not part of either C++ or 
ECMAScript.

In the draft as it currently is written, NaN is the result of one of the 
following:

1. Divide by zero
2. Converting a string to an Integer when that string does not contain a 
syntactically valid integer.
3. Using the result of either of the above in a computation.

All three of these constitute error conditions and should simply result in 
a run-time exception. Unlike floating point numbers, zero's don't happen 
"accidentally" in integer arithmetic as a result of lost precision. Thus, 
you should *never* have a divide-by-zero situation. Similarly, you should 
*never* attempt to convert a string to an integer unless you are sure it 
contains a syntactically valid integer. In both cases, the script writer is 
making an assumption about the inputs to an operation. If those assumptions 
(that the divisor is non-zero or that the string represents an integer) 
turn out to be wrong, the script should abort.

Scripting languages, unlike application languages should abort on a 
hair-trigger. It can be very damaging for a script to continue running 
after something has gone wrong.  It could result in shutting down a bunch 
of interfaces or changing some other configuration parameter. The current 
definition uses integer NaN values to make scripts continue running after 
an error. I don't think that's a good idea.

One might argue that a poorly-formed string might come from MIB objects and 
that it is too harsh to terminate the script in those situations. I don't 
agree. If you use a string in an integer context, it is because you are 
certain that the string will always represent an integer. If you're 
mistaken, an exception is the most humane way of alerting you. Propagating 
an NaN through calculations just puts the system into a strange state and 
does not help get the script's job done. At best, the script will silently 
do nothing. At worse, it could damage your configuration. Besides, how 
often will you retrieve an integer from a string-valued MIB object?

My proposal:

- Eliminate NaN from the current PM.
- Divide-by-zero causes a run-time exception and terminates the script.
- If ToString fails, it causes a run-time exception and terminates the script.
- Add an IsInteger() function that returns 1 if its argument is an integer 
or can be converted to an integer else returns 0.

P.S. If we decide to keep NaN, then let's at least rename it to "Error" or 
"IError" or something like that.  That way, it won't be confused with 
floating-point NaN.

- Pablo
---------------------------------------------------------------------
Pablo Halpern                                    [email-masked]
http://www.halpernwightsoftware.com

---

From: Pablo Halpern <[email-masked]>
Date: Tue, 13 Mar 2001 14:36:22 -0500

>         will be added to the set of SNMP data types.

I don't know why you would say this. I did make the above incorrect 
statement, but very little of my post actually relies on it. I only mention 
a future float type briefly at the beginning and end of my argument. The 
rest of my messages argues against integer NaN for exactly the reasons you 
state: scripts should terminate rather than propagate bad values.

>right answers, wrong reasons

Likewise :-)

- Pablo