Python advocacy in scientific computation

[David Treadwell]

On Mar 4, 2006, at 11:16 PM, Dennis Lee Bieber wrote:

> On Sat, 4 Mar 2006 14:23:10 -0500, David Treadwell
> <i.failed.turing.test at gmail.com> declaimed the following in
> comp.lang.python:
>
>> needed programming, be it CS or chemical engineering, taught it in  
>> a  wlfraed at ix.netcom.com
>> very linear, bottom-up fashion. First you read inputs, then do Foo,
>> then do Bar, then do (fill in your favorite third-level word).
>>
> 	Doesn't quite sound like what was "bottom up" in my day... Sounds
> like an common "input, process, output" design.

Well, you're right about my description--that's what the program  
ended up looking like. It wasn't the way it was written.

Usually, I'd do it more like this:

Find or derive the formula of interest.
Translate the formula into ForTran  (hmmm ... catchy name for a  
language!)
Put the minimum number of statements around the formula to get it to  
run.
Write the UI. Back in the day, a user interface consisted of

       $ENTRY
...
  or

9999 DATA ...
or, if we were feeling lucky,

       READ (6,*) ... (or whatever)

By the time I finished writing the code, if I was lucky, it looked  
like what I described.
Very few subroutines (Maybe some LINPAC or some other code package),  
lots of the dreaded GOTO statements.
Comment statements? A waste of punch cards and RAM. *LOL*

Then spend weeks squashing bugs.

Shells, wrappers, IF...THEN...ELSE blocks, code with only one input  
and one output were concepts unknown to us.

To put it mildly, I feel very under-served by my formal computer  
education. Perhaps it was just a  matter of bad timing. Still, as one  
post said, they teach us 8 semesters of mathematics and one of  
Fortran, expecting us to learn how to program by ourselves. Pick up  
any older book on "Numerical Methods in the Foo Sciences". They got  
the numbers crunched, but the programming style was wretched. Donald  
Knuth, were were you?

> 	"Bottom up", to me, was more: write the code to read/write the data
> records; then use those routines to write code to modify the  
> contents of
> the records; repeat ad infinitum (it seemed) until you reached the  
> main
> program -- which sort of came down to a "fiat lux".
>
> 	"Top down/Functional decomposition" ran the other way... Start with
> the main program. Determine what major activities it has to  
> perform, and
> add invocations to stub routines for each of those. Repeat with each
> stub, add invocations to the stubs for the functions it had to
> perform... until you reach the layer that does the "physical work",
> say... Problem with this approach, especially in a poorly thought out
> team, is that you may have widely spaced sections that have to
> manipulate the same file, say -- and end up with multiple routines all
> incompatible to do that.

Been there, done that. Aren't XML and the other structured data  
protocols nice?

>
> 	Often I'd (on solo efforts) get to some point, and then reverse, to
> build the low-level routines as a library... I think I've heard that
> defined as "outside in" design.

Sometimes, I'd add so many layers of crud onto the original meat of  
the program, it was just easier to toss the whole thing out. What a  
royal waste of time. Far better to plan ahead.

>
> 	In one aspect, OOP is closer to the "bottom up" approach, since one
> is creating "objects" to represent/manipulate the same things one
> started with in "bottom up"; just better encapsulated -- you don't
> suddenly find some routine 10 layers up that is directly manipulating
> the data (object state) with no direct understanding of where this  
> data
> came from, where it is going, etc.

Yes, but the computer doesn't, and never did "understand" the data.  
All of this OOP stuff was invented to help the Programmer and Legacy  
Code Maintainers understand the processing.

> 	In my college, it was the business majors that got hit... The
> Statistics II course was 90% number crunching using a statistics  
> package
> (I've forgotten the name of the package -- its been 27 years; and as a
> CS major I only had to take Stat I... SPSS comes to mind: Statistical
> Package for the Social Sciences).

And COBOL. Even in 1977, I used to feel sorry for the people who had  
to program in COBOL.

>
> 	Database management was worse: at the time, my textbook went
> "Hierarchical, Network, (theoretical) Relational" (five years later, a
> new edition went "Relational, (historical) Network, (historical)
> Hierarchical". Campus mainframe ran a DBTG Network model DBMS.

As a general rule, the scientists and engineers I know can't  
understand the structure of a database that doesn't fit into MS Excel.

>
>>
>> I still don't get OOP completely, but Python has helped a great deal.
>>
> 	I'm still terrible with the more intangible "objects", and various
> inheritance concerns... I do much better when the "objects"  
> directly map
> to tangible things (it is easy to model a radio: components include
> things like "tuner", "audio amplification", "demodulator/mixer") --  
> but
> trying to visualize a broadcast received on that radio as an  
> "object" is
> not so easy. And this is after having taken a few OOA/OOD courses.

I can't wait to need that kind of stuff. I think I'm baffled now...

>> Sure. It seems logical now. But remember, I learned WatFiv Fortran,
>> which came before even Fortran 77. I saw my first Fortran 95 code
>> about two years ago. It took me a while to realize that what I was
>> looking at _was_ Fortran!
>>
> 	F90/F95 is scary, isn't it...
>
> 	F77 wasn't that big a change from FORTRAN-IV (F66)  (hmmm, we're due
> for another standard, aren't we? 1966, 1977, 1990 [95 was a tweak]...)

Shouldn't Fortran 2003 be out by now? Maybe it will be so great that  
Python 3.x will be written completely in it? FPython, ayone?

>
> 	The major things F77 added were: a string type, consolidation of I/O
> such that encode()/decode() weren't needed, and blocked IF/ELSE
> statements.

I made the mistake of using the word "Hollerith" in front of a 21  
y.o. CS grad. I had to explain the history of the punch card.

>> Google makes this game too easy, but it's to Who you refer. How about
>> _this_ reference: "What we all need is a left-handed monkey wrench."
>
> 	Since I'm not going to Google it, I'll have to pass.
> 	{I'll also have to set up a recorder for March 17, SciFi Channel}

The Grateful Dead paying homage to a time-honored Navy tradition. Is  
the SciFi Channel having a Who-fest?

:--David