🚀 go-pugleaf

"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> writes:

> As far as I know, Fortran still requires floating point multiply to generate
> a result with no more precision than the arguments that went into it.

I disagree.  I don't think that any version of the standard makes such a
requirement.  The standard does not specify accuracy requirements.  In
my opinion, you are getting into the question of computational versus
mathematical differences.  I just got up and don't feel like dragging out the
latest standard to find the relevant citation (much less finding the
similar citation in other versions), but I'm sure many here will know
the one I'm referring to.

The fact that the standard describes  (a*b)+(c*d) interms of single
precision (when a,b,c,d are all single) does not mean that the result of
that computation has to be bit-by-bit identical with a naive implementation
of that expression.

If you go down that path, before long you'll probably conclude that the
standard disallows guard bits.  I simply do not believe this to be true
(or ever to have been true).

As someone else pointed out, the standard (as of f77, I think it was)
provides the DPROD intrinsic specifically for the purpose of doing a
double precision product of single precision operands.  Let me note
on a related matter that the standard does *NOT* require the result of
dprod(a,b) to actually be any more accurate than a*b.  It has to be
represented in double precision, but it doesn't have to meet any particular
accuracy requirements.  Of course, a user is likely to expect it to,
but I think that's one of thoes quality of implementation issues.  If
the vendor doesn't feel like bothering to do a good job of it, the
standard isn't the tool that will address that problem in this case.

-- 
Richard Maine
email: my last name at domain
domain: isomedia dot com