Re: example of KIND to replace DOUBLE PRECISION

Jason Blevins <jrblevin@xxxxxxxxxxxxxxxx> wrote:

It's still a little unclear to me how to manage kinds in the context of
a program that uses multiple libraries, each with their own working
precision kind parameters defined.

In the context of a single self-contained program or library, I would
simply define a working precision kind parameter and use it uniformly
throughout the program. For a program which uses a single external
library, say LAPACK95, I would probably use the precision parameters
defined by the library:

use la_precision, only: wp

However, what do you do when you need to use multiple libraries?

Most commonly, you would not use precision parameters from such
libraries at all. You would use your own precision parameters. The
library should have generic procedure names, so you just invoke the
procedures with their generic names and you will get the right version
for whatever precision you are using. This doesn't involve using
precision parameters from the library at all.

If you aren't familiar with generic procedures, you'll likely be
confused by the above because generics are the crux of the whole idea.

And it is important to note that you do not need to use the kind
parameter

(Or, when you're designing a library that would likely be used
with others?)

Now that's more work, particularly when you have to deal with supporting
multiple environments that have different numbers of precision options
(notably if some of the environments have a quad real and others don't).
I don't think I'll try to go into that one here. It is a harder question
(but fortunately, one that fewer people have to deal with; it's a
question for the library writers more than for the library users).

What happens if I call a routine from library_b using x and y
if the kinds happen to be different?

call b_routine(x, y)

Is this handled automatically by casting or does it only work if the
kind parameters are identical?

There is no casting in Fortran. (There are some mixed-mode operations,
but that's not the same thing). The actual and dummy arguments must
match. The library could choose to explicitly provide a version of the
subroutine that had the mixed kinds, but that would pretty quickly get
out of hand in the general case. That's much of why I talk about the
precision used on a whole application basis. You can't expect to
indivually select the precision of every separate object in your program
and get anything but a mess. (Besides, it would be too much bother to go
through deciding exactly what each object needed.) Instead, you select a
precision that pretty much the whole app will use for most things; you
can have exceptions where something uses a different precision, but they
need to be a relatively small number of exceptions to keep things under
control.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
.