robin wrote:
>
> >
> > REAL(selected_real_kind ( precision (1.0) + 1)) is also
> > identical if there is no intermediate precision between
> > default REAL and DOUBLE PRECISION kinds.
>
> Do you see a vendor providing such a one?
Up to now, clearly no.
But you cannot say that it will never be the case: Intel
architecture is based on 10bytes reals (I think). One could imagine
in the future compilers supporting 8bytes as REAL, 16bytes
as DOUBLE PRECISION, and in between 10bytes because it's
the native format. I don't know if it's realistic, but it could
happen.
>
> > > 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.
> >
> > It definitly doesn't: if I need 12 digits,
>
> It definitely does in the context of your original post, which
> is what we were discussing [quoted from above]:
>
> "> > > 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) ) etc"
>
> > I can't use default REAL, since it is only 6 digits on most
> > 32bits machines.
>
> But you were saying that you use a 64-bit machine.
> Default real there is 15 or so digits.
>
I use both 32bits and 64bits machines, and I want portable code
which efficiently run on both (and also on other possible
machines). I don't write code for a given a priori machine.
> > selected_real_kind ( precision (1.0) + 1) is OK on 32bits
> > machines, but will give a ~30 digits
> > kind (128bits) on some 64bits machines (Cray). default REAL
> > (15 digits) would have been prefered, since 128bits kinds
> > are generally software emulated and require more storage.
>
> And here [above] you confirm it.
>
I just point the behaviors on both machines
> To address this problem, you merely have to use
> SELECTED_REAL_KIND (15).
Yes, and it has been showed that in that case
you cannot define generic interfaces...
Moreover, YOU claimed that libraries should be written
using REAL and DOUBLE PRECISION (or equivalent)
>
> > If my algorithm requires some variables with 24 digits precision,
> > you can not say it's excessive precision!
>
> Of course I can say that. It's excessive precision
> because it's not available on most systems (about 99.9% of them).
> Did you read what I wrote above? :
> "> > It's excessive precision because not many machines
> > > support 24 digits. To be portable, about 15 digits is
> > > the maximum that can be "guaranteed". "
Then quadruple precision should never be used ?
>
> > If you have a little moment, please could you write
> > for me a library containing the previously described example of "mysum",
> > with a generic interface, which is portable (assuming 24 digits
> > precision exists),
>
> [Isn't this an oxymoron? 24 digits does not exist in any way
> as portable.]
>
> > and which does not use more
> > memory and CPU than necessary. I'm almost sure that you can
> > not meet all of these requirements, but let's see...
>
> Anyway, we all have gone to some length to show you how
> this can be done. We have produced examples of declarations.
Then it's easy: you just have to copy-paste the example and
repost it :-)
Best regards
--
+-----------------------------------+----------------------------+
| Pierre Hugonnet | mail....CGG |
| | 1, rue Leon Migaux |
| Seismic Data Processing R&D | 91341 MASSY cedex |
| | FRANCE |
| COMPAGNIE GENERALE DE GEOPHYSIQUE | phone...(33) 164 47 45 59 |
| Massy processing centre (France) | fax.....(33) 164 47 32 49 |
| http://www.cgg.com | [log in to unmask] |
+-----------------------------------+----------------------------+
My opinions are not necessarily those of CGG
--------------------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|