In a message dated 6/19/98 12:21:20 AM Pacific Daylight Time,
[log in to unmask] writes:

DPROD is a very useful function, but not complete.
I think it should be:

1 - generalised to complex numbers (why isn't it ?)

This certainly would be useful for working with complex on non-Intel
architectures.  

2 - generalised to any kind parameters, something like
    DPROD(x,y,KIND=...), meaning that we want the result in
    the given real kind (this is of course essentially different from 
    REAL(x*y,KIND=...) or REAL(x,KIND=...)*REAL(y,KIND=...) )


I find it annoying when changing the KIND of variables breaks code which was
working well, because DPROD() is no longer accepted.  My emotional
expectation, however, is that the result corresponds with the KIND of the
arguments.

With such a great impetus toward movement to Intel, I'm not sure the issue
needs a solution.  As it is, I've never seen anyone use DPROD to improve
portability of code between non-extended and extended precision architectures.
I do believe I've demonstrated to myself, at least, that it's useful for that
purpose.  My personal version of Livermore Kernels produces the same precision
rating on all 32-bit real machines, extended precision or not, and that gives
a more realistic comparison of performance.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%