<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<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]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>Van
and Everyone Else:<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'> So
for this reason alone, refactoring is very strongly recommended.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>Sincerely,<o:p></o:p></span></p>
<p class=MsoNormal><b><span style='font-size:12.0pt;font-family:"Century Schoolbook","serif";
color:teal'>Craig T. Dedo<o:p></o:p></span></b></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>17130
W. Burleigh Place<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'>Brookfield,
WI 53008-0423 E-mail: <<a
href="mailto:craig@ctdedo.com">craig@ctdedo.com</a>><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>USA<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>Linked-In:
<a 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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>-----Original
Message-----<br>
From: j3-bounces@j3-fortran.org [mailto:j3-bounces@j3-fortran.org] 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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;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:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>_______________________________________________<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>J3
mailing list<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>J3@j3-fortran.org<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'>http://j3-fortran.org/mailman/listinfo/j3<o:p></o:p></span></p>
<p class=MsoPlainText><span style='font-size:10.0pt;font-family:"Century Schoolbook","serif"'><o:p> </o:p></span></p>
</div>
</body>
</html>