> Robin Vowels wrote:
> >
> > >
> > > 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.
> >
>
> I do not agree: if you don't know what is really done by a function
> and if you have clearer alternative ways to proceed, then the function
> is not far from not-useful...
>
> you have three ways to multiply two single precision (SP) reals
> and to get a double precision output:
>
> 1- DP conversion of SP multiplication of SP reals : DBLE(x*y)

No, this is not a double precision result.  It is single precision,
then converted to double precision, and is not what DPROD does.
.
> 2- DP multiplication of DP converted reals : DBLE(x)*DBLE(y)
> 3- DP multiplication of SP reals. The result is equal to 2-

On a machine that has hardware to produce a DP result from
SP arguments, (3) is what that implementor would do, otherwise
(2) is what the implementor would do.  If there is no hardware
available to do FP multiplication, (3) is what the implementor
would do.

This is what I wrote before.

> DPROD makes sense (is useful) only if it implements the third way.

But only if the hardware/software allows the implementor to do it.
Otherwise, it has to be by (2), which is perfectly legitimate.

The point is, it should be up to the implemtor to implement
it in the most efficieient way, whether it is by (2) or by (3).

It doesn't need a specification that says it must be by (2)
or by (3) or by some other way.

It is sufficient to know that the result is DP.

> If it is not the case, you simply don't need it because it is
> redundant.

No, it is not redundant, and you have missed the point.

>So the standard should specify this implementation
> (perhaps the implementor will use DBLE()*DBLE(), but he may
> choose a more efficient way, if there's one).
> As the current specification is so poor ("double precision result"),

What don't you understand about "double precision result"?

> this new one would be compatible with existing code.

> > > 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.

> This is not required by the standard...

> Regards
> Pierre Hugonnet                             Seismic Data Processing R&D



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