Re: make check error

[Brian Gough <bjg at network-theory dot co dot uk>]

Gerard Jungman writes:
 >   What are we supposed to assume about
 >   the underlying arithmetic?

Assume the least possible. i.e. the model for ordinary numbers, +/-{0,
[DBL_MIN, DBL_MAX]}

 > So, how many people are working on or worried that
 > they might someday work on a platform w/o IEEE 754?

Full IEEE support is hard to find.  Subsets are the norm. Conformance
depends on both the compiler and the fpu (classic example, compiler
optimisation x==x, where x=NaN). Conformance is always "claimed" by
the manufacturer, but there is no independent test (c.f. FDIV bug).
Programs that "depend on" (i.e. rely on) a lot of IEEE features are
not very portable, and are almost impossible to debug when things go
wrong.

The sensible policy is to write to the reality of the platforms out
there -- assume that there are variable subsets, supported to variable
degrees and make appropriate tradeoffs for the module in question and
document them in the manual if important.  After normal arithmetic,
best supported is probably infinity arithmetic, and worst is maybe
denormalized numbers.

It is nice to use features of IEEE but it should be possible to
degrade gracefully. If not, don't rely on it. 

 > The current implementation does not (I think
 > this is, strictly speaking, a lie) depend on IEEE 754.

That is the right thing to do here I believe.  You could use the
GSL_POSINF GSL_NEGINF GSL_NAN macros for +/-Inf,NaN return values.  A
top-level rounding function would be useful for isolating the extended
precision issue into a single function.  This could then use the
appropriate assember instruction to round, rather than "volatile", or
be a no-op on platforms that do not have extended precision.