From: Rich Townsend on
James Giles wrote:
> Rich Townsend wrote:
> ...
>
>>Well, I'm coming at things from a namespace standpoint. If each module
>>has a different prefixing scheme, then there's no need to worry about
>>namespace conflicts. Without the scheme (or some other approach), one
>>has to start using ONLY to do renaming -- and in my eyes that is a sin
>>before God. :)
>
>
> Well, I come at these things from the point of view
> of namespace management too. The only time I have
> more than one thing in a given scope with the same
> name is when it's generic. I tend to only use renaming
> for things from the dreaded "someone else's module".
> I have yet to need any prefix codes to tell me where
> things are from. Usually I don't care. If I do, I want
> very much to always be able to tell by looking at the
> local declarations. (I don't want to have to maintain
> a table of what prefix codes go with what module
> name either. I don't quite see how two letter prefixes
> can really be mnemonic.)
>

Let me give a concrete example, and see if you can suggest how to go
about things using your approach (which I'm interested to hear about --
if I can dump the prefixes with no consequences, then I'm all for it).
In my cubic spline module, there is a routine sl_interp_y(), which
performs spline interpolation on tabulated (ie, y vs. x) data. I also
have a module that provides a routine ft_interp_y() --- it does the same
operation, but uses linear interpolation instead of spline.

If I dumped the prefixes, then these two procedures would clash via the
TKR rules. Now, I could merge the routines; but I'd rather keep all the
spline stuff in the spline module, and all of the linear stuff in the
linear module. Any thoughts?

cheers,

Rich
From: Dan Nagle on
Rich Townsend wrote:

<snip>

> If I dumped the prefixes, then these two procedures would clash via the
> TKR rules. Now, I could merge the routines; but I'd rather keep all the
> spline stuff in the spline module, and all of the linear stuff in the
> linear module. Any thoughts?

Can you define a type for spline data, and another for the linear data?

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.
From: Rich Townsend on
Dan Nagle wrote:
> Rich Townsend wrote:
>
> <snip>
>
>> If I dumped the prefixes, then these two procedures would clash via
>> the TKR rules. Now, I could merge the routines; but I'd rather keep
>> all the spline stuff in the spline module, and all of the linear stuff
>> in the linear module. Any thoughts?
>
>
> Can you define a type for spline data, and another for the linear data?
>

Yes, I already have types, and routines that operate on them. But the
specific interpolation functions I mention above are "shortcut" routines
that operate on real array arguments. In essence, they do the following:

1) Create an appropriately-initialized instance of the type, from array
arguments
2) Pass the instance to the typed interpolation routine
3) Return the results to the caller
4) Throw away the instance; this is done implicitly, since the instance
(stored in a local var) goes out of scope at the end of the routine

cheers,

Rich
From: James Giles on
Dan Nagle wrote:
> Rich Townsend wrote:
>
> <snip>
>
>> If I dumped the prefixes, then these two procedures would clash via
>> the TKR rules. Now, I could merge the routines; but I'd rather keep
>> all the spline stuff in the spline module, and all of the linear
>> stuff in the linear module. Any thoughts?
>
> Can you define a type for spline data, and another for the linear
> data?

That was my first thought.

Another is to question how often (other than in testing) that you
have two different interpolation methods in use from within the
same scope? In most production code you would pick one
interpolation method (for speed or accuracy or the best compromise
between them) and not even USE the other. I can see that you might
USE both in a comparison - that perhaps is a classic, though rare,
need for a rename.

Finally (unless I think of something else later), this is actually
a case where traditionally the routines might have different names
anyway. It's just not usual that the difference necessarily has anything
to do with the location of the codes. Some people might have put
them in a single module of interpolation routines of which these
are two of many. Certainly in the old days they'd both likely be
in the same library of external procedures. The difference in
name is more related to what they do, not to where they're from.

I'd have to know more about why you need to access both in the
same scope before I could go any further on this. There are some
more choices in F2003 (type-bound procedures, for a start).

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


From: Rich Townsend on
James Giles wrote:
> Dan Nagle wrote:
>
>>Rich Townsend wrote:
>>
>><snip>
>>
>>>If I dumped the prefixes, then these two procedures would clash via
>>>the TKR rules. Now, I could merge the routines; but I'd rather keep
>>>all the spline stuff in the spline module, and all of the linear
>>>stuff in the linear module. Any thoughts?
>>
>>Can you define a type for spline data, and another for the linear
>>data?
>
>
> That was my first thought.
>
> Another is to question how often (other than in testing) that you
> have two different interpolation methods in use from within the
> same scope? In most production code you would pick one
> interpolation method (for speed or accuracy or the best compromise
> between them) and not even USE the other. I can see that you might
> USE both in a comparison - that perhaps is a classic, though rare,
> need for a rename.
>
> Finally (unless I think of something else later), this is actually
> a case where traditionally the routines might have different names
> anyway. It's just not usual that the difference necessarily has anything
> to do with the location of the codes. Some people might have put
> them in a single module of interpolation routines of which these
> are two of many. Certainly in the old days they'd both likely be
> in the same library of external procedures. The difference in
> name is more related to what they do, not to where they're from.
>
> I'd have to know more about why you need to access both in the
> same scope before I could go any further on this. There are some
> more choices in F2003 (type-bound procedures, for a start).
>

I'm interpolating variables relating to the internal structure of a
star. Some of these variables are guaranteed to vary smoothly, without
discontinuities (e.g., the pressure), and are therefore good candidates
for spline interpolation. Others can show discontinuities (e.g.,
Brunt-Vaiasala frequency, which shows a trapezoidal-like peak around the
cores of massive stars), and require linear interpolation, since splines
would introduce ringing around the discontinuity.

cheers,

Rich