Re: [office-formula] Creating the test suite

["David A. Wheeler" <dwheeler@dwheeler.com>]

> I was thinking of something more rigorous, where the processing model 
> treats things correctly from IEEE 754 perspective.  So, our functions 
> would be defined to return NaN or +Infinity, -Zero, or whatever, as 
> appropriate.  The XPath expression language, for example is defined this 
> way.  The user interface can still report things as simply "Error".  That 
> can  be implementation-defined.
> 
> Now where would this make a difference?  In the case of  scientific 
> computing, such support can be used to detect numeric underflow/overflow 
> conditions, etc.  It also gives better integration with any native codeor 
> other system which does treat the floating point math according to IEEE 754.

Hmm, I see.  We may be able to get there trivially.
The spec has been carefully written to have Errors, but not be specific
about what the Errors are (other than that NA is one of them).  That way,
people can be general or specific about error conditions - we don't
interfere with innovation.

We could simply claim that Nan, +Infinity, and -Infinity are simply Error values,
and that -Zero is normally indistinguishable from 0.
Then we could define functions that can query them
(ISNAN(), ISINFINITY, ISPINFINITY, ISNINFINITY, ISNZERO or whatever), and
say "on applications whose number models match IEEE 754, the following
functions are defined...".  Call it the "Numeric Model Group" or whatever.
That way, people who are implementing "infinite" precision in software don't
have to do the full IEEE754 model (it's painful to do!), but if you already have
it in your chips, you can use it.

What do you think?  One danger - this is a committee invention (though
a pretty tame one).  And right now I think other things are higher priority.
If someone has a burning desire to do this, great, but let's work on completing
what we KNOW we need to complete.

--- David A. Wheeler