<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Craig Dedo wrote:
<blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAEm5zvsZia5MkUMdZm8pSmTisgAAEAAAAKZoHuUc7vpJpIQIzMoQkioBAAAAAA==@ctdedo.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Century Schoolbook";
panose-1:2 4 6 4 5 5 5 2 3 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="Section1">
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">Van
and Everyone Else:<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">
Unfortunately
for Van, this particular situation does not seem to make a strong
argument for
coroutines. To me, it does not seem worthwhile to develop a complex
new
feature when good quality solutions are already available, using
features that
are already in the language.<o:p></o:p></span></p>
</div>
</blockquote>
<br>
Perhaps Craig didn't read the first word of the subject.<span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p><br>
<br>
</o:p></span>
<blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAEm5zvsZia5MkUMdZm8pSmTisgAAEAAAAKZoHuUc7vpJpIQIzMoQkioBAAAAAA==@ctdedo.com"
type="cite">
<div class="Section1">
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">
It
seems to me that you have already hit upon the best solution. Use
allocatable arrays and put them into a module. If the program is not
straining
the memory resources of the computer you are using, then also use the
SAVE
attribute. In order to avoid the problem of mis-matched allocations
and
deallocations, write a procedure to do all of the allocations at once
and a
second procedure to do all of the deallocations at once. Properly
written, they should be mirror images of each other and it should be
easy to
compare whether an array is mentioned in one and not in the other.</span></p>
</div>
</blockquote>
<br>
I'm not as dense as Craig's explanation suggests. I have two choices:
(1) use the SAVE attribute if the same arrays are to be used for
hundreds of invocations with different path lengths, or (2) put the
variables in a subroutine with internal subroutines, and put the loop
over paths in the outer subroutine.<br>
<br>
Automatic variables in a coroutine have an implicit "save until return,
even if suspend intervenes" attribute, which is exactly what I need.<br>
<br>
<blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAEm5zvsZia5MkUMdZm8pSmTisgAAEAAAAKZoHuUc7vpJpIQIzMoQkioBAAAAAA==@ctdedo.com"
type="cite">
<div class="Section1">
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">
Yes,
a procedure of 3784 source lines of code (SLOC) is overdue for
refactoring. In fact, a procedure of this length is almost begging for
the presence of several (or many) serious defects. The best research
shows that the defect rate (i.e., # defects / KSLOC) is constant below
200
executable statements per procedure. The defect rate increases
linearly
above 200 executable statements per procedure. Thus, a 1 KSLOC
procedure
has a defect rate 5 times that of a 200 SLOC procedure, a 2 KSLOC
procedure 10
times, and a 3.8 KSLOC procedure 19 times.<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">
So
for this reason alone, refactoring is very strongly recommended.</span></p>
</div>
</blockquote>
<br>
I'm not as dense as Craig suggests. It is already factored into dozens
of internal subroutines. At least part of the problem is that the
module procedure is so big.<br>
<br>
<blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAEm5zvsZia5MkUMdZm8pSmTisgAAEAAAAKZoHuUc7vpJpIQIzMoQkioBAAAAAA==@ctdedo.com"
type="cite">
<div class="Section1">
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">
Then
there is the issue of human understandability. A procedure of 3784
SLOC
is highly unlikely to be understood by mere mortals. Even a
super-genius
would have a hard time understanding all of it. The best research
shows that
understanding is at its best at 200 SLOC or less. As length increases
over 200 SLOC, understanding goes down. You might notice a similarity
with
what I wrote 2 paragraphs back. Yes, understanding and defect rates
are inversely
and strongly correlated. As understanding goes down, defect rates go
up.</span></p>
</div>
</blockquote>
<br>
Automatic arrays require only declaration. My practice is to declare
each one in a separate statement with a comment about its usage.
Explicit allocation and deallocation requires at least two more
statements. In our case, we have a department standard that the status
of every allocation and deallocation is checked. This either requires
another statement per allocation and deallocation, or encapsulating the
allocation and checking in one routine, and the deallocation and
checking in another one. I can't (yet) use the distinction between
allocatable and pointer attributes for generic resolution, so I need
two sets of generics, one for pointers and one for allocatables. Not
using automatic variables increases the bulk of the part of the program
that creates these variables by a factor of three or five.<br>
<br>
<blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAEm5zvsZia5MkUMdZm8pSmTisgAAEAAAAKZoHuUc7vpJpIQIzMoQkioBAAAAAA==@ctdedo.com"
type="cite">
<div class="Section1">
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">
There
is a second understandability issue. You mention an “already-long
calling sequence”. This suggests that you have a very lengthy
argument list. If there are more than 7 arguments in the argument
list,
then understanding will also go down. This is because human short-term
memory is limited to around 7 items, i.e., the average person can keep
track of
7 items at one time. Above that, confusion starts to set in and
understanding starts to degrade. Another good place for using module
data.</span></p>
</div>
</blockquote>
<br>
OK, I have mixing ratio, temperature, absorption cross section per
molecule, total absorption cross section, incremental optical depth,
transmissivity, the derivatives of each of these things with respect to
mixing ratio, temperature, spectral line centers, spectral line widths,
sensitivity of spectral line widths with respect to temperature, ...,
all of this on a coarse grid (for rectangular quadrature) and a fine
grid (for Gaussian quadrature). Add to that arrays that specify where
Gaussian quadrature is needed instead of where rectangular quadrature
is needed, and the magnetic field. That's just the arrays that depend
upon path length. Then there are the frequencies, the filter shapes,
the antenna patterns, which chemical species are modeled line-by-line
and which ones channel-by-channel, the pressure grid, the relationship
between pressure and height (so it doesn't have to be recalculated from
temperature and pressure using hydrostatic equilibrium on every
invocation), and the output radiances and Jacobians, convolved with the
filter shapes and antenna patterns. This list is from memory, so I'm
sure there are more. Anyway, it's way beyond seven, without much hope
of reducing the list below seven.<br>
<br>
Some problems are inherently complicated.<br>
<br>
<blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAEm5zvsZia5MkUMdZm8pSmTisgAAEAAAAKZoHuUc7vpJpIQIzMoQkioBAAAAAA==@ctdedo.com"
type="cite">
<div class="Section1">
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">
Hope
this helps. Please let me know how things work out. Please feel
free to contact me at any time with any questions or concerns that you
may have.
I am looking forward to hearing from you soon.</span></p>
</div>
</blockquote>
<br>
It was no help whatsoever.<br>
<br>
<blockquote
cite="mid:!&!AAAAAAAAAAAYAAAAAAAAAEm5zvsZia5MkUMdZm8pSmTisgAAEAAAAKZoHuUc7vpJpIQIzMoQkioBAAAAAA==@ctdedo.com"
type="cite">
<div class="Section1">
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">Sincerely,<o:p></o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size: 12pt; font-family: "Century Schoolbook","serif"; color: teal;">Craig
T. Dedo<o:p></o:p></span></b></p>
<p class="MsoNormal"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">17130
W. Burleigh Place<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">P.
O. Box
423
Mobile Phone: (414) 412-5869<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">Brookfield,
WI 53008-0423 E-mail: <<a moz-do-not-send="true"
href="mailto:craig@ctdedo.com">craig@ctdedo.com</a>><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">USA<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">Linked-In:
<a moz-do-not-send="true" href="http://www.linkedin.com/in/craigdedo">http://www.linkedin.com/in/craigdedo</a><o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">-----Original
Message-----<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:j3-bounces@j3-fortran.org">j3-bounces@j3-fortran.org</a> [<a class="moz-txt-link-freetext" href="mailto:j3-bounces@j3-fortran.org">mailto:j3-bounces@j3-fortran.org</a>] On
Behalf Of
Van Snyder<br>
Sent: Friday, January 29, 2010 15:17<br>
To: j3<br>
Subject: (j3.2006) Another application for coroutines<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">During
the 2008 requirements phase, I advocated coroutines to ease "reverse
communication" in library codes that need access to user code.<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">I've
recently encountered another circumstance where a coroutine would be
helpful.<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">The
program of my current responsibility integrates the radiative transfer
equation
through the limb of the Earth's atmosphere, from space to our
instrument.
The instrument's antenna points at about 70 angles over a period of
about 26
seconds. Therefore, each path through the atmosphere is of a different
length.<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">The
procedure that does the integration has about three dozen arrays with
at least
one dimension that depends upon the path length, and upon the
discretization of
the path (which is determined by input data).<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">To
avoid a trip to the allocator (and deallocator) for each pointing, we
allocate
these arrays once for each scan, for the path of longest length, as
automatic
arrays.<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">For
a variety of reasons, only a few having to do with these arrays, this
subroutine has become enormous (3784 lines). I'd like to break it up.
So as not to add three dozen arrays to an already-long calling
sequence, I'd
like to continue to access them either locally or through host
association.<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">An
obvious way to handle this is to convert them from automatic to
allocatable,
either put them in a module or make them save variables, and add the
appropriate explicit allocations and deallocations. This risks failing
to
deallocate a new one someday, if I have to add one (which I've had to
do
several times).<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">One
advantage of automatic variables, compared to allocatable ones, is that
you
can't forget to deallocate them (which I would have to do to get rid of
them if
they're save variables). Another potential advantage is that the
processor might make one trip to the allocator to get them all in one
gulp,
then calculate its descriptors. I don't know whether this actually
would
be an advantage, or if so whether any processor exploits it.<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">If
these variables were automatic variables in a coroutine, it could be
called to
get them created and to do some preliminary calculations necessary for
all
paths. Then it would suspend instead of returning, thereby preserving
its
activation record. It would be resumed for each path, and would
finally
return after the last path, at which time the arrays would be
deallocated.<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">_______________________________________________<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";">J3
mailing list<o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><a class="moz-txt-link-abbreviated" href="mailto:J3@j3-fortran.org">J3@j3-fortran.org</a><o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><a class="moz-txt-link-freetext" href="http://j3-fortran.org/mailman/listinfo/j3">http://j3-fortran.org/mailman/listinfo/j3</a><o:p></o:p></span></p>
<p class="MsoPlainText"><span
style="font-size: 10pt; font-family: "Century Schoolbook","serif";"><o:p> </o:p></span></p>
</div>
</blockquote>
<br>
</body>
</html>