Re: Reference to derived type element by index?
- From: nospam@xxxxxxxxxxxxx (Richard Maine)
- Date: Thu, 3 Apr 2008 10:03:22 -0700
*** Hendrickson <***.hendrickson@xxxxxxx> wrote:
Rob Crain wrote:
I have a derived type,...
and want to refer to the individual elements via some indexing scheme,
It's kind of an odd thing to do (IMO) and there's lots of
ways to do it.
Addressing the "odd thing to do" part, I'll note that I have done
generally simillar things fairly often. And I see others do them as
well. I'm applying a slight abstraction here to get to alevel at which I
see the simillarity. The part that I see as generally simillar is
wanting to refer to a set of values sometimes as an array and sometimes
as a set of distinctively-named scalars.
It doesn't even have to be in the context of derived type components. I
used to do this with common blocks a lot. In one scope, the common block
would have a list of scalars. In another scope, the same common block
would be a single array. (Or these two uses might even be in the same
scope, via the wonders of equivalence). I'd say this kind of thing was
fairly common. I've had people (including my wife) point out that
modules aren't quite as handy as common/equivalence for this particular
need.
Yes, there are multiple ways to do it. I often use the method (suggested
by a few people in this thread), of making the actual variable be an
array and then having named constants for the index values. That ends up
with syntax such as "some_array(i_alpha)" instead of just "alpha", but
it sure beats "some_array(42)". I've also done the aproach of making
scalar pointers to the array elements, which was also mentioned here. Or
I've done the thing with maintaining two copies and doing
copy-in/copy-out, but that can be a pain to make sure that the right
values are always in the right places (and it can be a big performance
hit). Equivalence seems like a "natural", but it doesn't work with
dynamic sizing, or much of dynamic anything. Several of the methods
apply only to a single object and have to be completely replicated in
the source code if you ever have more than one instance of an object at
the same time (for a simple example, if you have two variables of the
derived type here - this isn't exactly as esoteric as the "multiple
instances" terminology might sound).
Typical of where I see it come up is in the connection between a general
algorithm and a specific application of the algorithm, when a system of
equations is involved. The general algorithm for doing something with a
system of equations is typically going to be expressed in array terms.
The specific system of equations, however, might well be more naturally
written with multiple scalar variables.
For example, the equations for aircraft dynamics are usually going to
"want" to be written in terms of scalars such as the above-mentioned
alpha (angle of attack), q (pitch rate), etc.
But if I then want to, say, apply some algorithm for numerical solution
of differential equations, that algorithm is going to be expressed in
terms of a state vector; it won't care at all that state number 42
happens to be alpha.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.
- References:
- Re: Reference to derived type element by index?
- From: jwm
- Re: Reference to derived type element by index?
- From: *** Hendrickson
- Re: Reference to derived type element by index?
- Prev by Date: glibc detected *** ./run.out: munmap_chunk(): invalid pointer:
- Next by Date: Re: unresolved external symbol
- Previous by thread: Re: Reference to derived type element by index?
- Next by thread: Re: Reference to derived type element by index?
- Index(es):