SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 15 Feb 2004 01:03:31 PST8
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: PL/I most important statement (was: call(TZ) ? - PL/I)

Content Type: text/plain

On Sat, 14 Feb 2004 20:27:09 PST8, Lynn H. Maxson wrote:
>Gregory Smith wrote:
> >"...I am an engineer--I prefer Peter's approach. PL/I's
> >begin/end combination lets me think like an engineer. C's
> >malloc forces me to think like a programmer."

>Oddly enough when I want to allocate space dynamically for a
>matrix after I acquire the range in any dimension I use an
>'allocate' statement, if for no other reason than that's what I
>want to do. I would think an engineer would think like this.

That is thinking like a COMPUTER engineer--I am a CHEMICAL
engineer. Let me repeat what I said before:

(Non-computer) Engineer's and mathemetician's view:
I need a matrix of of size (x, y, z) for this next SERIES OF CALCULATIONS.

I added the emphasis for a reason. The begin/end construct not only does
memory management, it helps keep focus on the other objectives that I
find important. If I am designing a 200 tray distillation tower, I will
need to keep track of 202 liquid flows, 202 vapor flows, N tower liquid
feeds (n>=1, usually only one), N tower vapor feeds (n>=0, usually 0),
M tower products (M>=2, usually two to five), up to 202 energy inputs
(although two is usually sufficient), AND liquid and vapor compositions
on all 200 trays (which requires 200*I values for each phase if
there are I components in the feed, where 2

I prefer to organize my code around the SERIES OF CALCULATIONS
that I am doing:

/* get ntrays and icomp from design database */
.... code that sets ntrays and icomp ...
BEGIN /* Tower Calculations */
dcl Liq_Flow(ntrays+2)...
dcl Vap_Flow(ntrays+2)...
dcl Liq_Comp(ntrays,icomp)...
dcl Vap_Comp(ntrays,icomp)...
.... Design calculations for tower...
/* Save results in design database */
... code to save our results ...
END; /* Tower Calculations */

The BEGIN/END combination does a great job of bracketing
my series of calculations--and it ALSO handles memory allocation.

> ...

>For most of us non-programmers who think in terms of what
>we want to have happen when we no longer need a
>dynamically allocated variable, we can 'free' it. We can do it
>without any of the limitations imposed by a begin-block, i.e.
>within a specific, non-shared code segment.

> ... .

>I can understand why Bob reacts the way he does. I'm almost
>sorry that I even mentioned the two uses the PL/I authors had
>in mind for the 'begin' statement. That Peter found a third
>use to avoid an 'allocate' and 'free' while basically restricting
>his processing options does not change the PL/I authors initial
>intent.

Sure, 'allocate' and 'free' will do the same thing without
the limitations of a begin-block. So what if a begin-block
imposes additional limitations on the code. If the limitations
don't affect what *I* see as a logical sequence of calculations,
then I am happy. If the limitations get in the way, I will do away
with the begin block and clutter up the middle of my tower
calculations with 'allocate' and 'free' statements.

===============================================================
Gregory W. Smith (WD9GAY) gsmith@well.com
finger gsmith@well.com for PGP public key

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 15 | February | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.