Re: make check error

[Gerard Jungman <jungman@lanl.gov>]

Matt Newville wrote:
>
> I may be missing the point of checking whether DBL_MIN*DBL_MIN
> is Underflow or 0.  It all seems a little pedantic to me.

Well, you know how it is, the illusion of robustness
and correctness, etc.

This discussion brings up a very important point which
should have been discussed but has thus far managed
to stay hidden. I have discussed this with Brian, but
either we have never come to a conclusion or I don't
understand the conclusion. The question is:

  What are we supposed to assume about
  the underlying arithmetic?

At various times I have been ready to assume
full (or sufficient anyway) IEEE conformance.
But then there is always some vacillation based
on the fear that people might be using this stuff
on some weird embedded DSP project or something,
with no IEEE safety net.

So, how many people are working on or worried that
they might someday work on a platform w/o IEEE 754?
This is really important to know.

I would like to fix this problem, but it's
time to absolutely firm up the boundary conditions
for this sort of thing, so I don't just wander
off in another random direction.

The requirements for gsl_sf_multiply_impl(),
as I see them:

  1. Must have GSL semantics for error reporting.
  2. Must provide error estimate, to conform to
     the other functions in this directory. 
  3. Must provide a valid result and error
     estimate when reporting success.

The current implementation does not (I think
this is, strictly speaking, a lie) depend on IEEE 754.
I would be happy to make one that does; the
current code is frankly kind of embarrassing,
but I didn't know what else to do w/o IEEE.

We could provide both, if absolutely needed,
and ifdef the right in at compile time. Yuck.
I wonder how many inconsistencies we would
miss if we really tried to go back and clean
this up?

-- 
G. Jungman
(Chief GSL Pedant and Multiplier of Numbers)