| Re: new to IDL - question about modularity [message #54569] |
Mon, 25 June 2007 17:16 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
little davey writes:
> I like common blocks, and I'll tell you why. I am a meteorologist who
> fully takes advantage of the big "I" in IDL...interactive. I develop
> algorithms, that is, I play the "Let's Try This" game professionally.
> COMMON blocks are the way to go for this kind of work.
Guess I must have missed that memo. I've been learning
by noodling around in IDL for nearly 20 years, and I've
never once thought I needed a common block for interactive
work. :-(
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: new to IDL - question about modularity [message #54570 is a reply to message #54569] |
Mon, 25 June 2007 16:19  |
little davey
Messages: 5
Registered: June 2007
|
Junior Member |
|
|
On Jun 25, 10:17 am, Paul van Delst <Paul.vanDe...@noaa.gov> wrote:
> David Fanning wrote:
>> Josh writes:
>
>>> despite having five manuals on IDL in front of me, I'm having some
>>> trouble with writing modular code. I think it lies in my lack of
>>> understanding of the structure, but hopefully it's a simple issue...
>
>>> I'm using IDL 6.3, and have written a single .pro file that looks
>>> like,
>
>>> pro xxx
>>> ...
>>> end
>
>>> pro yyy
>>> ...
>>> end
>
>>> pro zzz
>>> ...
>>> end
>
>>> in an effort to break up the tasks to be done. However, within the
>>> zzz procedure I would like to access an array that was built in the
>>> xxx procedure. I realize that's not possible, and was hoping for some
>>> guidance as to a better way to do this.
>
>> The simplest way to do this, and maybe the only way if
>> there is really no connection between the three modules
>> in your example, is to use a common block to store the array.
>
> A common block? Shock, horror, and gasp! :o0
>
> Just kidding :o) But, I don't think the OP has provided enough information to suggest
> them as the first possible solution in a list. I would prefer encapsulation of all the
> relevant data in a structure (or object) depending on, among other things, computational
> cost, complexity, etc.
>
> - If the array in question that was built in xxx is cheap to construct, then perform that
> construction in a separate function/pro and call it where it's needed - in both xxx and zzz.
> - If the array built in xxx is *not* cheap to construct, then consider the use of a
> structure (think of it like an object, let's call it the "abc" object) to carry all your
> information - that is, the result of xxx and the intermediate data that other "abc"
> methods may need.
>
>> If there is a connection (e.g., zzz calls xxx), then you
>> can pass information around by means of output keywords
>> or even pass a pointer variable around that can be filled
>> out by individual modules.
>
>> There really should be some kind of connection, or these
>> procedures shouldn't be in the same file. That is to say,
>> the only reason xxx and yyy should be in the same file
>> as zzz is that they are utility routines for zzz. Thus,
>> a common block is rarely (I almost said never) needed.
>> They should be able to pass all their information via
>> keywords and parameters. :-)
>
> I reckon a structure is the go. Or maybe even an object depending on the comfort level of
> the OP in using them.
>
> cheers,
>
> paulv
>
> --
> Paul van Delst Ride lots.
> CIMSS @ NOAA/NCEP/EMC Eddy Merckx
I like common blocks, and I'll tell you why. I am a meteorologist who
fully takes advantage of the big "I" in IDL...interactive. I develop
algorithms, that is, I play the "Let's Try This" game professionally.
COMMON blocks are the way to go for this kind of work.
I write modules that I want to type in at the command line. If I have
to append either a parameter list of variables, or a structure such as
temp.level.pres.850, this defeats the purpose of Interactive.
If you WANT or NEED to write software that has attributes of being
fully independent, maintainable, algorithm is hidden, or any of the so-
called advantages that I learned in my C++ class, fine. However, as a
"Try This" person, I can honestly say that none of those have much
relevance during scientific development. (Getting the final algorithm
put into operations, ok, THEN re-write).
-- Dave K --
|
|
|
|
| Re: new to IDL - question about modularity [message #54571 is a reply to message #54570] |
Mon, 25 June 2007 08:28 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paul van Delst writes:
> I reckon a structure is the go. Or maybe even an object depending on the comfort level of
> the OP in using them.
I expect he will be in touch with you. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: new to IDL - question about modularity [message #54572 is a reply to message #54571] |
Mon, 25 June 2007 08:17 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
David Fanning wrote:
> Josh writes:
>
>> despite having five manuals on IDL in front of me, I'm having some
>> trouble with writing modular code. I think it lies in my lack of
>> understanding of the structure, but hopefully it's a simple issue...
>>
>> I'm using IDL 6.3, and have written a single .pro file that looks
>> like,
>>
>> pro xxx
>> ...
>> end
>>
>> pro yyy
>> ...
>> end
>>
>> pro zzz
>> ...
>> end
>>
>> in an effort to break up the tasks to be done. However, within the
>> zzz procedure I would like to access an array that was built in the
>> xxx procedure. I realize that's not possible, and was hoping for some
>> guidance as to a better way to do this.
>
> The simplest way to do this, and maybe the only way if
> there is really no connection between the three modules
> in your example, is to use a common block to store the array.
A common block? Shock, horror, and gasp! :o0
Just kidding :o) But, I don't think the OP has provided enough information to suggest
them as the first possible solution in a list. I would prefer encapsulation of all the
relevant data in a structure (or object) depending on, among other things, computational
cost, complexity, etc.
- If the array in question that was built in xxx is cheap to construct, then perform that
construction in a separate function/pro and call it where it's needed - in both xxx and zzz.
- If the array built in xxx is *not* cheap to construct, then consider the use of a
structure (think of it like an object, let's call it the "abc" object) to carry all your
information - that is, the result of xxx and the intermediate data that other "abc"
methods may need.
> If there is a connection (e.g., zzz calls xxx), then you
> can pass information around by means of output keywords
> or even pass a pointer variable around that can be filled
> out by individual modules.
>
> There really should be some kind of connection, or these
> procedures shouldn't be in the same file. That is to say,
> the only reason xxx and yyy should be in the same file
> as zzz is that they are utility routines for zzz. Thus,
> a common block is rarely (I almost said never) needed.
> They should be able to pass all their information via
> keywords and parameters. :-)
I reckon a structure is the go. Or maybe even an object depending on the comfort level of
the OP in using them.
cheers,
paulv
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
|
|
|
|
| Re: new to IDL - question about modularity [message #54581 is a reply to message #54572] |
Fri, 22 June 2007 19:46 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Josh writes:
>
> despite having five manuals on IDL in front of me, I'm having some
> trouble with writing modular code. I think it lies in my lack of
> understanding of the structure, but hopefully it's a simple issue...
>
> I'm using IDL 6.3, and have written a single .pro file that looks
> like,
>
> pro xxx
> ...
> end
>
> pro yyy
> ...
> end
>
> pro zzz
> ...
> end
>
> in an effort to break up the tasks to be done. However, within the
> zzz procedure I would like to access an array that was built in the
> xxx procedure. I realize that's not possible, and was hoping for some
> guidance as to a better way to do this.
The simplest way to do this, and maybe the only way if
there is really no connection between the three modules
in your example, is to use a common block to store the array.
If there is a connection (e.g., zzz calls xxx), then you
can pass information around by means of output keywords
or even pass a pointer variable around that can be filled
out by individual modules.
There really should be some kind of connection, or these
procedures shouldn't be in the same file. That is to say,
the only reason xxx and yyy should be in the same file
as zzz is that they are utility routines for zzz. Thus,
a common block is rarely (I almost said never) needed.
They should be able to pass all their information via
keywords and parameters. :-)
http://www.dfanning.com/tips/namefiles.html
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
