Pierre Hugonnet wrote:

> 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,

It doesn't take "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...

Yes, and there were often (programming) errors introduced
because of that.

Now, with interfaces/modules, not only can calling be
automated and simplified, it's error-free, and you get
a compile-time error message if you make a mistake.

Many of us have adopted the modern facilities of F90/95,
because they offer considerable savings in preparation and
debugging time.

> > 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.

With a wrapper, you can still use it, and can have an automated
error-free interface as well.

> > > 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.

Nonsense.  The F compiler does not even have DOUBLE PRECISION !
(but it does have real (kind= . . . )

> > 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.

I (and others) have said that this is not so.  We have demonstrated it.

> 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)

You're safer without the "r" option, as there's no guarantee
that these figures can be universally met, esp. the 2500.

> It doesn't need to be part of the standard, but it could be
> a "standard" extension module (such as ISO_VARYING_STRING)

No need to.  Anyway, if you want one, it's so easy to write
such a module containing 3 declarations.

Conditional compilation sounds like a good idea.

> 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)

No problem wth libraries and single/double, as Fortran
must have at least two real kinds.  The intrinsics PRECISION
and/or SRK can be used to guarantee that the kinds are unique.

With three or more real kinds available, explicit calls to
procedures using the third or fourth real kind
would be necessary so as to maintain portability.
But precision for all could be specified using SRK.

> 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
> ------------------------------------------------------------------------------
> --




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