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

Re: snmpconf PM: Integer NaN?




Steve

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

The thing I'm interested in learning is which is better for the
programmer, bracketing with isInteger() or checking the expression
value for NaN. The most interesting difference between them is that
isInteger is checked before the conversion and NaN is checked after
the conversion. For example:


With isInteger():
  // Retrieve 1 digit decimal integer at 7th byte of octet string object
  str = getVar("xxx");
  i = substr(str, 7, 1);
  if (isInteger(i)){
      value = i * 1000;
      doSomeThingWith(value);
  } else {
     // do some cleanup (perhaps of scratchpad contents)
     // or maybe call signalException()
  }


With NaN:
  // Retrieve 1 digit decimal integer at 7th byte of octet string object
  str = getVar("xxx");
  i = substr(str, 7, 1);
  value = i * 1000;
  if (String(value) == "NaN"){
     // do some cleanup (perhaps of scratchpad contents)
     // or maybe call signalException()
     return;
  }
  doSomeThingWith(value);

Based on this example, I don't see much difference between having
to check before or being able to check after (i.e. no benefit to 
NaN). One scenario where it would be simpler with NaN is where many 
operands are rolled up into a value - it would be simpler to check
the value instead of each operand. I don't think this happens very
often though.

Another angle on this decision is that by gaining the flexibility
to detect errors after the fact and correct them, you lose the
flexibility to *skip* error detection (unless you're willing
to throw correctness out the window).

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

No, there are no other cases.

Personally I'm leaning towards no NaN as well. Does anyone see cases
where the taint value would simplify scripts?


Steve


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