Robin Vowels wrote:
>
> > > > 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)
> > > > 2- DP multiplication of DP converted reals : DBLE(x)*DBLE(y)
> > > > 3- DP multiplication of SP reals. The result is equal to 2-
> > >
>
> > With the current specification, an implementation of DPROD
> > by (1) is unfortunatly **perfectly standard conforming**
>
> I doublt it. If that were so, the product would be the same as DBLE(REAL (x*y))
> which you can get by writing DBLE (x*y). It's nothing like
> DPROD(x, y).
It's nothing like _what is expected_ from DPROD, but the point here is
that the standard lacks precision and authorize implementation of (1)
> >
> > The standard should specify that the result should be equal to
> > the result of (2) (which leaves the possibility to implement (3)).
>
> The standard only needs to say that a double precision product is obtained.
> Is there something about the term "double precision" that is causing difficulty?
>
I think this is the problem in this discussion:
when speaking about "double precision" we should separate the
KIND, characterised by a given number of significant digits, and
the precision in terms of results accuracy.
Everything in the standard is about the KIND, there is nothing
about accuracy, which is really a numerical issue.
for instance the standard just says (I think) that the result of x*y
must
be an _approximation_ (which approximation?) of the multiplication
of x by y, returned in the same KIND than x and y.
There's nothing about the result accuracy...
In other words a compiler may give: 1.0*2.0 -> 2.1 and be
standard conforming! (of course nobody would buy it, but this is
another issue)
> Specifying (2) does not allow the implementor to foolow (3)
> when appropriate. It completely prohibits (3) !!
It doesn't, as long as the results are identical
In fact, when writing this, I just understand that there is no way to
solve the DPROD problem without speaking about accuracy. And this is
very difficult (impossible?) in terms of standard... We just have
to rely on compiler vendors to produce "what is expected".
Regards
--
Pierre Hugonnet Seismic Data Processing R&D
COMPAGNIE GENERALE DE GEOPHYSIQUE
mail: 1 rue Leon Migaux phone.....(33) 164 47 45 59
91302 MASSY fax.......(33) 164 47 32 49
FRANCE [log in to unmask]
My opinions are not necessarily those of CGG
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|