OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Creating the test suite



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.

Not an urgent request, just an observation.  

-Rob

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 07/19/2006 05:17:54 PM:

> Robert Weir exclaimed:
> > Makes me wonder if we want to formally adopt IEEE 754 floating point
> > conventions for things like1/0 == +Infinity, but 0/0==NaN, etc.,  at least
> > in the processing model.  Implementations could collapse this all into a
> > single Error string for the user interface if they desired.
>
> To the best of my knowledge, in all implementations any such values
> (1/0, 0/0, etc.) are treated as an Error, which then propagates through other
> functions as an Error (except for the functions noted specially).
> If we want to relax this (for future implementations), what would you suggest?
>
> --- David A. Wheeler


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]