Re: NaN-toolbox much faster now

[Jason Riedy]

And Jaroslav Hajek writes:
> Actually this somewhat similar to is what is done for integer
> types - they raise global flags on operation or conversion
> overflows. And this comes at the cost of encapsulating them in
> a special class, which brings more problems... I don't see this
> as a viable option for real types.

It's already supported in IEEE-754 systems.  Use signaling NaNs
as the stored NaNs.  Test for the invalid flag after operations.
You still need to disambiguate between NaN-producing operations
and sNaNs, and you need to filter NaNs so you store sNaNs.  Both
are O(amount of data) and only are necessary if the invalid flag
is raised.

Keeping the implementation sane requires setting the IEEE
default, no-trapping mode.  Keeping the *use* sane requires some
thought about integrating these features into Octave's language.

So mean ([5, NaN]) could return 5 and set a flag or return an
extra value to indicate a NaN was encountered.  But that would
take quite some time & documentation to explain.

There *SHOULD* be portable means to do this.  Many systems claim
IEEE-754 compliance, and that means there is some mechanism
available to carry out the above.  In reality, however, the only
mechanism for access to these features (via C99) is not supported
fully on many platforms.

IIRC, Windows makes the invalid flag inaccessible.  So this whole
message is kinda pointless.  But it is an alternate route for
implementing the NaN-toolkit behavior.  Needs extra hooks into
Octave...

Jason