If additional control were given over the details of SUM(), it would be wanted also for intrinsics such as DOT_PRODUCT() and
MATMUL(). If we renew the argument that there should be no DOT_PRODUCT(), then SUM(A*DBLE(B)) or
SUM(A*REAL(B,KIND(SELECTED_REAL_KIND(PRECISION(B)+3)))) might do, if I could keep track of the parens.
----- Original Message -----
From: "Phillip Helbig" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, September 21, 2000 9:59 AM
Subject: Re: Single/double precision in summation
> > > > On Wed, 20 Sep 2000, W. J. Metzger wrote:
> > > > > How about sumx = sum( real( x, kind(0d0) ) )
> > > >
> > > > I would expect this to create a large temporary array, which
> > > > has got to be a net loss.
> > > >
> > > > It would be great if SUM could accept an optional KIND argument
> > > > which specifies the precision at which the summation is done.
> > >
> > > It seems to me that this wouldn't matter. The standard doesn't specify
> > > how things are done internally. ...
> >
> > Obviously (but maybe not :-) ), what I am proposing the optional
> > KIND argument would do would be to specify how things are done
> > internally, for this function.
>
> Right, but the above, or sumx = sum(dble(x)) seems to me to say the same
> thing---some the double-precision version of x. I think it would be a
> departure from previous practice if the standard didn't specify what was
> done internally here, but did for an optional argument.
>
> Pessimists say that it is quality of implementation. Perhaps. But the
> above DOES say that the double-precision version of x is to be summed,
> and it would be good quality if an unnecessary temporary array were not
> created.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|