[Valgrind-users] A "numerical analysis" valgrind skin

[Olly B. <ol...@su...>]

I was digging through some third party code looking for what appeared to
be a loss of numerical precision somewhere, which is a rather dull job.
I started wondering if this couldn't be automated using valgrind...

So imagine a valgrind skin (or tool if you prefer the newspeak) which
tagged every floating point value (F) with an error value (e), such that
F is known to lie in the interval [F - e, F + e].  Each floating point
operation would calculate the resulting error appropriately, for example
addition would be something like:

 (F1, e1) + (F2, e2) = (F1 + F2, e1 + e2)

If a value is "used" in a way such that behaviour might be affected if
F is changed by e or less, we issue a diagnostic.  I'm not quite sure
how to define "used".  A call to printf with format "%.4f" when the
error is 0.001 might be one example, or use in a conditional context, or
a call to a function which is ill-defined on a value within the
precision (e.g. sqrt of 0.2 with an error of 0.25).

I'm not realistically going to have time to write this anytime soon.
So I'm sending this to the list to prevent the idea just getting lost,
to let people pick holes and suggest improvements, and on the off-chance
that somebody else might even want to try coding it!

Some thoughts of my own:

Perhaps the error bounds should be asymmetric?  cos((0, 0.1)) can't
be more than 1.  The answer (0.99750, 0.00250) reflects the possible
outcomes, but changing the base value could mean changing the code's
behaviour after a warning.  The answer (1.0, 0.00500) would cause
acos(cos((0, 0.1)) to issue a bogus warning.

It might be necessary to track precision on integer values too -
otherwise what do you do when a floating point value is cast to an int?
You could warn if the error bounds overlap another integer, but that may
be overeager depending how the integer is used.

Code making use of defined IEEE fp properties may cause problems.
Perhaps we need to keep a bitmask with each value tracking "value could
also be +inf/-inf/..."

Cheers,
    Olly