Home > Archive > Fortran > December 2005 > Ten Commandments (On Topic!)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Ten Commandments (On Topic!)
|
|
| David Flower 2005-11-21, 7:57 am |
| Here are my suggestions for improving one's code:
1) Thou shalt know the standard for the version of FORTRAN one is
using, and never depart from it without good reason. Thou never knowst
when thy code will be required to be compiled by a different compiler.
2) Thou shalt adhere to any standards imposed by thy local installation
3) Thou shalt never forget that no code is better than its associated
documentation.
4) Thou shall always ensure that thy code is fully commented.
5) Thou shalt remember that appropriate use of space greatly clarifies
code.
6) Thou shall indent code between DO...END DO IF...END IF etc.
7) Thou shalt avoid code that causes other programmers to reach for the
manual
8) Thou shalt always use IMPLICIT NONE
9) Thou shalt never embed unknown constants within thy code; rather
thou shalt define them as PARAMETERS, clearly explaining their value.
10) Thou shalt add a comment to every type statement, exactly
specifying the variable
As an example of several of the above, compare:
W=X/Y/Z
with
C This form chosen over X/(Y*Z) as Y*Z may cause overflow
W = (X/Y) / Z
(The former violates 4, 5 and 7)
Finally, whilst compiling the above, I thought of including the
following two, which are rather more of the form of guidelines,
particularly useful if you frequently use a browser:
1) Where possible, avoid continuation lines in non-executable
statements
The reason for this is that, when browsing for variabloe names,
finding:
A MyVariable, YourVariable, HisVariable
is useless, whereas:
INTEGER MyVariable
is helpful
2) Develop a close relationship between the names of:
- Indices of DO loops
- PARAMETERS specifying the size of arrays
- Variables indicating the limit of a DO-loop
- Variables storing a particular value of a DO loop index
For example, one might use the names ICOL, MCOL, NCOL, KCOL
respectively.
To illustrate:
INTEGER MROW, MCOL
PARAMETER (MCOL=3)
PARAMETER (MROW=4)
INTEGER MATRIX(MCOL,MROW)
INTEGER ICOL, IROW, NCOL, NROW, KCOL, KROW
defined as above; any of the following lines of code would arouse
suspicion:
DO IROW = 1, NCOL
MATRIX ( IROW,MCOL) = 42
KCOL = MROW
They might, of course be correct, but probably are not.
Now, all of you out there, lets hear your comments...
Dave Flower
| |
| Gordon Sande 2005-11-21, 7:57 am |
| On 2005-11-21 06:07:31 -0400, "David Flower" <DavJFlower@AOL.COM> said:
> Here are my suggestions for improving one's code:
>
> 1) Thou shalt know the standard for the version of FORTRAN one is
> using, and never depart from it without good reason. Thou never knowst
> when thy code will be required to be compiled by a different compiler.
>
> 2) Thou shalt adhere to any standards imposed by thy local installation
>
> 3) Thou shalt never forget that no code is better than its associated
> documentation.
>
> 4) Thou shall always ensure that thy code is fully commented.
>
> 5) Thou shalt remember that appropriate use of space greatly clarifies
> code.
>
> 6) Thou shall indent code between DO...END DO IF...END IF etc.
>
> 7) Thou shalt avoid code that causes other programmers to reach for the
> manual
>
> 8) Thou shalt always use IMPLICIT NONE
>
> 9) Thou shalt never embed unknown constants within thy code; rather
> thou shalt define them as PARAMETERS, clearly explaining their value.
>
> 10) Thou shalt add a comment to every type statement, exactly
> specifying the variable
>
>
>
> As an example of several of the above, compare:
>
> W=X/Y/Z
>
> with
>
> C This form chosen over X/(Y*Z) as Y*Z may cause overflow
> W = (X/Y) / Z
>
> (The former violates 4, 5 and 7)
>
> Finally, whilst compiling the above, I thought of including the
> following two, which are rather more of the form of guidelines,
> particularly useful if you frequently use a browser:
>
> 1) Where possible, avoid continuation lines in non-executable
> statements
> The reason for this is that, when browsing for variabloe names,
> finding:
> A MyVariable, YourVariable, HisVariable
> is useless, whereas:
> INTEGER MyVariable
> is helpful
>
> 2) Develop a close relationship between the names of:
> - Indices of DO loops
> - PARAMETERS specifying the size of arrays
> - Variables indicating the limit of a DO-loop
> - Variables storing a particular value of a DO loop index
> For example, one might use the names ICOL, MCOL, NCOL, KCOL
> respectively.
> To illustrate:
> INTEGER MROW, MCOL
> PARAMETER (MCOL=3)
> PARAMETER (MROW=4)
> INTEGER MATRIX(MCOL,MROW)
> INTEGER ICOL, IROW, NCOL, NROW, KCOL, KROW
> defined as above; any of the following lines of code would arouse
> suspicion:
>
> DO IROW = 1, NCOL
>
> MATRIX ( IROW,MCOL) = 42
>
> KCOL = MROW
>
> They might, of course be correct, but probably are not.
>
>
>
>
> Now, all of you out there, lets hear your comments...
There are two rules that you have not mentioned
1 - Do not use comments to repeat what is obvious from the code.
2 - Treat variable names as an important component of the internal
documentation.
These are more than just variations on your rules as you come close to
violating 1 in the unnumbered example above.
> Dave Flower
| |
| Dan Nagle 2005-11-21, 7:57 am |
| Hello,
Gordon Sande wrote:
<snip>
> 1 - Do not use comments to repeat what is obvious from the code.
>
> 2 - Treat variable names as an important component of the internal
> documentation.
Thou shalt use keywords and intents when calling external procedures,
to document the call and to force the explicit interface.
Thou shalt name thine constructs with names which do not
repeat the condition nor loop limits.
<snip>
Good show.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
|
|
David Flower schreef:
> Here are my suggestions for improving one's code:
>
<snip>
> 9) Thou shalt never embed unknown constants within thy code; rather
> thou shalt define them as PARAMETERS, clearly explaining their value.
My preferred way for this is not (from example below):
INTEGER MROW, MCOL
PARAMETER (MCOL=3)
PARAMETER (MROW=4)
but
INTEGER, parameter :: MROW = 4, MCOL = 3
> Finally, whilst compiling the above, I thought of including the
> following two, which are rather more of the form of guidelines,
> particularly useful if you frequently use a browser:
>
> 1) Where possible, avoid continuation lines in non-executable
> statements
> The reason for this is that, when browsing for variabloe names,
> finding:
> A MyVariable, YourVariable, HisVariable
I always use & where you put an A
> is useless, whereas:
> INTEGER MyVariable
> is helpful
>
> 2) Develop a close relationship between the names of:
> - Indices of DO loops
> - PARAMETERS specifying the size of arrays
> - Variables indicating the limit of a DO-loop
> - Variables storing a particular value of a DO loop index
> For example, one might use the names ICOL, MCOL, NCOL, KCOL
> respectively.
> To illustrate:
> INTEGER MROW, MCOL
> PARAMETER (MCOL=3)
> PARAMETER (MROW=4)
> INTEGER MATRIX(MCOL,MROW)
> INTEGER ICOL, IROW, NCOL, NROW, KCOL, KROW
> defined as above; any of the following lines of code would arouse
> suspicion:
>
> DO IROW = 1, NCOL
>
> MATRIX ( IROW,MCOL) = 42
>
> KCOL = MROW
>
> They might, of course be correct, but probably are not.
>
Anyone remembers Dijkstra's commandments to become an angel in
programmer's heaven ?
[JvO]
| |
| David Flower 2005-11-21, 7:01 pm |
|
[JvO] wrote:
> David Flower schreef:
>
> <snip>
>
>
> My preferred way for this is not (from example below):
>
> INTEGER MROW, MCOL
> PARAMETER (MCOL=3)
> PARAMETER (MROW=4)
>
> but
>
> INTEGER, parameter :: MROW = 4, MCOL = 3
>
>
> I always use & where you put an A
>
>
> Anyone remembers Dijkstra's commandments to become an angel in
> programmer's heaven ?
>
> [JvO]
There are reasons for this; in the case of the PARAMETERs, the code I
quoted was standard F77 and F90; your's was only F90.
In the case of continuation lines, by using A, B , C etc., I know I
must stop at S, or violate the F77 standard. (1, 2, 3 does not work, as
zero is not a valid continuation character.
Of course, if you are 100% sure that you will never need to run your
code under F77...
Dave Flower
| |
| Ron Shepard 2005-11-21, 7:01 pm |
| In article <1132567651.181930.30740@g14g2000cwa.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:
> INTEGER MATRIX(MCOL,MROW)
I always hate debugging code like this. Fortran has its own
conventions about rows and columns, and although you can swim
upstream and use the opposite convention, it just makes it harder
for others to work with your code. In fact, after you come back to
your own code in a few days, w s, months, etc., it is harder to
work on your own code with this backwards convention.
INTEGER MATRIX(MROW,MCOL) ! the way god intended :-)
$.02 -Ron Shepard
| |
|
| Yes, I am, and I only use free format source form.
[JvO]
| |
| phaccount@nycap.rr.com 2005-11-21, 7:01 pm |
| Um, two comments:
Why MRow, Mcol, Irow instead of Row, Col, etc when implicit none is in
effect? (My personal preference is cCol[s],cRow[s],iRow (where prefixes
c, i are "attributes" -- c stands for count, i for index, etc). That
way I usually write
do iCase=1,cCase[s] ...
I believe this is the Hungarian notation, and it allows re-use of the
"Case" word.
Second comment: The very example above always makes me wish for inline
declarations. I would like to be able to declare iCase just before the
loop, because, at least the way I write code, iCase will be used _only_
in that loop, and nowhere else outside of it. If I have 2 loops where
I am looping over the same case, I try to find meaningfull names such
as
[wish: integer iPass1]
Pass1: do iPass1=1,cCase[s]
....
end do Pass1
[wish: integer iPass2]
Pass2: iPass2=1,cCase[s]
....
end do Pass2
Any practical reason why that is not part of the standard (I believe
C++ allows for that, not that fortran must follow C++ in every
particular detail)?
Thanks,
Mirko
| |
| Rich Townsend 2005-11-21, 7:01 pm |
| phaccount@nycap.rr.com wrote:
> Um, two comments:
>
> Why MRow, Mcol, Irow instead of Row, Col, etc when implicit none is in
> effect? (My personal preference is cCol[s],cRow[s],iRow (where prefixes
> c, i are "attributes" -- c stands for count, i for index, etc). That
> way I usually write
>
> do iCase=1,cCase[s] ...
>
> I believe this is the Hungarian notation, and it allows re-use of the
> "Case" word.
Yep, I use i_case and n_cases.
>
> Second comment: The very example above always makes me wish for inline
> declarations. I would like to be able to declare iCase just before the
> loop, because, at least the way I write code, iCase will be used _only_
> in that loop, and nowhere else outside of it. If I have 2 loops where
> I am looping over the same case, I try to find meaningfull names such
> as
>
> [wish: integer iPass1]
> Pass1: do iPass1=1,cCase[s]
> ...
> end do Pass1
>
> [wish: integer iPass2]
> Pass2: iPass2=1,cCase[s]
> ...
> end do Pass2
>
> Any practical reason why that is not part of the standard (I believe
> C++ allows for that, not that fortran must follow C++ in every
> particular detail)?
I'm sure there are good reasons for this, but I too miss this 'local loop
variable' possibility in Fortran. I use it extensively in Perl and PHP. I guess
its probably something to do with the fact that Fortran doesn't have the notion
of block scope.
cheers,
Rich
| |
| Phillip Helbig---remove CLOTHES to reply 2005-11-21, 7:01 pm |
| In article <1132586633.129397.243100@g49g2000cwa.googlegroups.com>,
"[JvO]" <jvo_36@hotmail.com> writes:
>
> I always use & where you put an A
Non-standard, except in fixed-form Fortran 90.
| |
|
| Sorry Phillip,
& MyVariable, YourVariable, HisVariable
is standard F77 and also
Standard F90/95/2003 (for free format if it is the last line of a
continued statement)
and that is how I meant my remark.
[JvO] aka Jan van Oosterwijk
| |
| Michael Metcalf 2005-11-21, 9:57 pm |
| Sorry Jan,
The & character was not part of the F77 character set.
Regards,
Mike Metcalf
"[JvO]" <jvo_36@hotmail.com> wrote in message
news:1132616296.918386.218460@z14g2000cwz.googlegroups.com...
> Sorry Phillip,
>
> & MyVariable, YourVariable, HisVariable
>
> is standard F77 and also
> Standard F90/95/2003 (for free format if it is the last line of a
> continued statement)
> and that is how I meant my remark.
>
> [JvO] aka Jan van Oosterwijk
>
| |
| Ken Plotkin 2005-11-21, 9:57 pm |
| On Mon, 21 Nov 2005 13:39:51 GMT, Gordon Sande
<g.sande@worldnet.att.net> wrote:
>There are two rules that you have not mentioned
>
>1 - Do not use comments to repeat what is obvious from the code.
>
>2 - Treat variable names as an important component of the internal
> documentation.
>
>These are more than just variations on your rules as you come close to
>violating 1 in the unnumbered example above.
Very good. Those can replace the two in the original list that were
clearly personal prejuduces, and not universal. That still leaves us
with an even ten.
Ken Plotkin
| |
| David Flower 2005-11-22, 4:00 am |
|
Ken Plotkin wrote:
> On Mon, 21 Nov 2005 13:39:51 GMT, Gordon Sande
> <g.sande@worldnet.att.net> wrote:
>
Agreed; I should perhaps have added this to the commandment about
comments
[color=darkred]
I do not disagree, but believe that commandment (10) is more important;
sometimes it is not possible to compress the description into a
variable name. For example an INTEGER flag that has values 1 to 42,
each with a different meaning could not be compressed into a variable
name; a full list of meanings could, indeed should, be commented next
to the type statement
[color=darkred]
Only because the variables had no meaning anyway.
[color=darkred]
>
> Very good. Those can replace the two in the original list that were
> clearly personal prejuduces, and not universal. That still leaves us
> with an even ten.
Which two ?
>
> Ken Plotkin
Dave Flower
| |
|
| Time flies...
And memory fades ...
[JvO]
| |
| Gordon Sande 2005-11-22, 7:59 am |
| On 2005-11-22 04:34:52 -0400, "David Flower" <DavJFlower@AOL.COM> said:
>
> Ken Plotkin wrote:
>
> Agreed; I should perhaps have added this to the commandment about
> comments
>
>
> I do not disagree, but believe that commandment (10) is more important;
The statement was that the variable name was a COMPONENT of the documentation
which does not mean that it is the only documentation.
> sometimes it is not possible to compress the description into a
> variable name. For example an INTEGER flag that has values 1 to 42,
> each with a different meaning could not be compressed into a variable
> name; a full list of meanings could, indeed should, be commented next
> to the type statement
The sensible, to me at least, thing would be to have a variable name
for the integer like
integer :: processing_stage
or for those who still like six characters
integer :: prc_stg ! processing stage
with a set of (42) named paramters like
integer :: stage_premix = 1
integer ;; stage_premix_ = 2
In my code I have many instances of 20 or so binary status flags
represented in an integer with my set, reset and test functions.
I have found that it is easier in the long run to think octal
but write decimal so that when I debug the decimal printed values
are easier to take apart. Yes it does lead to an addition 0.001
percent in execution time but that has long since been recovered
by the one less run that I had to make. All the values are in
parameters so it is only when debugging that I have to look up
the actual values. I even don't bother using all the adjacent
values. So 1, 2, 4, 10 are for 4 related issues and 100, 200
for another issue and 10,000 etc for yet others.
>
>
> Only because the variables had no meaning anyway.
>
>
> Which two ?
>
>
> Dave Flower
| |
| Rich Townsend 2005-11-22, 7:59 am |
| Gordon Sande wrote:
> On 2005-11-22 04:34:52 -0400, "David Flower" <DavJFlower@AOL.COM> said:
>
>
>
> The statement was that the variable name was a COMPONENT of the
> documentation
> which does not mean that it is the only documentation.
>
>
>
> The sensible, to me at least, thing would be to have a variable name
> for the integer like
>
> integer :: processing_stage
>
> or for those who still like six characters
>
> integer :: prc_stg ! processing stage
Or for those who still like both six characters and non-1984 arithmetic,
integer :: pr_stg
:)
cheers,
Rich
| |
| Ken Plotkin 2005-11-22, 7:01 pm |
| On 22 Nov 2005 00:34:52 -0800, "David Flower" <DavJFlower@AOL.COM>
wrote:
>
>Which two ?
>
I'm sure each of us can identiry two they don't like. :-)
#8 is definitely off my list, and #2 can be squirrelly - depending on
the installation. YMMV,
| |
| Richard Maine 2005-11-22, 7:01 pm |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
> Gordon Sande wrote:
>
> Or for those who still like both six characters and non-1984 arithmetic,
>
> integer :: pr_stg
Of course, those who are picky about 6 characters might also not like
the underscore or the lower case. :-)
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Gordon Sande 2005-11-22, 7:01 pm |
| On 2005-11-22 12:44:04 -0400, nospam@see.signature (Richard Maine) said:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
>
> Of course, those who are picky about 6 characters might also not like
> the underscore or the lower case. :-)
One foot down to four toes!
| |
| Kevin G. Rhoads 2005-11-22, 7:01 pm |
| I always liked "Unnecessary parentheses aren't"
| |
| David Flower 2005-11-24, 3:58 am |
|
David Flower wrote:
> Here are my suggestions for improving one's code:
>
> 1) Thou shalt know the standard for the version of FORTRAN one is
> using, and never depart from it without good reason. Thou never knowst
> when thy code will be required to be compiled by a different compiler.
>
> 2) Thou shalt adhere to any standards imposed by thy local installation
>
> 3) Thou shalt never forget that no code is better than its associated
> documentation.
>
> 4) Thou shall always ensure that thy code is fully commented.
>
> 5) Thou shalt remember that appropriate use of space greatly clarifies
> code.
>
> 6) Thou shall indent code between DO...END DO IF...END IF etc.
>
> 7) Thou shalt avoid code that causes other programmers to reach for the
> manual
>
> 8) Thou shalt always use IMPLICIT NONE
>
> 9) Thou shalt never embed unknown constants within thy code; rather
> thou shalt define them as PARAMETERS, clearly explaining their value.
>
> 10) Thou shalt add a comment to every type statement, exactly
> specifying the variable
>
>
>
> As an example of several of the above, compare:
>
> W=X/Y/Z
>
> with
>
> C This form chosen over X/(Y*Z) as Y*Z may cause overflow
> W = (X/Y) / Z
>
> (The former violates 4, 5 and 7)
>
> Finally, whilst compiling the above, I thought of including the
> following two, which are rather more of the form of guidelines,
> particularly useful if you frequently use a browser:
>
> 1) Where possible, avoid continuation lines in non-executable
> statements
> The reason for this is that, when browsing for variabloe names,
> finding:
> A MyVariable, YourVariable, HisVariable
> is useless, whereas:
> INTEGER MyVariable
> is helpful
>
> 2) Develop a close relationship between the names of:
> - Indices of DO loops
> - PARAMETERS specifying the size of arrays
> - Variables indicating the limit of a DO-loop
> - Variables storing a particular value of a DO loop index
> For example, one might use the names ICOL, MCOL, NCOL, KCOL
> respectively.
> To illustrate:
> INTEGER MROW, MCOL
> PARAMETER (MCOL=3)
> PARAMETER (MROW=4)
> INTEGER MATRIX(MCOL,MROW)
> INTEGER ICOL, IROW, NCOL, NROW, KCOL, KROW
> defined as above; any of the following lines of code would arouse
> suspicion:
>
> DO IROW = 1, NCOL
>
> MATRIX ( IROW,MCOL) = 42
>
> KCOL = MROW
>
> They might, of course be correct, but probably are not.
>
>
>
>
> Now, all of you out there, lets hear your comments...
>
>
>
> Dave Flower
Well 20 postings in reply, but nobody suggested their own ten
commandments - how about it ?
Dave Flower
| |
| Charles Russell 2005-11-26, 6:59 pm |
| 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. S fast compile/ link. For small problems, the compiler
should feel like an interpreter.
| |
| Ken Plotkin 2005-11-27, 3:57 am |
| On Sat, 26 Nov 2005 18:05:35 -0600, Charles Russell
<SPAMworFREEwor@bellsouth.net> wrote:
[snip]
>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
[snip]
That's interesting.
How come all of my programs that use single precision work?
And why is it that I've seen colleagues run out of digits, switch to
double precision, and still run out of digits?
I must be missing something.
Ken Plotkin
| |
| Mr Hrundi V Bakshi 2005-11-27, 3:57 am |
|
"Ken Plotkin" <kplotkin@nospam-cox.net> wrote in message
news:jngio1hgcpr808r5q66apuh7s4je2hdn36@
4ax.com...
> On Sat, 26 Nov 2005 18:05:35 -0600, Charles Russell
> <SPAMworFREEwor@bellsouth.net> wrote:
>
> [snip]
> [snip]
>
> That's interesting.
>
> How come all of my programs that use single precision work?
>
> And why is it that I've seen colleagues run out of digits, switch to
> double precision, and still run out of digits?
>
> I must be missing something.
>
Without a doubt, but that'll hardly affect you and your equally inept
colleagues: ba boom, ba boom, et cetra, et cetra, ...!
--
Boom,
Hrundi V.B..
| |
| Dan Nagle 2005-11-27, 7:56 am |
| Hello,
Ken Plotkin wrote:
> On Sat, 26 Nov 2005 18:05:35 -0600, Charles Russell
> <SPAMworFREEwor@bellsouth.net> wrote:
>
> [snip]
>
>
> [snip]
>
> That's interesting.
>
> How come all of my programs that use single precision work?
>
> And why is it that I've seen colleagues run out of digits, switch to
> double precision, and still run out of digits?
>
> I must be missing something.
At a large computing center, I was tasked to learn
what kind of real the programs run there were using.
The results were, IIRC, about 70% 64 bit real, 25% 32 bit real
and 5% 128 bit real.
The 32 bit real programs were mainly signal processing
of one sort or another. The 128 bit real programs
were trying to track the solution of very stiff differential
equations. 64 bit was used for everything else.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Gordon Sande 2005-11-27, 9:56 pm |
| On 2005-11-27 01:26:50 -0400, Ken Plotkin <kplotkin@nospam-cox.net> said:
> On Sat, 26 Nov 2005 18:05:35 -0600, Charles Russell
> <SPAMworFREEwor@bellsouth.net> wrote:
>
> [snip]
> [snip]
>
> That's interesting.
>
> How come all of my programs that use single precision work?
>
> And why is it that I've seen colleagues run out of digits, switch to
> double precision, and still run out of digits?
>
> I must be missing something.
>
> Ken Plotkin
I always had the impression that 36 bits was were one had to be
carefull, with 32 bits one was often in trouble , with 48 bits
trouble was rarely seen and with 60 bits trouble was only there
when you looked for it.
32 bits -> too bloody many to cast stones at
36 bits -> 7090 and other old beasties
48 bits -> Burroughs
60 bits -> CDC 6000 and such
so the net result is that I run in 64 bit double precison
almost all the time any more. It's is overkill but trouble is
rather rare. Of course YMMV as they say in various plcaes.
| |
| Greg Lindahl 2005-11-27, 9:56 pm |
| In article < 2005112721053916807%gsande@worldnetattne
t>,
Gordon Sande <g.sande@worldnet.att.net> wrote:
>I always had the impression that 36 bits was were one had to be
>carefull, with 32 bits one was often in trouble , with 48 bits
>trouble was rarely seen and with 60 bits trouble was only there
>when you looked for it.
Perhaps the generalization of "doing numerical analysis by
generalization is inaccurate" is a better one?
-- greg
| |
| Steven G. Kargl 2005-11-27, 9:56 pm |
| In article < 2005112721053916807%gsande@worldnetattne
t>,
Gordon Sande <g.sande@worldnet.att.net> writes:
> On 2005-11-27 01:26:50 -0400, Ken Plotkin <kplotkin@nospam-cox.net> said:
>
>
> I always had the impression that 36 bits was were one had to be
> carefull, with 32 bits one was often in trouble , with 48 bits
> trouble was rarely seen and with 60 bits trouble was only there
> when you looked for it.
>
> 32 bits -> too bloody many to cast stones at
> 36 bits -> 7090 and other old beasties
> 48 bits -> Burroughs
> 60 bits -> CDC 6000 and such
>
> so the net result is that I run in 64 bit double precison
> almost all the time any more. It's is overkill but trouble is
> rather rare. Of course YMMV as they say in various plcaes.
Yes, memory is cheap these days. I have a monte carlo
simulation that can easily grab 1 to 2 GB of memory for
just a few arrays in 32-bit single precision.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Tim Prince 2005-11-28, 3:57 am |
| Gordon Sande wrote:
>
>
> I always had the impression that 36 bits was were one had to be
> carefull, with 32 bits one was often in trouble , with 48 bits
> trouble was rarely seen and with 60 bits trouble was only there
> when you looked for it.
>
> 32 bits -> too bloody many to cast stones at
> 36 bits -> 7090 and other old beasties
> 48 bits -> Burroughs
> 60 bits -> CDC 6000 and such
>
> so the net result is that I run in 64 bit double precison
> almost all the time any more. It's is overkill but trouble is
> rather rare. Of course YMMV as they say in various plcaes.
>
If you go back that far, and count IBM 360 hex format (with as few as 21
bits precision) as your 32-bit standard, of course you would find
frequent problems. The earlier posts were about IEEE 32-bit format,
which gives 24 bits precision, compared with 27 in the usual 36-bit
format. To think that we had to deal with this stuff only 30 years ago!
| |
| Ken Plotkin 2005-11-28, 3:57 am |
| On Sun, 27 Nov 2005 01:28:08 -0500, "Mr Hrundi V Bakshi"
<mrhrundivbakshi@hotmail.com> wrote:
>Without a doubt, but that'll hardly affect you and your equally inept
>colleagues: ba boom, ba boom, et cetra, et cetra, ...!
Why don't you just go XXXX yourself?
| |
| Ken Plotkin 2005-11-28, 3:57 am |
| On 27 Nov 2005 17:28:39 -0800, lindahl@pbm.com (Greg Lindahl) wrote:
>Perhaps the generalization of "doing numerical analysis by
>generalization is inaccurate" is a better one?
That was pretty much the point of my post.
I suspect that the 32-64-128 bit survey results Dan gave reflected
what the authors of those programs worked out what they needed.
With cheap memory and computing power these days, and MPUs on PCs
(maybe other systems?) doing the actual calculations in 80 bits,
there's no pressing reason to not use double precision. (Other than
age and habit, which shouldn't be underestimated.)
Having grown up with 3 to 3 1/2 significant figures, though, I tend to
appreciate 8 or 16 significant figures as a labor saving device. You
can write expressions in fairly simple ways, rather than push the
algebra to give you expressions that focus on the digits that matter.
Ken Plotkin
| |
| Greg Lindahl 2005-11-28, 3:57 am |
| In article <sb9lo1digr6rjkjdjo2kg7mgr2bjc4au61@4ax.com>,
Ken Plotkin <kplotkin@nospam-cox.net> wrote:
>I suspect that the 32-64-128 bit survey results Dan gave reflected
>what the authors of those programs worked out what they needed.
My experience says a majority of software authors seem to rely on
generalizations.
>With cheap memory and computing power these days, and MPUs on PCs
>(maybe other systems?) doing the actual calculations in 80 bits,
>there's no pressing reason to not use double precision. (Other than
>age and habit, which shouldn't be underestimated.)
This is very untrue. Caches are still small, memory bandwidth is still
limited, and few new PCs do actual calculations in 80 bits. Sheesh.
Talk about misleading generalizations.
>Having grown up with 3 to 3 1/2 significant figures, though, I tend to
>appreciate 8 or 16 significant figures as a labor saving device. You
>can write expressions in fairly simple ways, rather than push the
>algebra to give you expressions that focus on the digits that matter.
Again, this isn't how most people seem to write software.
-- greg
| |
| Ken Plotkin 2005-11-28, 3:57 am |
| On 27 Nov 2005 23:01:50 -0800, lindahl@pbm.com (Greg Lindahl) wrote:
[snip]
>This is very untrue. Caches are still small, memory bandwidth is still
>limited, and few new PCs do actual calculations in 80 bits. Sheesh.
>Talk about misleading generalizations.
I thought the math processor in Intel chips always worked in 80 bits.
But as far as caches and bandwidth goes...so my old habit of not using
double precision unless I really need it is still a Good Thing?
>
>
>Again, this isn't how most people seem to write software.
Yes - I've noticed. :-)
Ken Plotkin
| |
| Catherine Rees Lay 2005-11-28, 7:01 pm |
| phaccount@nycap.rr.com wrote:
> Um, two comments:
>
> Why MRow, Mcol, Irow instead of Row, Col, etc when implicit none is in
> effect?
<snip>
> Second comment: The very example above always makes me wish for >inline
> declarations. I would like to be able to declare iCase just before >the
> loop, because, at least the way I write code, iCase will be used >_only_
> in that loop, and nowhere else outside of it.
Personally I'd use M as a prefix to indicate that this is the maximum
value, N to indicate the actual value (in F90 and beyond with dynamic
allocation these are often the same) and I to indicate the current
value, e.g. in a loop index.
This has two advantages:
1) if the "meaningful name" starts with an N or an M it's visually more
distinctive and less prone to typos - MMICE and IMICE are more different
than MMICE and MICE.
2) Even with implicit none, if you stick to I-N for integers you have a
visual "hold on a minute" indicator if you do something which might give
an unintentional result such as dividing one integer by another.
I don't like inline declarations. I want to be able to see all the
variables I've declared in one place. And if I'm looping over the same
thing twice, I'd use the same loop variable twice.
But I don't think either is overwhelmingly "better" style-wise, as long
as you're consistent.
Catherine.
| |
|
| Charles Russell articulated on 11/27/05 01:05:
> 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.
This reminds me of an important question that I have not resolved for
myself yet: What is the best (in the sense of ease and speed of
programming and error-proneness) way to write detailed input data into
input files?
For a while I used NAMELISTs and I thought they were great. But I came
across criticisms of use of NAMELISTs, and what's more, I never saw
anybody advocating them (except me)! People frequently talked of
`parsing' input files, and writing/using `parsers'.
I cannot quite figure out the advantages of using/writing parsers. Would
people in this list agree on NAMELISTs instead as a means of providing
fast, intuitive and error-free input to the program? Obviously writing
parsers is much more complicated compared to using NAMELISTs.
Thanks,
--
FCC.
===
Nothing splendid has ever been achieved except by those who dared
believe that something inside of them was superior to circumstance.
-Bruce Barton
| |
| Catherine Rees Lay 2005-11-28, 7:01 pm |
| I think this all seems very sensible on the surface - except that all
too often I'm presented with code which was written using these
guidelines many years ago, has been added to piecemeal ever since, and
now someone wants to use it as the basis for an interactive program with
lots of new features and a nice user interface which can fail gracefully
no matter what rubbish the user puts into it.
It's not a good idea if your personal code may end up non-personal.
(Although I'd take your version of it over most, since you use the
compile and runtime diagnostics :-)
I second not writing a user interface. If you need a user interface, IMO
these rules don't apply. If not, text files are dead easy, especially if
you allow for your sample one to have a comment on or before each line
to say what each data item is.
Catherine.
Charles Russell wrote:
> David Flower wrote:
>
>
> 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. S fast compile/ link. For small problems, the compiler
> should feel like an interpreter.
| |
| Dan Nagle 2005-11-28, 7:01 pm |
| Hello,
Ken Plotkin wrote:
<snip>
> With cheap memory and computing power these days, and MPUs on PCs
> (maybe other systems?) doing the actual calculations in 80 bits,
> there's no pressing reason to not use double precision. (Other than
> age and habit, which shouldn't be underestimated.)
There's memory bandwidth. See http://www.cs.virginia.edu/stream
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Dan Nagle 2005-11-28, 7:01 pm |
| Hello,
FCC wrote:
<snip>
> Would
> people in this list agree on NAMELISTs instead as a means of providing
> fast, intuitive and error-free input to the program? Obviously writing
> parsers is much more complicated compared to using NAMELISTs.
I think namelist is great. Are the critics also advocates
of other languages?
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
|
| Dan Nagle articulated on 11/28/05 12:29:
> Hello,
>
> FCC wrote:
> <snip>
>
>
>
> I think namelist is great. Are the critics also advocates
> of other languages?
>
Not really. There are several threads in comp.lang.fortran in which
NAMELIST is discussed. Some people use it, but others state that they
use their own `parsers'. It appears to me that NAMELIST is not preferred
because
1. the marker characters that mark the beginning and end of NAMELIST
group can be different from compiler to compiler whereas `parsers' can
be written in 100% portable fortran.
2. NAMELIST slows down the code and consumes too much space.
3. NAMELIST only works for TEXT files (does not work for BINARY files).
4. Not all programs write their output in NAMELIST form, so if such
output will be used as the input or part of the input for another
program, then using NAMELIST becomes non-trivial (e.g. as in pipes,
where NAMELIST would not work).
Among these criticisms, I would agree on the 1st one partially, because
it is easy to fix (just change from &.../ format to $... $ format or
whatever is required by the compiler). However, this could be a problem
if compilers of conflicting standards need to be used often. No. 2 is
not so important because NAMELIST data is read usually once to input all
the variables so the run-time penalty should be minimal. No. 3 is also
not so important because most input data that need to be prepared by the
user are in TEXT files. No. 4 is, in my opinion, the real di vantage.
However, one can use NAMELIST strictly for the user-prepared part of the
input file since that is where it is very useful. For other data that
come from other applications, a parser may still be needed.
On the other hand, NAMELIST
1. allows creation of lists that contain variable names that are
related, so the files become easier to maintain (both source code and
input files).
2. results in much less likelihood of introducing errors during the
transfer of data from the input file into variables (one can have bugs
in personal parsers, especially in the development stage).
3. causes data to be backward compatible automatically if one needs to
add new variables (with parsers this means more coding just to be able
to correctly transfer the data from the input file to the variables).
It appears to me that, NAMELIST is indeed a `simple automatic input-file
parser', which ought to help speed up coding. Then it should be included
in the list of `Ten Commandments' I believe, particularly inside item
no. 2. Especially in research work (like mine), often what counts is how
fast the correct results are obtained, and not how efficient the code works.
Best,
--
FCC.
===
Once you begin to understand life, you don't need an excuse to be  !
-Anonymous
| |
| Dan Nagle 2005-11-28, 7:01 pm |
| In-Reply-To: <dmeto9$msl$1@defalla.upc.es>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 71
Message-ID: <P9Dif.81$3x2.24@trnddc07>
Date: Mon, 28 Nov 2005 12:58:23 GMT
NNTP-Posting-Host: 70.21.110.63
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc07 1133182703 70.21.110.63 (Mon, 28 Nov 2005 07:58:23 EST)
NNTP-Posting-Date: Mon, 28 Nov 2005 07:58:23 EST
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:140002
Hello,
FCC wrote:
<snip a bunch>
> 1. the marker characters that mark the beginning and end of NAMELIST
> group can be different from compiler to compiler whereas `parsers' can
> be written in 100% portable fortran.
Non-standard Fortran should be counted, here I think,
as a different language. Standard namelist uses the same delimiter
characters everywhere.
> 2. NAMELIST slows down the code and consumes too much space.
And a homebrew parser doesn't?
> 3. NAMELIST only works for TEXT files (does not work for BINARY files).
Binary files are non-standard. Namelist is formatted, i.e.,
human readable. Why add labels and comments to a file not intended
to be read by humans?
> 4. Not all programs write their output in NAMELIST form, so if such
> output will be used as the input or part of the input for another
> program, then using NAMELIST becomes non-trivial (e.g. as in pipes,
> where NAMELIST would not work).
Why doesn't namelist work in pipes?
> Among these criticisms, I would agree on the 1st one partially, because
> it is easy to fix (just change from &.../ format to $... $ format or
> whatever is required by the compiler).
Or use whatever compiler switch or environment variable
is needed to make the conversion magically. One must expect
vendors to retain backwards compatibility.
> However, this could be a problem
> if compilers of conflicting standards need to be used often. No. 2 is
> not so important because NAMELIST data is read usually once to input all
> the variables so the run-time penalty should be minimal. No. 3 is also
> not so important because most input data that need to be prepared by the
> user are in TEXT files. No. 4 is, in my opinion, the real divantage.
> However, one can use NAMELIST strictly for the user-prepared part of the
> input file since that is where it is very useful. For other data that
> come from other applications, a parser may still be needed.
>
> On the other hand, NAMELIST
> 1. allows creation of lists that contain variable names that are
> related, so the files become easier to maintain (both source code and
> input files).
> 2. results in much less likelihood of introducing errors during the
> transfer of data from the input file into variables (one can have bugs
> in personal parsers, especially in the development stage).
> 3. causes data to be backward compatible automatically if one needs to
> add new variables (with parsers this means more coding just to be able
> to correctly transfer the data from the input file to the variables).
>
> It appears to me that, NAMELIST is indeed a `simple automatic input-file
> parser', which ought to help speed up coding. Then it should be included
> in the list of `Ten Commandments' I believe, particularly inside item
> no. 2. Especially in research work (like mine), often what counts is how
> fast the correct results are obtained, and not how efficient the code works.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Gordon Sande 2005-11-28, 7:01 pm |
| On 2005-11-28 00:17:46 -0400, Tim Prince <tprince@nospamcomputer.org> said:
> Gordon Sande wrote:
>
> If you go back that far, and count IBM 360 hex format (with as few as
> 21 bits precision) as your 32-bit standard, of course you would find
> frequent problems. The earlier posts were about IEEE 32-bit format,
> which gives 24 bits precision, compared with 27 in the usual 36-bit
> format. To think that we had to deal with this stuff only 30 years ago!
I was going to grumble about IBM 360 using hex normalization but decided
to keep the list shorter. Yes it was 32 bit hex that was my complaint
but even 32 bit IEEE is a bit short of the old 36 bit mainframes. And
if one really has a good memory the very early 360s did not have a guard
byte but that was cured fairly early on. If I have it right, there was
a real curiosity in that a normalization for multiplying by 1.0 could
result in losing precision before the guard byte was added.
| |
| Gordon Sande 2005-11-28, 7:01 pm |
| On 2005-11-28 07:29:42 -0400, Dan Nagle <dannagle@verizon.net> said:
> Hello,
>
> FCC wrote:
> <snip>
>
>
> I think namelist is great. Are the critics also advocates
> of other languages?
NAMELIST is one of the "hidden gems" of Fortran.
A great way to write one-off test beds that are more flexible
than just coding the test data inline.
It has two minor downsides. One is that if you use different
names for differing purposes you will need to have all the
NAMELISTs present and in the intended order. That is more a
self imposed problem that results from heavy use. Not likely
to bother smaller usages. The other is that a misspelled
NAMELIST gets skipped over, but previous caveat applies again.
| |
| Rich Townsend 2005-11-28, 7:01 pm |
| Ken Plotkin wrote:
> On 27 Nov 2005 23:01:50 -0800, lindahl@pbm.com (Greg Lindahl) wrote:
>
> [snip]
>
>
>
> I thought the math processor in Intel chips always worked in 80 bits.
Most new chips use SSE2, which is 64-bit IEEE.
cheers,
Rich
| |
| Dan Nagle 2005-11-28, 7:01 pm |
| Hello,
Gordon Sande wrote:
<snip>
> One is that if you use different
> names for differing purposes you will need to have all the
> NAMELISTs present and in the intended order.
I've wanted to add a "skip to namelist group" intrinsic
for a while, but it's just never had a high enough priority
to go anywhere.
Then one could read namelists in any order,
by a skip-then-rewind strategy.
There's a few other annoyances with namelist,
especially regarding derived types. But since
no one has mentioned them yet, I guess they're
not really major.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Charles Russell 2005-11-28, 7:01 pm |
| Catherine Rees Lay wrote:
> It's not a good idea if your personal code may end up non-personal.
I simply propose using a minimal subset of the language, sufficient for
the scientist who is not a programmer, and do not see any conflict with
accepted notions of good programming style.
| |
| glen herrmannsfeldt 2005-11-28, 7:01 pm |
| Gordon Sande wrote:
(snip)
> I was going to grumble about IBM 360 using hex normalization but decided
> to keep the list shorter. Yes it was 32 bit hex that was my complaint
> but even 32 bit IEEE is a bit short of the old 36 bit mainframes. And
> if one really has a good memory the very early 360s did not have a guard
> byte but that was cured fairly early on.
Only long (64 bit) float didn't have the guard (hex) digit
> If I have it right, there was
> a real curiosity in that a normalization for multiplying by 1.0 could
> result in losing precision before the guard byte was added.
I don't know that I heard the examples where it caused problems.
It might be 1.0, or it might be that multiplying by 2, 4, or 8 would
cause the problem. In any case, it was claimed to be a very expensive
retrofit.
Note that the 68881 also has guard digit problems for, if I remember,
the trigonometric functions. There is a story behind that one.
-- glen
| |
| Pierre Asselin 2005-11-28, 9:58 pm |
| FCC <fccaner@removemegmail.com> wrote:
> I cannot quite figure out the advantages of using/writing parsers. Would
> people in this list agree on NAMELISTs instead as a means of providing
> fast, intuitive and error-free input to the program? Obviously writing
> parsers is much more complicated compared to using NAMELISTs.
Namelist has a few limitations:
* the strings in the input files have to match the variable names;
usually that is not a problem but it is a constraint.
* the file systax gets ugly if you try to put arrays or variables
of user-defined types in the namelist.
That said, namelist will do a lot of your work for essentially zero
effort.
--
pa at panix dot com
| |
| Gary L. Scott 2005-11-28, 9:58 pm |
| Dan Nagle wrote:
> Hello,
>
> FCC wrote:
> <snip>
>
>
>
> I think namelist is great. Are the critics also advocates
> of other languages?
>
I think it's pretty neat also...but needs more detailed error reporting
(i.e. did variable 2 overflow, was variable 3 non-character data, etc.)
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Ron Shepard 2005-11-29, 3:58 am |
| In article <dmg9un$1j2$2@reader2.panix.com>,
pa@see.signature.invalid (Pierre Asselin) wrote:
> Namelist has a few limitations:
> * the strings in the input files have to match the variable names;
> usually that is not a problem but it is a constraint.
> * the file systax gets ugly if you try to put arrays or variables
> of user-defined types in the namelist.
It has other problems too. The variables cannot be dummy or
allocatable arrays or scalar variables with nonconstant length.
Also, the variables cannot be pointers or structures that contain
pointers. If the namelist statement is in a subprogram, then even
local variables cannot be included unless they are SAVEd.
These restrictions seem to be arbitrary to me. You can write your
own namelist-equivalent I/O that does not contain these limitations,
so the restrictions are, in principle, unnecessary.
$.02 -Ron Shepard
| |
| Dave Thompson 2005-12-05, 3:57 am |
| On 21 Nov 2005 11:52:33 -0800, phaccount@nycap.rr.com wrote:
<snip>
> Second comment: The very example above always makes me wish for inline
> declarations. I would like to be able to declare iCase just before the
> loop, because, at least the way I write code, iCase will be used _only_
> in that loop, and nowhere else outside of it. If I have 2 loops where
> I am looping over the same case, I try to find meaningfull names such
> as
>
> [wish: integer iPass1]
> Pass1: do iPass1=1,cCase[s]
> ...
> end do Pass1
>
> [wish: integer iPass2]
> Pass2: iPass2=1,cCase[s]
> ...
> end do Pass2
>
> Any practical reason why that is not part of the standard (I believe
> C++ allows for that, not that fortran must follow C++ in every
> particular detail)?
>
C++ does allow declarations in the middle of a block, essentially in
place of any statement. ('Statement' in C or C++ is only executable,
excluding declarations and stuff like routine headers.) C also allows
this as of C99, full implementations of which are not yet common, but
this particularly feature is often provided as an extension in C89.
The actual syntax of the declaration and of the loop are different in
C++ and C than in Fortran, of course.
C (all versions) and C++ also allow you to _enforce_ the locality of
the variable by using a nested block:
void foo (int *a /* array in C passed as pointer */)
{
double x = 0.0;
{ int i1;
for( i1 = 0; i1 < N ++i1 ) { prep (a[i1]); }
i1 = i1 / 2; guess (i1); /* midpoint */
if( i1 > 666 ) dobig (a); else dosmall (a);
}
{ int i2 = N / 42;
/* you can't use i1 here by mistake */
while( a[i2] > 0 ) { i2 = iter (a[i2]); }
}
/* you can't use i1 here either, nor i2 */
}
/* note: compressed for posting. This spacing and bracing style
not necessarily recommended for real code. */
And for the specific case of a 'for' loop, in standard C++ and C99 but
not C89 the loop itself can localize a variable (or several) without
an (explicit) extra block:
void foo ()
{
for( int i = 0; i < 10; ++i ) { blahblah (i); }
/* note the typespecifier int */
/* i is no longer available here */
}
Pre-standard C++, nicknamed "ARM" after the Stroustrup book (C++
Annotated Reference Manual) that defined it, _does_ keep such a loop
variable in scope and existence until the end of the _containing_
block, and one common compiler (M$VisualC++) still (AFAIK) implements
the ARM rule by default (AIUI because MFC needs it) although there is
an option to obtain the standard behavior.
- David.Thompson1 at worldnet.att.net
| |
| Jan Vorbrüggen 2005-12-08, 3:58 am |
| > Character and structure types are
> unnecessary when you stick to numerics (rule 3).
I disagree - I still want structures to organize all those scalar
and short-vector parameters driving the algorithm(s). 187.facerec
from SPEC CFP2000 mostly keeps to what you are advocating, but it
definitely wants structures. Oh, and formatted I/O (for specdiff
to work properly(, and single-precision reals must be OK for signal
processing.
Jan
| |
| Richard E Maine 2005-12-08, 7:15 pm |
| Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:
>
> I disagree - I still want structures to organize all those scalar
> and short-vector parameters driving the algorithm(s).
I've mostly been keeping out of this thread (and intend to mostly stay
that way), but I want to express emphatic agreement with Jan here. I
used f77 as my primary language since about 1968, but around 1990, there
were two things that drove me to spend a lot of time looking for another
language. I experimented with several others, finding none that
satisfied me, before settling on f90...at some risk, because there
weren't even any compilers yet, but I was desparate. I had concluded
that the lack of those two things in f77 was just intolerable in terms
of the effort required for workarounds. Yes, it is possible to code
numerics without them, or to hack system-dependent tricks, but I found
that unacceptable.
The two things in question were dynamic storage and structures. I later
learned to appreciate many other things about f90, but those were the
two features that drove my abandonment of f77. I find structures an
immense help in organizing data, and thus improving the readability,
reliability, and mantainabilioty of codes. Yes, that includes purely
numeric codes.
To me, managing data without structures is a lot like structuring code
using nothing other than conditional goto statements. Yes, you can. But
you pay a severe penalty, which grows with the size of the code.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Catherine Rees Lay 2005-12-09, 4:15 am |
| Richard E Maine wrote:
> Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> wrote:
>
>
>
>
> I've mostly been keeping out of this thread (and intend to mostly stay
> that way), but I want to express emphatic agreement with Jan here. I
> used f77 as my primary language since about 1968, but around 1990, there
> were two things that drove me to spend a lot of time looking for another
> language. I experimented with several others, finding none that
> satisfied me, before settling on f90...at some risk, because there
> weren't even any compilers yet, but I was desparate. I had concluded
> that the lack of those two things in f77 was just intolerable in terms
> of the effort required for workarounds. Yes, it is possible to code
> numerics without them, or to hack system-dependent tricks, but I found
> that unacceptable.
>
> The two things in question were dynamic storage and structures. I later
> learned to appreciate many other things about f90, but those were the
> two features that drove my abandonment of f77. I find structures an
> immense help in organizing data, and thus improving the readability,
> reliability, and mantainabilioty of codes. Yes, that includes purely
> numeric codes.
>
> To me, managing data without structures is a lot like structuring code
> using nothing other than conditional goto statements. Yes, you can. But
> you pay a severe penalty, which grows with the size of the code.
>
I'd agree here - you can make pseudo-structures in f77, for instance by
using a naming convention for your arrays to ensure that they are
visually grouped, combined with named parameters for indexes. However,
I'd say that designing this actually requires more thought and work of
the sort the OP wanted to avoid (i.e. the type of thing you do for
preoduction code, not personal code) than using the structure in the
first place.
You can often keep it simple at the next level, though - by just using
the structure to group related arrays and variables, and avoiding
structures within structures.
Catherine.
|
|
|
|
|