Useful Optimizations for Numerical Code

[Doug Gwyn (VLD/VMB)]

Just because an implementation does not provide an exact match to some
assumed computational model does not mean that the implementation is
wrong or that the model was appropriate to adopt in the first place.

I've been programming numerical applications longer than almost anyone
I know of, including on computers where that meant providing one's own
support for arithmetic operations.  I too once wrote high-level
language code that attempted to probe details of machine arithmetic,
to determine suitable "epsilons" etc.  However, I've found through
experience that there are a large number of useful and interesting
computing architectures that violate any such simple model of the
computational process, particularly with respect to floating-point
operations.  There may be hidden guard bits, multiple levels of caching
with different numbers of bits at different levels, funny notions of
round-off, truncation in surprising directions, gradual underflow, etc.,
etc. to the point that these days I'm much more surprised when such a
high-level test for computational precision returns anything even semi-
useful than when it doesn't.

There are other ways to accomplish what is being attempted with such
code.  I see no point in trying to return to a largely imaginary notion
of how computations were performed in the "good old days".  Much better
to devise an alternative that can be GUARANTEED to work without having
to enlist the universal cooperation of the system software providers.