> Peter Shenkin wrote:
> >
> > But I don't think DPROD is supposed to be equivalent to DBLE*DBLE;
> > if it were, there would have been no need for it. It was intended
> > to allow a processor to carry out arithmetic directly on REALs but
> > maintain the more significant bits in the result. The reason, as
> > I understand it, is that some processors provide machine
> > instructions for this that are more efficient than DBLE*DBLE,
> > besides which it wouldn't be necessary to incur the cost of the
> > REAL->DBLE conversion.
> >
>
> In my sense (and as was stated by Michel Olagnon), to make DPROD a
> really useful function, the standard should simply say that the result
> should be equivalent to DBLE()*DBLE().
No, it dosn't need this to make it a "useful" function.
It is sufficient to have stated that a double precision result is
obtained. That allows the implementor to produce code for the
most efficient way to do it.
As has already been pointed out, some machines/implementations
use the double-length product obtained by multiplying two
reals. In others, it may mean converting each argument to
double precision before multiplying.
To insist that it be done this way or that may force the implementor
to make an inefficient implementation.
> What can be expected from DPROD are better performances than
> DBLE()*DBLE() on some machines, or at least equivalent performances
> on machines where internal multiplications are already performed on
> double reals.
>
> In fact there is a need of a whole set of functions where the result
> would be of a higher precision that the input numbers, the most
> classical one being the dot_product:
One would hope that this is done internally, before returning
the result.
> dot_product(x,y,kind=kind(1.0d0)), where x,y are default reals
>
>
> Regards
> Pierre Hugonnet Seismic Data Processing R&D
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|