"Peter Shenkin" <[log in to unmask]> wrote:
>
> On Jun 24, 11:14am, Dr W.W. Schulz wrote:
> > Subject: Re: dprod
> > ... If DPROD(x,y) and DBLE(x)*DBLE(y) always give the
> > same result then for all what users can know and care they can assume
> > that DPROD(x,y) is "defined as" DBLE(x)*DBLE(Y). This is good enough for
> > a definition.
> ...
>
> As I said in my first email in response to the assertion, those
> who want to say that DPROD(x,y) should give the same result as
> DBLE(x)*DBLE(y) have a good argument. *This* is the guarantee
> the user needs. I think I agree with this position. I also agree
> that DEC seems to do this, and that that's a Good Thing.
>
> But that was not your assertion. You said:
>
> > > > DEC thinks DPROD(x,y) is defined as DBLE(x)*DBLE(y)
>
> This is not an assertion about the result; it is an assertion
> about the implementation. This statement says that DEC first
> casts x and y to DBLE, then multiplies them. The fact that
> the numbers came out the way they did does not warrant that
> conclusion.
The warranty should come indeed not from the results, but from examination
of the assembly language. My Dec and Sun compilers use DBLE(x)*DBLE(y)
to compute DPROD(x,y), and my Nag compiler uses a call to a library
__f90_dprod (I am no longer a Real Programmer, so I cannot see what
the object code for __f90_dprod implements...).
>
> DPROD was created so that the user would have a way of saying,
> "If the architecture can multiply two REALs into a DP register,
> I want it to do so here."
That's exactly what I thought, and I would like the standard to
garantee that DPROD won't do some foolish thing instead, and not
give the same result as if I had written DBLE(x)*DBLE(y). And I
hope that I don't need to read the assembly language of each
new system's implementation before using DPROD. I'm getting too
old and busy with other things to find fun in assembly language.
>
> If DPROD were *defined as* DBLE(x)*DBLE(y), it would be
> useless, because it would disallow this operation. It would
> also be redundant, because the user could just put the casts
> in himself.
>
> -P.
>
Michel
Michel OLAGNON email: [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|