Malcolm Cohen wrote:
>
> I would think that using the intrinsic DOT_PRODUCT would be the obvious
> thing to do here (I believe all the BLAS 1 and 2 routines have "obvious"
> translations into intrinsic F90 functions).
dot product was just an example. Consider routines which do
not have intrinsic equivalent (or even dot product on >1 dimension
arrays, or NRM2(),...).
>
> OTOH you can provide the generic interface yourself, and this is not
> terribly hard to do.
>
It isn't hard, simply requires a lot of time, especially if you
use many libraries on many platforms... I consider this is a
waste of time. In the old days we didn't have to do that...
>
> Perhaps you've not seen many Fortran 90 libraries? (You did say that
> you used only F77 and not F90, so this is not an unlikely deduction!)
> Several of the ones I have seen (including our own) provide a generic
> interface.
>
I DO use F90. What I said is that F77 is still the "standard" langage
of our data processing software, so that I'm forced to use it
more than I would like.
> > the many free libraries, and the libraries you write yourself?
> > This kind of interface is processor-dependant (one version of the
> > routine for each kind value supplied by the compiler), so that it
>
> Yes, if the number of real kinds is not the same then the library cannot
> be written portably - because either it supplies 2 or 3 or 4 routines.
> (Assuming it wants complete coverage of REAL kinds - not necessarily true).
>
> OTOH, it is possible (and easy) to design the library to be *called* portably,
> simply by using generics.
>
According to my experience it is not so easy. The key point being
the correspondance between the kinds used in the library and the
kinds used in a calling program. It turns out in fact that you
always need to assume that you are using the default REAL and
DOUBLE PRECISION kinds, even hidden by the SELECTED_REAL_KIND mechanism.
Using SELECTED_REAL_KIND without any (implicit) reference to
REAL or DOUBLE PRECISION is almost impossible.
>
> If you restrict yourself to (default) REAL and DOUBLE PRECISION it is trivial
> to do it portably. If you don't so restrict yourself then
> (a) using just REAL and DOUBLE PRECISION does not work (duh!)
> (b) portability (of the library code itself) necessarily goes out the window
> if you want to use machines with different numbers of real kinds.
>
That's why I say that SELECTED_REAL_KIND doesn't bring any advantage
in terms of portability: if you want to be portable, you are
forced to use REAL and DOUBLE PRECISION.
In a not so distant past, I proposed to define "standard" real
kind constants, which could be commonly accepted as references:
ISO_REAL_KIND_1 = SELECTED_REAL_KIND(p=6,r=25)
ISO_REAL_KIND_2 = SELECTED_REAL_KIND(p=12,r=250)
ISO_REAL_KIND_3 = SELECTED_REAL_KIND(p=24,r=2500)
It doesn't need to be part of the standard, but it could be
a "standard" extension module (such as ISO_VARYING_STRING)
With these constants, libraries could be easily written and called
portably (with the help of conditionnal compilation, since
the constants could be equals, or equal to -1)
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
--------------------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
