Pierre Hugonnet wrote:

> robin wrote:
> >
> > > > selected_real_kind ( precision (1.0) + 1)
> > > >
> > > > which should give a different kind from that for 1.0.
> > >
> > > This goes totally against SELECTED_REAL_KIND spirit, whose
> > > intent is to request a given precision.
> >
> > And indeed it does [request a given precision]. It gives you
> > a different precision from that of 1.0, and resolves the generic
> > resolution problem that you were concerned about.
>
> It DOES NOT request a given precision:

Let's assume that PRECISION (1.0) returns the value 6.
PRECISION (1.0)+1 yields 7.
With this "7",  SELECTED_REAL_KIND selects a kind
that gives at least 7 decimal digits' accuracy.

It looks very much to me that SRK is requesting a given precision.

> it requests a precision greater
> than default REAL, that's all, like DOUBLE PRECISION (and I prefer
> this latter, which is more readable than
> selected_real_kind ( precision (1.0)) + 1) )

Be that as it may, at least two subset compilers do not accept
"DOUBLE PRECISION".

And DOUBLE PRECISION does not work with COMPLEX.
With COMPLEX, you need to use something like that
which we have already elucidated, in order to obtain a
precision grreater than single precision.

> Requesting a given precision is specifying explicitly the precision
> you want (p=6, p=12, ...)

which is what " selected_real_kind ( precision (1.0) + 1)" does.
Or would you rather have:

 selected_real_kind (p= precision (1.0) + 1)   ?

> > > SUBROUTINE mysum_double(a)
> > > DOUBLE PRECISION :: a(:)
> > > REAL(selected_real_kind(precision(1.0d0)+1)) :: accu
> >
> > This specifies quadruple precision, and would
> > not be portable.
>
> And do you have a portable way to specify quad precision ? :-)

Indeed.

> > > SUBROUTINE mysum_12(a)
> > > REAL(selected_real_kind(p=12)) :: a(:)
> > > REAL(selected_real_kind(p=24)) :: accu
> >
> > Again, this may get into trouble, as it's excessive
> > precision.
>
> It may get into trouble...
> But it's NOT excessive precision:

It's excessive precision because not many machines
support 24 digits.  To be portable, about 15 digits is
the maximum that can be "guaranteed".

> if I really need
> to process data with 12 digits accuracy, I may
> need intermediate variables with 24 digits.
>
> I'm not sure that you caught my problem:

You can be sure that I did.

> INTERFACE mysum
>    MODULE PROCEDURE mysum_single, mysum_double
> END INTERFACE
>
> ...
>
> SUBROUTINE mysum_single(a)

> REAL :: a(:)
> DOUBLE PRECISION :: accu
>
> accu = 0.0
> DO i=1,size(a)
>    accu = accu + a(i)
> END DO
> mysum_single = accu
>
> END SUBROUTINE
>
> I want to process data with 6 digits accuracy: in the main I declare
> REAL(selected_real_kind(6)) :: array(n)
>
> On a 32bits machine where REAL is 6 digits and DOUBLE 12 digits,
> array(:) is REAL:
> the routine sums array using a 12 digits accumulator to reduce
> round-off problems. This is exactly what I want.
>
> On a 64bits machine where REAL would be 15 digits and DOUBLE 30 digits,
> array(:) is still REAL:
> the routines sums array using a 30 digits accumulator. I will
> give a good result, but 30 digits is much more than I actually
> need, leading to wasted CPU time.
>
> The solution could be:
> REAL(selected_real_kind(p=12)) :: accu
>
> But now It doesn't work if I process data with 12 digits
> accuracy (REAL(selected_real_kind(12)) :: array(n))  :
> I really need a 24 digits accumulator.
>
> I'm sorry, but I don't see any solution to this. I you
> have one, I'm very interested in...

We have already showed you.

> > > But now I can't define a generic name, since the kinds are
> > > identical.
> >
> > We showed you how to resolve this before.
>
> Not at all: I showed that either you define the libraries with
> REAL and DOUBLE PRECISION, then you can have generic interfaces but
> little control over the used precisions, or you
> define libraries with SELECTED_***, then you have the full control of
> the precisions but without generic interfaces.

We already showed you how SRK allows you to have generic
interfaces.

> Best Regards
> +-----------------------------------+----------------------------+
> |          Pierre Hugonnet          | mail....CGG                |



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