Re: Ten Commandments (On Topic!)
- From: Charles Russell <SPAMworFREEwor@xxxxxxxxxxxxx>
- Date: Sat, 26 Nov 2005 18:05:35 -0600
David Flower wrote:
Well 20 postings in reply, but nobody suggested their own ten commandments - how about it ?
OK, here's something radical (or reactionary?):
Fortran style for nonprogrammers, or how to do the most math with the least programming.
Kernighan & Pike assert that programming for personal use is one to two orders of magnitude faster than programming for someone else. Here are my rules for achieving that in fortran.
1) Stick to batch jobs.
So you can run overnight or put the code in a loop. (Ability to run overnight is like having two orders of magnitude faster CPU.)
2) Keep I/O rudimentary.
Don't write a user interface. Instead, use a good text editor to edit input files and browse output files. Leave interfaces, graphics, communications, and databases for professional programmers. Avoid format statements. Use list-directed I/O for fast coding, except when you need
to squeeze a lot of columns into a table. Stick to lineprinter graphics (the only truly portable graphics).Export final results to a spreadsheet for presentation or publication.
3) Stick to numerics.
Avoid text programming; give alphanumeric data a numerical key and keep the key in a notebook or spreadsheet. To manipulate code or data files use unix filters.
4) Stick to simple program organization.
First read in all the data, then crunch it with calls to netlib or other math packages, and finally write the results to a few files that you can view with an editor.
5) Avoid language-specific features.
For easily translatable code and easily transferable skills. Languages may come and go, but an algorithm is forever. Exception: make full use of fortran's variable-dimension bounds-checked arrays: these are safer, more flexible, more convenient,and more portable than arrays in other languages. (And scientific programming is nothing but math operations on arrays of reals.) Another exception: common and/or module are unavoidable.
6) Stick to arithmetic statements, do-enddo, if-elseif-else-endif, and infrequent well-commented goto-continue. (Avoid do while; you don't want a potentially infinite loop in a batch job.)
7) Stick to double precision and integer types.
IEEE single precision is worthless for numerical work; it won't work in conjunction with any curve fitting package that depends on finite-difference derivatives. Make the default double; default typing is then fairly safe. (With f77, you can count on ftnchek to get you out of any trouble.) Even if you declare variables, stick to the default naming conventions for easy reading. Don't use logical; use integer with C conventions, to facilitate translation to other languages and to restrict code to the default types. Character and structure types are unnecessary when you stick to numerics (rule 3).
8) Use a good compiler.
Use one with extensive compile-time and run-time diagnostics and leave them switched on; the penalty in execution speed should not exceed 2-3 fold. Use one with extensive support for old code features. Even if you intend to rewrite old code, it is much easier to start with a working example. Seek fast compile/ link. For small problems, the compiler should feel like an interpreter.
.
- Follow-Ups:
- Re: Ten Commandments (On Topic!)
- From: Catherine Rees Lay
- Re: Ten Commandments (On Topic!)
- From: FCC
- Re: Ten Commandments (On Topic!)
- From: Ken Plotkin
- Re: Ten Commandments (On Topic!)
- References:
- Ten Commandments (On Topic!)
- From: David Flower
- Re: Ten Commandments (On Topic!)
- From: David Flower
- Ten Commandments (On Topic!)
- Prev by Date: Re: Gfortran status
- Next by Date: Re: Ten Commandments (On Topic!)
- Previous by thread: Re: Ten Commandments (On Topic!)
- Next by thread: Re: Ten Commandments (On Topic!)
- Index(es):
Relevant Pages
|
