Small Language Wanted
Benjamin T Dehner
(Edward J. Hartnett) writes:
> In article <1992Aug25....@linus.mitre.org> craw...@church.mitre.org
(Randy Crawford) writes:
> >In article <DAVIS.92A...@pacific.mps.ohio-state.edu>
da...@pacific.mps.ohio-state.edu (John E. Davis) writes:
>
> >>Yes
> >>Fortran is still superior to C for what it is intended to do: Numerical
Work.
> >>Anyone who ``regularly lambast physicists for using "old" languages like
> >>Fortran'' is a little ignorant in my view.
> >
> >On a single statement basis, I'd agree: FORTRAN has it over C in expressing
> >numeric computations (you forgot to mention the problems C has in evaluating
> >expressions having mixed numeric types). But if you've ever attempted to
> >modify or even read a large FORTRAN program, you've experienced what I have
> >-- a rat's nest. I don't believe it's possible to write modular FORTRAN
> >code: at least, I've never seen it. And unless FORTRAN 90 eliminates
> >constructs like computed gotos, FORTRAN code will never become structured or
modular.
>
> I must disagree. While it is true that C is more often written more modular,
it is
> certainly possible to write well-behaved FORTRAN code. I think that
> what you are seeing is not that FORTRAN lends itself to rotten code,
> but that scientists usually write bad code, in whatever language they
> use. No offense to scientists, but I have rarely if ever seen a
> scientist who was a good programmer. They may know the language inside
> out, they may be able to whip up their application in a day that would
> take me a week, but take a look at it and you'll barf. Partly I think
As a scientific programmer, I have no choice but to agree with the
above statement. I am curently working on a program that was originally
written in the late 1960's, and has since been heavily modified. The original
code had almost zero documentation, and almost none of the hordes of people
who have gotten there hands in it since have explained what they did or what
they are trying to do. The only good thing about the code is that it is highly
structured with many subroutines, so that I can look at one part at a time.
> that this is because they have other things to worry about (like the
> purpose of the application, rather than implementation details),
> partly because it's part of the myth of science that scientists are
> smart, and so they think "I don't need to write simple, clear code,
> I'm smart enough to figure it out if I have to," and a big part of it
> is that they have either never studied programming, or they studied it
> so long ago that it was before modern programming, and the benifits
> thereof, were ever heard of. Essentially, they never know what they're
> missing. They think code is supposed to be badly documented, poorly
> structured, and difficult to understand.
No, often the code is not really meant to be used by other people.
Then when it does start getting spread around, ...
> I never use common blocks myself, ditto global variables (are their
> global variables other than in common blocks?). Subroutine arguments
> are always passed by reference, never value (how do you pass by
> value?). User defined data types (i.e. structures) are available in
> many implementations of FORTRAN (e.g. Sun), if you don't insist on
> standard FORTRAN 77, ditto for loop constructs. I have to say right
> here that I am talking about FORTRAN with extensions. I would never
> like to write in strict standard FORTRAN. But I think that commercial
> applications are rarely written in FORTRAN, and too many FORTRAN
> programmers don't use the language extensions, althought there is
> little chance they will ever have to port their code, and a good
> chance that if they do, the other machine will support the same or
> similar extensions.
The code I have mentioned above has been beat into as standard of
Fortran as could be managed. Anything nonstandard/system dependant is put
into a special set of subroutines. We can now routinely pass the code back
and forth from an Ultrix system to a VMS system, and by adding the special
subroutines -- about a 100 line file (out of about 12700 for the rest of the
program) compile and run with no problem.
> >
> >I think the real advantage that C has over FORTRAN (and Pascal has over C)
is
> >especially among undisciplined numerical programmers, where the "better"
> >language allows sufficient expressiveness to solve the problem, yet less
> >opportunity to write bad code. And it's easier for "part-time" programmers
> >to write bad code in FORTRAN than in C.
No. C is such a terse language it is very easy to write bad code.
It's your programming style and how much effort goes into making the code
legible that counts, which, as mentioned above, scientists who mostly used
Fortran tend not to do.
> Perhaps true, but learning C is a lot more difficult than learning
> FORTRAN. Plus you're just not going to get around those thousands of
> man-years of extant FORTRAN code!
-----------------------------------------------------------------------------
Benjamin T. Dehner Dept. of Physics and Astronomy
b...@iastate.edu Iowa State University
Ames, IA 50011
Charles J. Divine
>I don't believe it's possible to write modular FORTRAN code:
>at least, I've never seen it. And unless FORTRAN 90 eliminates constructs
>like computed gotos, FORTRAN code will never become structured or modular.
Perhaps we have different understandings of the words structured and
modular. But the place I worked at for most of the 80s insisted that
FORTRAN programs be structured and modular. After several years of
trying to fix code that _was_ a rat's nest, management opted for the
structured, modular approach. Since this place was hardly cutting
edge, I assumed they took their ideas from elsewhere. Yes, computed
gotos are a mess -- but programmers, analysts and management can
choose to not use them (which is what has happened at many places).
>I think the real advantage that C has over FORTRAN (and Pascal has over C) is
>especially among undisciplined numerical programmers, where the "better"
>language allows sufficient expressiveness to solve the problem, yet less
>opportunity to write bad code. And it's easier for "part-time" programmers to
>write bad code in FORTRAN than in C.
In many ways FORTRAN is more forgiving than C. For people who are
writing smaller programs (most of the programs I see here are written
by scientists and engineers and are quite small), the limitations of
FORTRAN are no real problem. Learning a new computer language can be
quite daunting for the part timer. I've written some elegant C
programs -- but then I make my living at it and I had the time to
really learn C. I still remember both how much freedom I had when
I began writing in C -- and how often I made subtle errors that
produced results at variance with what I wanted.
A colleague compares C to a high performance sports car -- brilliant
performance, no brakes.
--
Chuck Divine
Jim Giles
|> [...]
|> On a single statement basis, I'd agree: FORTRAN has it over C in expressing
|> numeric computations (you forgot to mention the problems C has in evaluating
|> expressions having mixed numeric types). But if you've ever attempted to
|> modify or even read a large FORTRAN program, you've experienced what I have --
Actually, the "rat's nest" problem is about the same for both languages.
The basic problem is that most *programmers* write in an unstructured
way. C programmers even call themselves (proudly no less!) "hackers".
To extemporize a program and then `hack' at it until it works is *NOT*
a structured way to proceed (yes, that *is* the meaning of the term
"hacker").
|> [...] I don't believe it's possible to write modular FORTRAN code:
|> at least, I've never seen it. [...]
I have. That's all I write in any language. This is true of *any* language
I use. Modular coding is a language independent concept and can be done
in assembler! In fact, the basis of "structured programming" (the original
definition of the term - not its modern useless meaning) is to write the
algorithm abstractly and select the actual language you're going to use
*afterwords*. Structured programming consists of iteratively refining
the algorithm to more and more specific forms - the *last* refinement is
to finally express the sub-modules of the algorithm in the actual programming
language(s). In a well designed environment, there should be several
languages available and they should be inter-callable.
|> [...] And unless FORTRAN 90 eliminates constructs
|> like computed gotos, FORTRAN code will never become structured or modular.
Computed GOTOs are not relevant to the issue of modular code. It is possible
to misuse setjump/longjump in C to a much *more* dangerous extent (the jumps
are not local), yet you don't claim that this makes modular code difficult
in C. Even GOTOs themselves are less restricted in C than in Fortran (you
can jump *into* a nested structure from outside).
Computed GOTOs have nearly *exactly* the same semantics as C's switch
(including the fall-through unless the user explicitly breaks out). True,
the computed GOTO is not required to properly nest, but C's ordinary GOTO
isn't either.
|> [...]
|> > The only real thing that I miss in Fortran 77 is a pointer type. There are
|> >many times when I wanted to pass pointers to functions through common blocks.
|>
|> I'd say this statement is a perfect example of where the difficulty lies in
|> FORTRAN: unstructured programming conventions and poor software engineering
|> practices. [...]
You mean like C's overuse of explicit pointers? This is usually a *very*
poor software engineering practice. It's worse than overusing GOTOs and
results in similar symptoms (spaghetti). Things for which aliasing is not
explicitly part of what you want to do should *never* be forced be implemented
with explicit pointers. This includes such things as dynamic memory, recursive
data structures, aggregate reshaping (that is, treating a 10x10 array as
a 100 long rank-one array for a while), etc..
|> [...] The problem lies in FORTRAN's common blocks and the popular
|> excessive use of global variables, [..]
Most C programs (that I've seen) excessively use globals too.
True, C has a poor MODULE-like functionality in the form of file-scoping
rules. Most Fortrans already have modules or soon will. Even so, *real*
modules have more similarity to COMMONs than to file-scoping: being named
aggregates. MODULEs can hold procedures as well as data (which makes
MODULE-private objects useful) and MODULEs are name associated instead
of storage associated, but those are the only differences from COMMON
(important though they are!). C files are not *named* aggregates though.
All objects exported from them are *individually* global. This is a much
more serious deficiency.
|> [...] poor control over subroutine argument
|> passing-by-value/passing-by-reference, [...]
C *requires* explicit user selection of these. I've never found this
level of "control" particularly useful. Especially since it is sometimes
desirable to alter a procedure which does one so that is does the other:
in C this requires altering all the *calls* to the procedure.
|> [...] NO user-defined data types, no recursion, [...]
Well, yes and no. Not having these things is better than having them in
a poorly implemented form (as C's user defined types are). Yes, recursion
is sometimes useful (though always less efficient - or, at best, equal *if*
your optimizer is up to snuff). Missing featurers can always be added by
future standards, poorly designed ones are very difficult to remove. Both
of these are in Fortran 90.
|> [...]
|> poor-to-nonexistant looping constructs, [...]
Huh? Minor syntactic sugar is missing. This makes *some* loops harder
to *read*. C also has illegible looping constructs - especially the
ubiquitous for() loop (which some style guides recommend for *all*
C loops). True, I'd like different syntax for WHILE and UNTIL loops,
different syntax for N TIMES loops, loops with iteration variables
defined (both covarying, and independently varying), etc. (in fact,
I think this is a very improtant issue since I think syntax is the
most important aspect of a language's legibility). Neither language
has a full set and those that C has are equipped with built-in
legibility problems. Fortran 90 is closer than either to a well
designed set of control flow constructs in general - loops being
a particular case.
|> [...] a dependency on gotos (and the very
|> existence of computed gotos) to a lack of [...] switch/case constructs,
|> etc, etc.
This is being inconsistent. Computed GOTO and C's switch have nearly
identical semantics. Just because C doesn't use the four characters
`g', `o', `t', and `o' doesn't alter this. If your complaint is that
*neither* language has a really *good* select/case feature, then I would
agree. Fortran 90 does is an improvement in this respect over both.
|> [... reordered ...] and archaic conditionals from .NE.
OK. On the other hand, a preprocessor which converts <, <=, ==, /= (I would
prefer ~= here), >=, and > to their corresponding Fortran is trivial to write.
I agree, these should be in the standard - they *are* in Fortran 90. Also,
.AND. should be written as /\, .OR. should be written as \/, .NOT. should be
written as ~, and .XOR. *could* be >< (though ASCII is inadequate to present
a really good xor operator), etc. - the committee was timid in its additions.
If you want to complain about bad operators though, C is the language with
the worst. Over 40 operators and 15 precedence levels (more than any other
language I've ever seen). Many of the operators are poorly chosen from the
available character set and are, as a result, difficult to read as well as
difficult to learn. The operators are at odds with the use of the same
characters in other conventional notations. For example `||' in mathematics
means "is parallel to"; `|' in most gramatical notations is "exclusive or"
(and elsewhere in UNIX is "pipe"); `!' of course is an exclamation (or a
factorial); K&R C doesn't allow unary plus (why?); unary minus has a different
precendence than infix minus; there are, unnecessarily, *two* selector operators
of `struct' variables (depending on whether they are pointed at or not); etc..
Add to that: contrary to human-factors studies on productivity and syntax,
C has expression level operators which cause side-effects.
|> [...]
|> While none of these affect the ability of the language to express numeric
|> computation on a single statement basis, any program of more than about 200
|> lines begins to get unwieldy and critical mass occurs at about 1000 lines.
|> This is unacceptable in modern programming languages, and _I_ think it
|> relegates FORTRAN and her afficionados to the dark ages of software engineering.
I also would put the trade-off between C and Fortran at about 200 to 1000
lines of code. Fortran is much better for the larger codes. C is like
Basic in that it's mainly good for trying out simple algorithms in the small
and not for large projects at all. *If* your algorithm can be efficiently
decomposed into lots of small independent procedures that don't need to
process arrays as first-class objects, C *can* still be used effectively.
|> [...]
|> I think the real advantage that C has over FORTRAN (and Pascal has over C) is
|> especially among undisciplined numerical programmers, where the "better"
|> language allows sufficient expressiveness to solve the problem, yet less
|> opportunity to write bad code. And it's easier for "part-time" programmers to
|> write bad code in FORTRAN than in C.
Well, it's harder for part-time programmers to learn enough C to write
good code with it. The typical learning curve for C is longer than for any
other language I'm familiar with. Parttime programmers are, by definition,
not people with the time to spend on this kind of learning - even if C
coding really did result in better coding practices (which I've not noticed
to be true). With respect to learning, Pascal and C are on the opposite
ends of the spectrum, with Fortran between them. For ad-hoc learning -
typified by the usual C approach - Fortran is the easiest to learn of all:
Pascal was designed to be a teaching tool, but only in a well-ordered
learning environment.
For a C-level language which is much better designed and *vastly* easier to
learn and to use, try Turing (invented at the University of Toronto). It's
slowly becoming more widely available. There are probably numerous others
I'm not aware of.
|> As I see it, a programming language has to be judged in the real world not by
|> what programmers can do _with_ it, but by what they can do _to_ it.
Oh, well if you want *extensible* languages, the functional languages (Scheme,
ML, Haskell, etc.) are the best. Object oriented languages come in a distant
second best (with C++ trailing that pack in terms of design quality). A close
third comes in the form of languages with generic procedure interfaces (a`la
Ada, though Ada has other problems - though it's still better than C overall).
It's not clear but that generic procedures might not be better than the object
oriented approach, but with Ada the only widespread example of the former, it's
hard to tell.
--
J. Giles
Jim Giles
|> scientist who was a good programmer. [...]
You must encounter a different set of scientists than I do. Most of
the ones who develop code at all - that I deal with - are among the most
talented programmers I've ever met. Possibly this is not common at the
*.edu sites.
To be sure, it is rare for a language to be designed with an eye toward
making the scientist's job easier. Often, the computer "scientist" will
respond to a feature request from a scientist with "who'd want to do that?"
Or with "you don't want to do that" (as if the scientist didn't know what
he wanted to do).
Now, it's true that most scientists are not code-developers at all and
don't know anything about it (this is changing). However, the fact that
people who never do code development are bad programmers doesn't seem
relevant.
--
J. Giles
Jim Giles
|> [...]
|> No, often the code is not really meant to be used by other people.
|> Then when it does start getting spread around, ...
Sort of like UNIX and C for example?
--
J. Giles
Craig Burley
_assigned_ GOTOs, right? I mean, computed GOTOs are fairly easy to figure
out; they're just a SELECT CASE with automatic "GOTO label" filled in for
each case from 1 to N. Assigned GOTOs, on the other hand, as in "GOTO I",
are really bizarre and hard to read and maintain, and often are used to
implement "inline subroutines" and the like.
Given SELECT CASE in F90, one doesn't really need computed GOTOs, but they
aren't really bad for readability. But assigned GOTOs are really a pain
for everone, programmer and implementer both!
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Thomas Koenig
>I never use common blocks myself, ditto global variables (are their
>global variables other than in common blocks?).
I take it you never use any NAG, IMSL or similar routines, then. If, for
example, you want to call a general - purpose root finder, you will have
to pass it the function to be solved, via an EXTERNAL argument. If you
you want to communicate with that function, COMMON (which is indeed the
only kind of global variable FORTRAN supports) is the only way to do it.
--
Thomas Koenig, ecm...@ccu1.aukuni.ac.nz, ib...@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
Ajay Shah
>In article <1992Aug25....@colorado.edu>, e...@khonshu.colorado.edu (Edward J. Hartnett) writes:
>|> [...] No offense to scientists, but I have rarely if ever seen a
>|> scientist who was a good programmer. [...]
>You must encounter a different set of scientists than I do. Most of
>the ones who develop code at all - that I deal with - are among the most
>talented programmers I've ever met. Possibly this is not common at the
>*.edu sites.
I agree with the original poster -- in general good scientists are
focussed on their application areas and simply don't invest in knowing
about computers. Long experience often makes them good coders, but
rarely good programmers. Look at the accent on fortran, for example:
how could a good programmer possibly use fortran? It has to be the
case of a person who wants to get a job done and doesn't take interest
in the means.
There are exceptions, of course. Generally coinciding with the trend
away from fortran.
No .edu bias that I can see in this phenomenon.
-ans.
--
Ajay Shah, (213)749-8133, ajay...@usc.edu
Wade Schuette
>In article <1992Aug25....@colorado.edu>, e...@khonshu.colorado.edu (Edward J. Hartnett) writes:
>|> [...] No offense to scientists, but I have rarely if ever seen a
>|> scientist who was a good programmer. [...]
>
>You must encounter a different set of scientists than I do. Most of
>the ones who develop code at all - that I deal with - are among the most
>talented programmers I've ever met. Possibly this is not common at the
>*.edu sites.
>
>To be sure, it is rare for a language to be designed with an eye toward
I'd pick up on that last point with a tangent on supercomputer and
parallel computer compilers and languages, including Fortran.
Japan apparently is far ahead of the US in terms of making complex
technology friendly to mortals. This may have changed (?), but as
of a few years ago the percent of Japanese scientists who used
supercomputers was WAY ahead of the percent in the US, and the
reasons seemed to be that the Japanese didn't expect the _SCIENTIST_
to have to learn how to parallelize his/her code, as the compiler
did that. So the physicist or biologist could work on their work,
not spend weeks in sessions on learning how to write paralle fortran.
Has that changed?
For that matter, does anyone know if the current supercomputer
compilers are bright enough to watch their own output actually run
and learn from it so on their NEXT pass they can stop guessing and
make better decisions as to how to optimize the data-dependent sections
of code? Or are humans still supposed to do THAT as well? I never
could understand why code intended to be run ten million times couldn't
watch its own work a little and adjust bad decisions made in earlier
compiles. Sometimes it wouldn't converge, but I'd think a lot of
programs run almost identical jobs (just as poorly) over and over and
over on almost identical data sets.
Seems like a small amount of applied AI could have a large impact on
such code. Also seems that the supercomputer is the only thing around
smart enough to watch itself and handle this adjustment, and not only
no scientist outside the field, but almost no human inside the field
could track the algorithms to do this by hand after the fact.
Comments?
--
==================================================================
R. Wade Schuette schu...@wl.com Ann Arbor, MI, USA
Andy Feldt
>j...@cochiti.lanl.gov (Jim Giles) writes:
> -ans.
The use of Fortran among scientists is partly historical, but there is
another very good reason why most scientists I deal with (including
some of the best programmers I have seen) use Fortran - it produces
the fastest code for floating point arithematic and has complex
data types built-in to the language. A good programmer chooses the
language which is best suited to his needs. (I am biased towards those
needs that physicists and astronomers have, since that is my point
of reference...)
--
Andy Feldt
System Support Programmer
Department of Physics and Astronomy
The University of Oklahoma
Mark C. Langston
> In article <1992Aug25....@colorado.edu>, e...@khonshu.colorado.edu (Edward J. Hartnett) writes:
> |> [...] No offense to scientists, but I have rarely if ever seen a
> |> scientist who was a good programmer. [...]
>
> You must encounter a different set of scientists than I do. Most of
> the ones who develop code at all - that I deal with - are among the most
> talented programmers I've ever met. Possibly this is not common at the
> *.edu sites.
I don't think one could segregate along *.edu sites...
>
> To be sure, it is rare for a language to be designed with an eye toward
> making the scientist's job easier. Often, the computer "scientist" will
> respond to a feature request from a scientist with "who'd want to do that?"
> Or with "you don't want to do that" (as if the scientist didn't know what
> he wanted to do).
>
> Now, it's true that most scientists are not code-developers at all and
> don't know anything about it (this is changing). However, the fact that
> people who never do code development are bad programmers doesn't seem
> relevant.
>
> --
> J. Giles
I think there is a trend towards scientists in general starting to write
code. Whether it is _good_ code, however, is another subject. But, if
these scientists are going to have to re-use, modify, adapt, or port their
code, they will soon learn that some techniques are cleaner than others.
True, many scientists haven't taken the time to take a programming course.
But then, isn't experience the best teacher? How many wonderful programmers
do you know that got that way without years of personalo problem-solving
code development?
And, being a good programmer has never been a prerequisite for being a
good scientist...just makes it easier, sometimes. And the more computer-
literate scientists there are, the more scientists with good programming
skills will emerge.
--
+--------8<------Cut Here------8<------Cut Here------8<------Cut Here---------+
Mark C. Langston | "Secrecy is the beginning of tyranny."
Psychology Dept. | "Always listen to experts. They'll tell you what can't
Memphis State U. | be done, and why. Then do it."
"Pftph!" | -From the notebooks of Lazarus Long
John Prentice
>
>how could a good programmer possibly use fortran? It has to be the
>case of a person who wants to get a job done and doesn't take interest
>in the means.
>
One is tempted to suggest that many CS types are merely interested
in the means and not in actually getting the job done. But to really
address your question, the answer is obvious to anyone who has much
experience in serious scientific computing. Fortran is still the
fastest language out there for the vast majority of problems. If
that changes in the future, say with functional languages, then you
will see scientists switching to those languages. It is precisely
the fact that scientists are interested in doing science, not in
programming purity, that drives their choice of language. In that
sense, they are way ahead of the types who will endlessly debate
whether one language is better than another.
As to whether scientists make good programmers, I have seen lots of
scientists who are bad programmers and a few who are very, very good.
I would say that on average, scientists don't pay enough attention
to software engineering issues and are slow to learn and adopt modern
programming techniques or languages. However, turn it around. How
many great professional programmers are good scientists? And if the
answer is very few (which it is), then you have to ask the question
of whether the CS community is even vaguely aware of what scientists
do with computers or what they really need in terms of languages and
software tools. If they were, then there would not be so many people
aghast at the use of Fortran in the scientific community.
My final comment is my stock one about Fortran. Continuing to
debate the pros or cons of Fortran 77 is a cheap shot, not worthy
of serious discussion. Fortran 77 is out of date, everyone agrees
with that. Fortran 90 is a modern language, with certainly as much
claim to that title as languages like C. You can argue the merits
of some of what is in Fortran 90, and I would welcome such a
discussion. But at least we would then be debating where the
scientific programming community is today, not where it was 20
years ago.
John
--
John K. Prentice
Quetzal Computational Associates
3200 Carlisle N.E., Albuquerque, NM 87110-1664; 505-889-4543
jo...@spectre.unm.edu -or- jkp...@cs.sandia.gov -or- jo...@aquarius.unm.edu
Doctor FORTRAN
> . . . . Bad C code is bad in truly awful ways.
"Good" C code is bad in truly awful ways, too.
As for eliminating computed GOTOs, to say nothing of arithmetic IFs (yuck!),
I say it's better to keep 'em, but strongly discourage their use. There's a
lot of old code out there that contains these archaic constructs (and there's
even more not-so-old code out there that contains the soon-to-be archaic
non-computed, unleaded GOTO). Keep the old constructs for compatability's
sake; encourage the use of the more modern constructs for new code.
==Doctor FORTRAN
Bill Venables
Michal> ... about 70% of the C code I had to work with was
Michal> badly written because of:
Michal> - ...
Michal> - making use of case sensitivity (i.e. symbols 'value' and 'Value' in the
Michal> same program)
Michal> - ...
I'll accept all the other points, but NOT this one. The concept of "case"
is a printing artefact and makes no sense in this context. What's wrong
with using all 52 letters in the character set? What could be more natural
than using "x" for a singly indexed array and "X" for a doubly indexed one?
Most versions of Fortran now do allow mixed case input (thank goodness -
otherwise you would go deaf reading the stuff) but then to regard "i" and
"I" as the *same* is a absolute gotcha.
It's case INsensitivity that is the real syntactic curse in any language
(or operating system for that matter).
--
___________________________________________________________________________
Bill Venables, Dept. of Statistics, | Email: vena...@stats.adelaide.edu.au
Univ. of Adelaide, South Australia. | Tel: +61 8 228 5412 Fax: ...232 5670
Uwe Kloss
> (Old K&R C might take something like
> `x = (a * b) / c' and rearrange it as `x = a * (b / c)' which could be deadly
> for many algorithms).
If you find a compiler (K&R) who does this, trash it and blame
it on the implementor!
This is definitely wrong behaviour, even for K&R!
> In addition, C has nothing equivalent to Fortrans **
> operator nor does it have complex types.
The differeces between code the compiler generates and
the one that is linked as a library or inserted by the
preprocessor.
> And arrays, C has no true array type
> like Fortran does (One must use pointers to pointers ... to pointers).
Did you ever try: int a[12][34];
And : a[x][y] = somewhat;
> Yes Fortran is still superior to C for what it is intended to do:
> Numerical Work.
This is mainly because, as you said, there's much 'canned solutions'.
> Anyone who ``regularly lambast physicists for using "old" languages like
> Fortran'' is a little ignorant in my view.
Let's say that's not very polite! ;-)
By the way, what does 'lambast' really mean?
I can guess it from the text, but never came across it yet.
Uwe
--
Eliminiere das Unmoegliche. Was immer uebrig bleibt, so
unwahrscheinlich es auch wirkt, muss die Wahrheit sein.
Aber was ist, wenn einmal NICHTS mehr uebrig bleibt?
(nach: John Brunner - Mehr Dinge zwischen Himmel und Erde)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Uwe Kloss UUCP: UweK...@lionbbs.bs.open.de
Fasanenstrasse 65 BTX: 0531336908 0001
3300 Braunschweig FIDO: not connected
Thomas Koenig
>For that matter, does anyone know if the current supercomputer
>compilers are bright enough to watch their own output actually run
>and learn from it so on their NEXT pass they can stop guessing and
>make better decisions as to how to optimize the data-dependent sections
>of code? Or are humans still supposed to do THAT as well?
Current supercomputer compilers still depend to a large extent on
local compiler options, like the C$DIR IVDEP - lines for the Crays.
Some of them are a bit more sophisticated; a Fujistu VP will vectorize
code like
K = 1
DO 10 I=1, N
IF (A(I).GT.0.) THEN
A(K) = A(I)
K = K+1
ENDIF
10 CONTINUE
if you assert that I.GE.K for the whole body of the loop. This kind of
assertion can be pretty dangerous, however; if you get it wrong, your
program will give you wrong results.
FORTRAN 90 will hopefully eliminate most of the need for sprinkling a
program with options, once it comes into widespread use. One thing it
will not eliminate, however, is the need to choose data structures
carefully before ever writing the first line of code.
Wade Schuette
>|> [...] No offense to scientists, but I have rarely if ever seen a
>|> scientist who was a good programmer. [...]
>
>You must encounter a different set of scientists than I do. Most of
>Now, it's true that most scientists are not code-developers at all and
>don't know anything about it (this is changing). However, the fact that
>people who never do code development are bad programmers doesn't seem
>relevant.
OK, so having gone back and forth, maybe we have a sense now that there
are scientists who write good code and scientists who don't, perhaps in
a different ratio than people who spend more time focusing on programming
issues.
Can we focus some attention on what CAN and SHOULD be taught to the
scientists who would prefer to write good code and are reasonably bright
but extremely busy. On a very practical, very pragmatic basis.
Suppose you can get 45 minutes of time, and hold a seminar on What every
scientist should know about computing but probably doesnn't... or some such.
One shot. The room is impatient. The top people are late. (the projector
doesn't focus.) Now what? This is a serious question, as I'd like to do
precisely this, for an audience of primarily biological / chemical
researchers. Software Engineering 101, extremely applied, for people
heavily into Fortran and "getting results today."
Or maybe, this: if you had ONE thing you could try to get across, that would
make sense to that audience in that time frame, what would it be?
Thomas Koenig
>Suppose you can get 45 minutes of time, and hold a seminar on What every
>scientist should know about computing but probably doesnn't... or some such.
[...]
>Or maybe, this: if you had ONE thing you could try to get across, that would
>make sense to that audience in that time frame, what would it be?
Probably, the one thing I would try to get across is: If you have that
problem, chances are other people have stumbled across it before. See
wether you have part of the solution already handy, in the shape of
NAG, IMSL, or Netlib, or somewhere in your own department. Make sure
that software which gets written is reusable; make the writers DOCUMENT
their stuff.
Oh yes, and make the people use either straight SI units (without any
multiplicators) or dimensionless numbers. I recently had to wade through
a lot of subroutines which were calculating phyiscal properties of
substances; unfortunately, the author had neglected to write down the
dimensions. He had used kJ, diffusion coefficients in cm^2/s,
temperatures in both Kelvin and deg C, pressure in bar, ... wading
through all that almost took as much time as rewriting it from scratch.
Pete Roth
]OK, so having gone back and forth, maybe we have a sense now that there
]are scientists who write good code and scientists who don't, perhaps in
]a different ratio than people who spend more time focusing on programming
]issues.
Determining "who's good at laying code" has been a problem for decades.
Usually, the results of studies show that the "best" folk are better than
the "worst" folk by a _factor_ of 25, on whatever measure you want to make.
And it doesn't depend on "scientific" training, either. My own hypothesis
is that somehow music adepts are better than the tone deaf, but that's just
a hunch...
]Can we focus some attention on what CAN and SHOULD be taught to the
]scientists who would prefer to write good code and are reasonably bright
]but extremely busy. On a very practical, very pragmatic basis.
]Suppose you can get 45 minutes of time, and hold a seminar on What every
]scientist should know about computing but probably doesnn't... or some such.
[...]
] This is a serious question, as I'd like to do
]precisely this, for an audience of primarily biological / chemical
]researchers. Software Engineering 101, extremely applied, for people
]heavily into Fortran and "getting results today."
]Or maybe, this: if you had ONE thing you could try to get across, that would
]make sense to that audience in that time frame, what would it be?
What do you mean when you say "good code"?
Fast running? Cheap to write? Maintainable? Portable?
"The easiest program to write is the one you don't have to write." Are
there commercial packages that do most of what your folk want?
Are these folk extremely busy because they have to deal with mounds of
rotting code?
Let's suppose they're interested in using powerful tools but
don't want to be bothered "maintaining" their or their colleagues' code.
45 minutes is just enough time to recommend that the organization start
switching to an Object Oriented approach. Note however, that there IS a
learning curve associated with this new paradigm...
regards, pete
- - - - - - - - - - - - - - - - - - - - - - - - - -
Peter N Roth ro...@oasys.dt.navy.mil
"Never argue with someone who buys ink by the barrel." - Daniel Janal.
J. D. McDonald
>j...@cochiti.lanl.gov (Jim Giles) writes:
>>In article <1992Aug25....@colorado.edu>, e...@khonshu.colorado.edu (Edward J. Hartnett) writes:
>>|> [...] No offense to scientists, but I have rarely if ever seen a
>>|> scientist who was a good programmer. [...]
>>You must encounter a different set of scientists than I do. Most of
>>the ones who develop code at all - that I deal with - are among the most
>>talented programmers I've ever met. Possibly this is not common at the
>>*.edu sites.
>I agree with the original poster -- in general good scientists are
>focussed on their application areas and simply don't invest in knowing
>about computers. Long experience often makes them good coders, but
>rarely good programmers.
That's an odd thing to say. If you write good code, you by definition
**are** a good programmer!! As the code **is** the program.
>Look at the accent on fortran, for example:
>how could a good programmer possibly use fortran?
Why not? It (i.e. Fortran 77) is just fine for most scientific calculation
purposes. Its not really good, it is true, for complex user interaction
tasks. But if your particular computer has calls to non-blocking input
and c-style output, its still doable.
Doug McDonald
J. D. McDonald
>schu...@wl.com (Wade Schuette) writes:
>Oh yes, and make the people use either straight SI units (without any
>multiplicators) or dimensionless numbers.
That is **TERRIBLE** advice for many cases. It would be OK to use
pure SI for a program to be used to teach freshman. But it would be wrong
fro most other purposes, certainly in my field. A good programmer
(well, a really topnotch one) would know better than that!!
Units are very important, not only for understanding, but, even more
important, for numerical accuracy. SI units are amost never the best ones
except for trivial codes.
Some sort of natural units are probably best for large calculations.
I personally loathe dimensionless units -- as, for example, are
traditional in quantum structure calculations or general relativity.
But that is amatter of taste, as they are often of a size that makes the
numbers close to one (i.e. quantum structure calculations).
Also, SI units are often not the units normally used when discussing
certain topics. For example, in my field, dynamics of chemical reactions,
SI units are essentially **never** used. Oh, people may quote heats of
formation in them, or laser pulse energies, but the pressures in reaction
chambers are never ever actually discussed in them - people usually use
torr. Energies are usually quoted in electron volts or, very common,
wavenumbers.
And the less said the better about the loathsome SI electromagnetic units,
which are so badly suited for calculations that the SI description document
mentions that fact and almost breaks down and says "for this purpose we
suggest you use Gaussian CGS".
SI is somewhat like Unicode (see comp.fonts and comp.std.internat) ....
It is an attempt by purists (note nationalistic flame to come: often
European rather than American) to dictate a purist approach that often
becomes piggishly silly.
Doug McDonald
paw...@vxdesy.desy.de
>>>>>> "Michal" == pawlak <paw...@vxdesy.desy.de> writes:
>
> Michal> ... about 70% of the C code I had to work with was
> Michal> badly written because of:
> Michal> - ...
> Michal> - making use of case sensitivity (i.e. symbols 'value' and 'Value' in the
> Michal> same program)
> Michal> - ...
>
> I'll accept all the other points, but NOT this one. The concept of "case"
> is a printing artefact and makes no sense in this context. What's wrong
> with using all 52 letters in the character set? What could be more natural
> than using "x" for a singly indexed array and "X" for a doubly indexed one?
>
> Most versions of Fortran now do allow mixed case input (thank goodness -
> otherwise you would go deaf reading the stuff) but then to regard "i" and
> "I" as the *same* is a absolute gotcha.
>
> It's case INsensitivity that is the real syntactic curse in any language
> (or operating system for that matter).
Did you ever try to DISCUSS your code with someone? How do you pronounce
capital letters then? Some people have 'verbal' memory (me for instance)
- I remember the word, not its graphical representation (therefore I also
have a lot of trouble if 'unnatural' identifiers are used). What to do
with such people? They will guaranteed mix such symbols... MixeD cASe
inPUT? YES! cASe seSitIviTy? NO!
Besides, with 31 letters allowed in identifiers I have 26^31 possible
identifiers (forgetting $, _, digits, shorter ones, etc). I don't really
feel I need more so urgently...
Michal
Dwight D. Moore
>...too much stuff to include...
>
There are really several problems when considering a "good programmer":
1. Good coding techiniques (modularity vs. the "one routine program", documenting
your code, readability, declaring your variables explicitly, name your variables
something useful instead of "th" or "de",...etc)
2. Efficient code (i.e. understanding the underlying concepts to improve code
performance). Do you index your array in declared subscript order (similar to
memory order, i.e. a[i][j][k], this makes a difference). Do you minimize your
expressions (removing extraneous mults by rephrasing your equation) or
replace division by mults when possible? I have seen where simple changes
in an equation in a loop improve performance and cut execution time in half.
3. Documentation. Do you document your code to indicate what is going on?
Readability, is part of documentation; the more readable your code is, the
easier it is to maintain, debug, port, etc. Is there paper documentation describing
methodologies, algorithms for your model, general approach to the problem?
Scientist that I have encountered generally learn (a few do, acutally) to write readable
code, and pick up a few tricks for efficient coding. This depends on the scientists
experience and training, but little exposure to good techniques, and good coding
techniques inhibits, their growth. If I taught a short lecture to a group of scientists,
I would focus on #1 and #3 (too many people under -estimate the value of #3) and
work on #2 later...you can always improve your code efficiency after it works, but
if it is hard to read, you will waste a lot of time trying to figure out where to start.
There is really a fourth category for using data structures, and maybe a fifth for
advanced programming concepts, but that isn't necessary when talking about scientific
models and Fortran 77, which is probably still the best language for scientific models.
----------------------------------------------------------------------------
Dwight D. Moore
Geosciences Computing Network
University of Oklahoma
dwi...@geohub.gcn.uoknor.edu (129.15.40.10)
These opinions do not necessarily represent the opinions of OU or the GCN.
----------------------------------------------------------------------------
Fergus James HENDERSON
>My final comment is my stock one about Fortran. Continuing to
>debate the pros or cons of Fortran 77 is a cheap shot, not worthy
>of serious discussion. Fortran 77 is out of date, everyone agrees
>with that. Fortran 90 is a modern language, with certainly as much
>claim to that title as languages like C. You can argue the merits
>of some of what is in Fortran 90, and I would welcome such a
>discussion. But at least we would then be debating where the
>scientific programming community is today, not where it was 20
>years ago.
Continuing to debate the pros or cons of C is a cheap shot, not worthy
of serious discussion. C is out of date, everyone agrees with that.
C++ is a modern language, with certainly MORE claim to that title
than languages like Fortran, even Fortran 90. You can argue about
the relative merits of C++ vs Fortran 90, and I would welcome such a
discussion. But at least we would then be debating the languages of
today, not those of 20 years ago.
:-) :-) :-)
P.S. At my institution, Fortran is taught in from 2nd year onwards,
while C++ is not taught at all. However they still teach Fortran 77,
and we do not have any Fortran 90 compiler. In contrast despite C++
not being taught at all we have not one but two C++ compilers.
--
Fergus Henderson f...@munta.cs.mu.OZ.AU
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!
Jim Giles
|> [...]
|> I agree with the original poster -- in general good scientists are
|> focussed on their application areas and simply don't invest in knowing
|> about computers. Long experience often makes them good coders, but
|> rarely good programmers. Look at the accent on fortran, for example:
|> how could a good programmer possibly use fortran? It has to be the
|> case of a person who wants to get a job done and doesn't take interest
|> in the means.
A good programmer *can* use *any* language and always picks the one
best suited to his task (Fortran in the case of scientific/numerical
work). A good programmer would *never* even use the argument that
language choice is a measure of *programmer* quality.
--
J. Giles
Jim Giles
|> [...]
|> Can we focus some attention on what CAN and SHOULD be taught to the
|> scientists who would prefer to write good code and are reasonably bright
|> but extremely busy. On a very practical, very pragmatic basis.
|> Suppose you can get 45 minutes of time, and hold a seminar on What every
|> scientist should know about computing but probably doesnn't... or some such.
Depending on the level of expertise and experience of the audience, this
is an easy question: for all but the most adept, the subject would be
the semantic properties of floating-point numbers. Only for *very*
advanced audiences would this be unnecessary instruction.
--
J. Giles
John Prentice
>jo...@spectre.unm.edu (John Prentice) writes:
>
>>My final comment is my stock one about Fortran. Continuing to
>>debate the pros or cons of Fortran 77 is a cheap shot, not worthy
>>of serious discussion. Fortran 77 is out of date, everyone agrees
>>with that. Fortran 90 is a modern language, with certainly as much
>>claim to that title as languages like C. You can argue the merits
>>of some of what is in Fortran 90, and I would welcome such a
>>discussion. But at least we would then be debating where the
>>scientific programming community is today, not where it was 20
>>years ago.
>
>Continuing to debate the pros or cons of C is a cheap shot, not worthy
>of serious discussion. C is out of date, everyone agrees with that.
>C++ is a modern language, with certainly MORE claim to that title
>than languages like Fortran, even Fortran 90. You can argue about
>the relative merits of C++ vs Fortran 90, and I would welcome such a
>discussion. But at least we would then be debating the languages of
>today, not those of 20 years ago.
>
>:-) :-) :-)
I think a more interesting issue is not C++ versus F90, if one wants
to frame it as a versus sort of issue, but rather the general idea
of OOPS versus conventional languages. I happen to think there is
alot of merit in OOPS and I think it has an unquestioned place in
scientific computing. However, I also think it is overhyped very
often. For example, one of the common claims for OOPS being the method
of choice for parallel computing is that you can easily hide the
underlying machine architecture from the programmer. This is said
to be good because it relieves the programmer of having to worry about
that architecture and promotes portability. The problem is that it
also promotes code inefficiency since the programmer, who understands
the data and logic structure of his code very well, is not able to
direct the computer to exploit that structure as efficiently if he
can't get to the underlying parallelization software. The idea of
hiding the nature of the computer from the programmer is not a bad
one for users doing small computing, but it is not acceptable when each
of your calculations takes 50 hours of Cray Y-MP or CM time. So
it is not that OOPS is bad, it is just that like everything, it has
a time and a place.
I would take the argument away from one over specific implementations
of these language ideas however. One reason is that as soon as you
start talking about C++, you are going to get jumped on by real OOPS
purists who will tell you that C++ is nothing but some OOPS ideas
layered on top of a bad conventional language (and they are arguably
correct). A real purist would insist on something like SmallTalk,
not C++. The pros and cons of that argument aside, the point is that
there *are* some very important issues for scientific computing with
regard to the use of OOPS and we should be thinking about them, not
about language wars.
While we are at it, we should be talking about functional languages
also. Their potential for applicability to scientific computing is
certainly as great as OOPS and possibily much greater. So, if people
would like to engage in a discussion of conventional versus OOPS
versus functional, I would find it valuable and fascinating.
As for Fortran 90, X3J3 did a good job of producing a modern dialect
of Fortran which compares well with every other conventional programming
language. But unlike virtually every other language out there, Fortran
is an evolving language. Fortran 77 was a major change from Fortran 66,
with new programming ideas incorporated into it. Fortran 90 is an even
more radical evolution. Work is now going on for the next version of
Fortran and what goes into it will be a function of what the user
community demands. Certainly, I would expect Fortran xx to encorporate
support of data parallelizm, perhaps control parallelism, and who knows,
perhaps even OOPS. What other language is making those kinds of
evolutionary strides, and doing so in the context of international standards
which preserve code portability across large numbers of computers?
The ANSI version of C, for example, did nothing more than clean up some of
the worst deficiencies of the original C, it introduced very little that
was new. So my point is, you can trash on Fortran for not being a
forefront language, and you would be largely correct. But you also
have to give it great credit for being the most dynamic of the major
languages (by which I mean languages in which people actually write large
programs), one which is contuously improving and evolving.
John
--
Dr. John K. Prentice
Partner, Quetzal Computational Associates
3200 Carlisle N.E., Albuquerque, NM 87110-1664; 505-889-4543
jo...@aquarius.unm.edu -or- jkp...@cs.sandia.gov -or- pren...@rufous.cs.unm.edu
Carl Gooch
>I don't mean to sound like I'm running down scientists at all. I'm
>just saying that the problems lie not in our stars, but in ourselves.
>You can have good programs in any programming language, and bad
>programs ditto. It's more a function of the programmer's outlook and
>training than the programming language (IMHO).
I'd agree with that. If you're writing a piece of code that you know
will be 5000+ lines and that you're going to have to maintain and
improve for a long time to come, you write it reasonably well in
self-defense. I'll grant that the definition of "reasonably well"
varies between individuals, but I doubt there are many large new
Fortran codes being written with flocks of arithmetic if's and
computed goto's.
>I never use common blocks myself, ditto global variables (are their
>global variables other than in common blocks?). Subroutine arguments
>are always passed by reference, never value (how do you pass by
>value?). User defined data types (i.e. structures) are available in
>many implementations of FORTRAN (e.g. Sun), if you don't insist on
>standard FORTRAN 77, ditto for loop constructs. I have to say right
>here that I am talking about FORTRAN with extensions. I would never
>like to write in strict standard FORTRAN. But I think that commercial
>applications are rarely written in FORTRAN, and too many FORTRAN
>programmers don't use the language extensions, althought there is
>little chance they will ever have to port their code, and a good
>chance that if they do, the other machine will support the same or
>similar extensions.
It's true that common blocks don't help code readibility, but there
are cases where not using them requires passing a long list of
parameters several steps up and down a call tree. In those cases, I
prefer to use common and pass only parameters which are immediately
relevant. (I also declare common blocks and the variables contained
in them in include files, so that I never have to worry about my
declarations of the same common block conflicting.)
Extensions like do-while loops are common enough that I use them
freely, partly because in an emergency, the changeover to if ... goto
... wouldn't be very painful. Structures I tend to avoid, in part
because that's a less common extension and in part because the changes
to unsnarl it would, generally, be rather large. If I were writing
for a single platform, I'd be a lot less picky about extensions.
Your mileage, of course, may vary.
Carl
--
------------------------------------------------------------------------------
Carl Gooch | Why am I inside at a keyboard when
go...@leland.stanford.edu | I could be outside riding bike?
------------------------------------------------------------------------------
Matt Kennel
: > In addition, C has nothing equivalent to Fortrans **
: > operator nor does it have complex types.
: The differeces between code the compiler generates and
: the one that is linked as a library or inserted by the
: preprocessor.
So? Again somebody telling us that we don't really want what
we say we want.
:
:
: > And arrays, C has no true array type
: > like Fortran does (One must use pointers to pointers ... to pointers).
: Did you ever try: int a[12][34];
: And : a[x][y] = somewhat;
Yes, but try to use "a" in a subroutine.
:
:
: > Yes Fortran is still superior to C for what it is intended to do:
: > Numerical Work.
: This is mainly because, as you said, there's much 'canned solutions'.
Perhaps, again, there's a reason, besides compatibility, why canned
solutions are STILL being written de novo in Fortran?
--
-Matt Kennel m...@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-*** lyapunov.ucsd.edu, username "anonymous".
Fergus James HENDERSON
>I think a more interesting issue is not C++ versus F90, if one wants
>to frame it as a versus sort of issue, but rather the general idea
>of OOPS versus conventional languages.
Actually I think that C++ would be a good language to use even if you
*didn't* use any of the OOP features, ie. just using C++ as a better C.
Just grab M++ or some other class library off-the-shelf and then
use C++ like a conventional language.
Then the extra features of C++ are available if you need them.
>I happen to think there is alot of merit in OOPS and I think it has an
>unquestioned place in scientific computing. However, I also think it
>is overhyped very often.
Yes, any new techniques in computer science are ALWAYS over-hyped.
OOP is not a panacea that will suddenly make programming complex systems
easy. However it *is* a significant improvement in the same way that
structured programming was a significant improvement over previous methods.
>For example, one of the common claims for OOPS being the method
>of choice for parallel computing is that you can easily hide the
>underlying machine architecture from the programmer. This is said
>to be good because it relieves the programmer of having to worry about
>that architecture and promotes portability.
If these are your goals, then it is can be good for these purposes.
>The problem is that it
>also promotes code inefficiency since the programmer, who understands
>the data and logic structure of his code very well, is not able to
>direct the computer to exploit that structure as efficiently if he
>can't get to the underlying parallelization software. The idea of
>hiding the nature of the computer from the programmer is not a bad
>one for users doing small computing, but it is not acceptable when each
>of your calculations takes 50 hours of Cray Y-MP or CM time.
If minimizing machine cycles is your goal, then of course programmers
will have to program at a lower level.
>So it is not that OOPS is bad, it is just that like everything, it has
>a time and a place.
Absolutely.
Fergus James HENDERSON
>UweK...@lionbbs.bs.open.de ( Uwe Kloss) writes:
>: > In addition, C has nothing equivalent to Fortrans **
>: > operator nor does it have complex types.
Note however that C++ does have complex types.
C++ has a pow() function instead of an ** operator.
Admittedly this is less convenient syntactically,
even though exactly the same code will be generated.
Some people on comp.lang.c++ have been proposing to add
an exponentiation operator to C++.
>: > And arrays, C has no true array type
>: > like Fortran does (One must use pointers to pointers ... to pointers).
>: Did you ever try: int a[12][34];
>: And : a[x][y] = somewhat;
>
>Yes, but try to use "a" in a subroutine.
void subroutine(int a[12][34]) {...}
If there are problems, could you please explain them better?
John Prentice
>
>Actually I think that C++ would be a good language to use even if you
>*didn't* use any of the OOP features, ie. just using C++ as a better C.
>Just grab M++ or some other class library off-the-shelf and then
>use C++ like a conventional language.
>
>Then the extra features of C++ are available if you need them.
Fair enough.
Thomas Koenig
>In article <1992Aug26.1...@ccu1.aukuni.ac.nz> ecm...@ccu1.aukuni.ac.nz (Thomas Koenig) writes:
[without being aware that he was writing flamebait, btw]
>>Oh yes, and make the people use either straight SI units (without any
>>multiplicators) or dimensionless numbers.
>That is **TERRIBLE** advice for many cases. It would be OK to use
>pure SI for a program to be used to teach freshman. But it would be wrong
>fro most other purposes, certainly in my field. A good programmer (well,
>a really topnotch one) would know better than that!!
Gee, thanks, but all I claim to be is to a good enough to get my
projects done:-)
>Units are very important, not only for understanding, but, even more
>important, for numerical accuracy. SI units are amost never the best ones
>except for trivial codes.
I have some trouble understanding that. How could one unit system be
more or less accurate than another? The only problem I can see is over-
and/or underflow. If your calculations involve squaring the charge of an
electron, for example, then SI units are certainly the wrong choice.
Characterizing problems where SI units give results which fall within
ten or fifteen orders of magnitute of unity (which all floating point
representations that I'm aware of can hold without problems) as trivial
seems to be somewhat of an understatement, however.
>Some sort of natural units are probably best for large calculations.
>I personally loathe dimensionless units -- as, for example, are
>traditional in quantum structure calculations or general relativity.
I find dimensionless numbers and dimensional analysis to be quite
valuable tools, especially in heat transfer and flow calculations (I'm a
chemical engineer, btw). Granted, dimensionless numbers are often not
easy to visualize. For a lot of problems, however, dimensional analysis
cuts down the parameter space to be investigated either with experiments
or by computation so dramatically that I am willing to put up with the
extra level of abstraction. Of course, many problems cannot be reduced,
such as describing a stirred chemical reactor.
>But that is amatter of taste, as they are often of a size that makes the
>numbers close to one (i.e. quantum structure calculations).
That is one of their nicer features, certainly.
>Also, SI units are often not the units normally used when discussing
>certain topics. For example, in my field, dynamics of chemical reactions,
>SI units are essentially **never** used. Oh, people may quote heats of
>formation in them, or laser pulse energies, but the pressures in reaction
>chambers are never ever actually discussed in them - people usually use
>torr. Energies are usually quoted in electron volts or, very common,
>wavenumbers.
Discussing 'heat of formation' with my thermodynamics professor would
have brought him close to apoplexy - are you talking energy or enthalpy
of formation there? I thought these old, inexact terms had long since
died the death they deserved...
If you look at single atoms, then SI units are indeed so far off unity
as to cause grave problems.
As far as giving the pressure in torr goes, that is fine as long as
you don't want to plug it into the ideal gas equation of state, for
example.
[comment about "loathsome" electromagnetic SI units and European purists
deteted]
Let me rephrase my piece of advice, then: In the sections of a program
which do the actual computation, choose either dimensionless numbers or
a consistent set of units, so that you can do the calculations
themselves with no conversion factors at all. All that conversion
factors do is introduce inefficiency and bugs. Conversion to other,
maybe more familiar units should be restricted to sections of code
dealing immediately with I/O. One consistent system in wide use is SI.
Can we agree on that? :-)
r...@dstos3.dsto.gov.au
> Can we focus some attention on what CAN and SHOULD be taught to the
> scientists who would prefer to write good code and are reasonably bright
> but extremely busy. On a very practical, very pragmatic basis.
> Suppose you can get 45 minutes of time, and hold a seminar on What every
> scientist should know about computing but probably doesnn't... or some such.
>
> One shot. The room is impatient. The top people are late. (the projector
> doesn't focus.) Now what? This is a serious question, as I'd like to do
> precisely this, for an audience of primarily biological / chemical
> researchers. Software Engineering 101, extremely applied, for people
> heavily into Fortran and "getting results today."
>
> Or maybe, this: if you had ONE thing you could try to get across, that would
> make sense to that audience in that time frame, what would it be?
>
Well, speaking as a scientist who dabbles with programming I would probably
give emphasis to the basics :
(a) if you plan to reuse your code, or give it to other people, put some
useful comments in. The biggest problems I've encountered when
other scientists give me code is receiving a subroutine, with no
accompanying notes or comments, and I then have to work out what
twenty arguments and ten arrays in common blocks actually do (No,
I'm not exagerating --- I had to spend 4 days with such a piece
of code recently :-().
(b) in numerical work, you will often find that it's been done before.
Be prepared to make use of NAG, IMSL, and good numerical packages
like that. The approaches they use will often be better (faster,
more accurate, etc.) that you could come up with yourself. If
they're too cheap to pay, there are texts on numerical analysis
(e.g. Numerical Recipes) and a number of good things in the public
domain --- usually not as good as the proprietary stuff, but
not bad. When you get some spare time, skim the documentation which
passes over your desk so you can be aware of where you might find
things you could need in the future.
(c) remember, the computer can't do your work for you. A number of
scientists on computers who I know fall back on number crunching
when they can't solve it by hand, and apply a brute force
approach --- looping over a large range in each of 20 variables
will eventually produce results, but only after a lot of grunt
is applied, and then you have to pore over many pages to find the
useful stuff. A bit of thought before unleashing the CPU can save
buckets of time.
(d) when you are testing code, test out one bit a time. Don't throw
together a large package, and try to fix all the problems at
the end.
(e) in a similar line to (d), when you receive code from someone else,
test it out using some (hopefully simple) test cases. A classic
I know of from my University days involved a PhD student who
got code via E-mail from a researcher overseas. After 6 months
of runs on almost every computer in the university, he stopped and
had a look at the data coming out. It was garbage. Turned out that
about two or three lines in a crucial subroutine got munged in
transmission.
Just my 2 cents worth.
Robert
--
---------------- <Standard Disclaimer>
Robert O'Dowd Phone : +61 8 259 7132
Bldg. 64 TSAN, AS/MOD Fax : +61 8 259 6104
P.O. Box 1650 E-mail : r...@dstos3.dsto.oz.au
DSTO Salisbury, South Australia OR r...@dstos3.dsto.gov.au
OR r...@mod.dsto.gov.au
Disclaimer: Opinions above are MINE, and probably worth what you paid for them.
Ross Taylor,Peyt312,6652,2655436
> In article <l9lrci...@almaak.usc.edu>, ajay...@almaak.usc.edu (Ajay Shah) writes:
> |> [...]
> |> I agree with the original poster -- in general good scientists are
> |> focussed on their application areas and simply don't invest in knowing
> |> about computers. Long experience often makes them good coders, but
> |> rarely good programmers. Look at the accent on fortran, for example:
> |> how could a good programmer possibly use fortran? It has to be the
> |> case of a person who wants to get a job done and doesn't take interest
> |> in the means.
This argument is ludicrous. I use Fortran because its best suited to the
jobs I do with it.
>
> A good programmer *can* use *any* language and always picks the one
> best suited to his task (Fortran in the case of scientific/numerical
> work). A good programmer would *never* even use the argument that
> language choice is a measure of *programmer* quality.
>
> --
> J. Giles
Here here, in my group we use Fortran, Pascal, Basic, C, C++ and assembler
(in decreasing order of frequency) depending on the task in hand. We even
have software systems that use 4 of these languages!
Ross Taylor
Toon Moene
writes:
[ ... Lots of stuff on language debate / programming proficiency
deleted ... ]
> Or maybe, this: if you had ONE thing you could try to get across, that
> would make sense to that audience in that time frame, what would it be?
The number of floating point numbers representable in N bits is strictly
less than the number of integers representable in N bits.
(Explanation: (why - this should be obvious) Scientists (at least the
people I work with) take the - infortunate - FORTRAN declaration of
floating point variables as REALs as a testimony that they have some
relation to the notion of the set of real numbers - silly sounds of
course: they're only a finite subset of the rationals ...)
--
Toon Moene (to...@moene.indiv.nluug.nl)
Kantershof 269, 1104 GN Amsterdam, The Netherlands
Tel.: + 31 20 6982029; Fax: + 31 20 6003411
No Disclaimers; a NeXT at home protects against this occupational hazard.
Edward J. Hartnett
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: scientists as programmers (was: Small Language Wanted)
References: <1992Aug25....@linus.mitre.org> <1992Aug25....@colorado.edu>
<1992Aug25.2...@newshost.lanl.gov>
<1992Aug26.1...@wl.com>
Distribution:
FCC: /home/khonshu/ejh/News/outgoing
--text follows this line--
In article <1992Aug26.1...@wl.com> schu...@wl.com (Wade Schuette) writes:
OK, so having gone back and forth, maybe we have a sense now that there
are scientists who write good code and scientists who don't, perhaps in
a different ratio than people who spend more time focusing on programming
issues.
Can we focus some attention on what CAN and SHOULD be taught to the
scientists who would prefer to write good code and are reasonably bright
but extremely busy. On a very practical, very pragmatic basis.
Suppose you can get 45 minutes of time, and hold a seminar on What every
scientist should know about computing but probably doesnn't... or some such.
One shot. The room is impatient. The top people are late. (the projector
doesn't focus.) Now what? This is a serious question, as I'd like to do
precisely this, for an audience of primarily biological / chemical
researchers. Software Engineering 101, extremely applied, for people
heavily into Fortran and "getting results today."
Or maybe, this: if you had ONE thing you could try to get across, that would
make sense to that audience in that time frame, what would it be?
==================================================================
R. Wade Schuette schu...@wl.com Ann Arbor, MI, USA
I think I should have been more clear when I said that scientists are,
in general, not as good programmers as professionals. I also make a
distinction between coding and programming, which is this: good code
is compact and efficient, but a good program is good code that is well
organized, and, most importantly, well documented.
If I could sit down all those scientists in a room and tell them one
thing, it would be that in all my experience programming, nothing is
more worthwhile than documentation. Particularly with science, if it's
not documented, it's almost useless, and will be completely useless
whenever it's handed to someone other than the original programmer.
Why? Because with science you have to KNOW what's going on in the
code. A small mistake can EASILY skew scientific results. And the time
invested in organization and documentation is more than repaid again
and again.
However, I don't think they'll listen. Why, I don't know, but it seems
impossible to convince a lot of them, unless they already have been
burned by having huge amounts of code turn useless at the departure of
a programmer. Then they might think "I don't want this to happen
again." However, with their own code, they will not get burned
like this, they will burn someone else maybe, but they won't be around
to witness that. And without that kind of experience, it's hard to
convince them that even working with their own code would be a lot
easier if it were better documented and organized.
I guess it's exactly the same with professional programmers; I wasn't
convinced of this until I ended up with a job working on someone
else's code, (in fact it's happened to me many times), and I almost
cry to see that so much of their work is wasted, and has to be redone,
when just a few hours a week would have made it permanently useful - a
springboard for their successors, instead of a millstone around their
necks. That's why I started being such a fanatic for documentation.
And it was only after that that I realized it was helping me a lot
too. I think few scientists go through this process, because they most
often start and work on their own projects - they don't often take up
where someone else left off, in the middle of the programs.
I certainly didn't mean to make such a blanket statement as
"scientists are bad programmers." What I should have said is that it's
unfortunate that so few scientists (in my experience) realize the
importantance of comprehensive documentation and well organized code.
C.S. and C.E. people tend to have this drummed into them more in their
training. (Scientists think "why?" Engineers think "how?").
Sorry about the length of the post!
--
Edward Hartnett e...@khonshu.colorado.edu
M. J. Saltzman
>
>>UweK...@lionbbs.bs.open.de ( Uwe Kloss) writes:
>>: > In addition, C has nothing equivalent to Fortrans **
>>: > operator nor does it have complex types.
>
>Note however that C++ does have complex types.
Complex types can be implemented as a class...
>[...]
>>: > And arrays, C has no true array type
>>: > like Fortran does (One must use pointers to pointers ... to pointers).
>>: Did you ever try: int a[12][34];
>>: And : a[x][y] = somewhat;
>>
>>Yes, but try to use "a" in a subroutine.
>
>void subroutine(int a[12][34]) {...}
>
>If there are problems, could you please explain them better?
No need to be so contrary. He's talking about writing subroutine() to
manipulate a generic multidimensional array with size not specified
until runtime.
--
Matthew Saltzman
Clemson University Math Sciences
m...@clemson.edu
Fergus Henderson
>In article <922401...@mulga.cs.mu.OZ.AU> f...@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>m...@lyapunov.ucsd.edu (Matt Kennel) writes:
>>
>>>UweK...@lionbbs.bs.open.de ( Uwe Kloss) writes:
>>>: > In addition, C has nothing equivalent to Fortrans **
>>>: > operator nor does it have complex types.
>>
>>Note however that C++ does have complex types.
> ^^^^
>Complex types can be implemented as a class...
The complex type is a standard part of C++.
Saying that C++ does not have a complex type is like
saying that C does not have any I/O.
In my opinion, the fact that it can be implemented using
the language rather than being a built-in special feature of
the language is an ADVANTAGE.
Languages like Fortran and Pascal have special primitives for
I/O that cannot be implemented using the language; rather they
must be part of the compilation system. Every such feature is
IHMO evidence of the weakness of such languages.
--
Fergus Henderson f...@munta.cs.mu.OZ.AU
This .signature VIRUS is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!
--
Fergus Henderson f...@munta.cs.mu.OZ.AU
This .signature VIRUS is a self-referential statement that is true - but
Jim Giles
|> [...]
|> >: > And arrays, C has no true array type
|> >: > like Fortran does (One must use pointers to pointers ... to pointers).
|> >: Did you ever try: int a[12][34];
|> >: And : a[x][y] = somewhat;
|> >
|> >Yes, but try to use "a" in a subroutine.
|>
|> void subroutine(int a[12][34]) {...}
|>
|> If there are problems, could you please explain them better?
try:
void subroutine(n, m, a[n][m]) {...}
Like for writing something as trivial as a matrix multiply routine
which can multiply conformable arrays of any size:
void mat_mult(i, j, k, a[i][k], b[i][j], c[j][k])
{... /* returns `a' since arrays are passed by reference */ ...}
Actually, this could be done by eliminating a *single* constraint in
the C standard - that is, the one which requires array sizes in declarations
to be constant-expressions instead of allowing expressions in globals and/or
preceeding parameters. I don't have the rationale document in from of me,
so I don't know why they left that constraint in (or if the explained at
all).
--
J. Giles
Jim Giles
|> [...]
|> I think I should have been more clear when I said that scientists are,
People who write scientific/numerical programs for a living (instead
of as an adjunct to their scientific work) *ARE* professionals. Yet,
their background is real science, not computing "science" (because no CS
type would even understand the problems).
|> [...]
|> If I could sit down all those scientists in a room and tell them one
|> thing, it would be that in all my experience programming, nothing is
|> more worthwhile than documentation. Particularly with science, if it's
|> not documented, it's almost useless, and will be completely useless
|> whenever it's handed to someone other than the original programmer.
|> Why? Because with science you have to KNOW what's going on in the
|> code. A small mistake can EASILY skew scientific results. And the time
|> invested in organization and documentation is more than repaid again
|> and again.
However, too many CS types view documentation as an end rather than
a means - that is, they write comments which do not elucidate:
x++; /* add one to x */
A good document consists of an abstract description of what the code
does, an abstract description of the algorithm which is being used, its
numerical properties, its speed (using big O notation if more precision
is not available). The code itself has only a *few* imbedded comments
which indicate the correspondence of the code to the abstract algorithm.
One should not try to explain the algorithm *with* interspersed comments,
nor should one merely restate in english what the specific statements do
(if you can't read the language, take a tutorial).
Too often, the CS style documentation contains headers which name
the programmer, give the date of completion of the code, the date
of the last modification or bugfix, the language used (as if you
couldn't tell by looking at the code itself), and some joke about
known bugs that the author will *soon* fix (though the last mod
was years ago and the author has since left). The author then
tries to explain the algorithm with interspersed comments *in* the
body of the code - and fails to write *either* a good description
of the algorithm *or* a good code. But it's "fully documented"
by the criteria they were tought in school.
|> [...]
|> I guess it's exactly the same with professional programmers; I wasn't
|> convinced of this until I ended up with a job working on someone
|> else's code, [...]
Gee, in *all* my jobs, for 20 years, I've had to work with someone
else's code. The dreaded "someone else's code" problem is commonplace
in programming.
--
J. Giles
Marc Roussel
writes:
>In <DAVIS.92A...@pacific.mps.ohio-state.edu>, "John E. Davis" writes:
>> In addition, C has nothing equivalent to Fortrans **
>> operator nor does it have complex types.
>the one that is linked as a library or inserted by the
>preprocessor.
That is a big difference! Consider the following Fortran program:
integer i
double precision a,b
a = 4.2
b = 9.3
i = 10
write(*,*)a**i,a**b
END
The compiler, faced with such a program, examines the types of the
arguments and generates completely different code to do the two
exponentiations; certainly, one calculation can be expressed exactly in
terms of multiplications while the other cannot. It may be more
efficient or more accurate to do it one way or the other and the
compiler can choose a calculation method which reflects current thinking
on this sort of problem.
Now consider an equivalent piece of code, written in C:
void main(){
int i;
double a,b;
a = 4.2;
b = 9.3;
i = 10;
printf(pow(a,(double) i),pow(a,b));
}
(You'll forgive me, I hope, for getting the C idiom slightly wrong.
The one manual I have at hand right now is less than entirely helpful on
several trivial details. In particular, I'm not at all sure that the
cast of i to double is entirely kosher, and I think that printf wants a
format specification. In any event, you get the general idea.) Can the
compiler play the sorts of tricks which the Fortran compiler was free to
do? I don't think so. pow() being a library routine, I don't think it
would be good form (or standard-conforming) for the compiler to guess at
the programmer's intent and to do anything more than to leave the
reference to be resolved by the linker. After all, until the library is
linked in, in principle the compiler knows nothing about any function
but perhaps its prototype. This particular library function
expects (I think) two doubles (floats?) and must be passed these.
That's all there is to it.
In my opinion, what C lacks to be able to handle these things
correctly is any concept of a "built-in" function. Fortran knows to
treat sin(a) and sin(x) differently if a is real and x is double
precision because knowledge of these primitive functions is built into
the compiler. C can't do anything like this because of its design. C
is great for writing wordprocessors, but not so great for scientific
computing for exactly this sort of reason.
Marc R. Roussel
mrou...@alchemy.chem.utoronto.ca
J A Stephen Viggiano
systems. You are encouraged to hit 'n' now!]
In article <l9lrci...@almaak.usc.edu> ajay...@almaak.usc.edu (Ajay Shah)
provides an invitation for a flame-fest, writing words of wisdom (NOT!)
as only Ajay can:
>I agree with the original poster -- in general good scientists are
>focussed on their application areas and simply don't invest in knowing
>about computers. Long experience often makes them good coders, but
>rarely good programmers. Look at the accent on fortran, for example:
>how could a good programmer possibly use fortran? It has to be the
>case of a person who wants to get a job done and doesn't take interest
>in the means.
Okay, Ajay, you really *asked* ^H^H^H^H^H^H^H *begged* for this one . . . .
I've made a little present for you . . . . hope you like it!
/\
| \
/\ |\ / \
/ \/ \ | | /\
| | \ \/ |
\ / \ /
\ / | /
\ / \ /
_---------------------------------------\
/ \ ___ ___ \
| | =-- --__==__ =-- --__= |
| | ___ ___ |
\ / =-- --__==__ =-- --__==__ /
-_______________________________________/
Just for Ajay Shah!!!
Once again, Ajay, you've got it wrong. You *always* get it wrong, don't you?
One could imagine that nobody takes you seriously, so you have to come on
the net, and put down a WHOLE CLASS OF PROFESSIONALS with your moronic (not
to say completely incorrect) statements like "how could a good programmer
possibly use fortran?" [sic] and that scientists are "rarely good
programmers". Let us know when you actually meet a scientist, will you?
What I am wondering about is why, if you think FORTRAN (that's "FORTRAN",
Ajay, not "fortran") is so lousy, WHY IN HEAVEN'S NAME TO YOU FOLLOW THIS
GROUP IN THE FIRST PLACE??? (Apologies to other members of the net for
shouting.) Seems to me that you only are interested in saying how much FORTRAN
stinks.
=============================================================
Insert tongue in cheek (in case you wonder)
=============================================================
RFD: comp.lang.ajay.thinks.fortran.stinks
This group will serve as a soapbox for but a single member of the network,
Ajay Shah. It will be unmoderated, and distribution will be worldwide, the
better for the whole world, civilized or not, to hear what that renown expert,
Ajay Shah, thinks about how awful the FORTRAN programming language is.
One of the first threads planned for the group is "Pants Against FORTRAN"
Day. Everybody who thinks FORTRAN is stupid is to wear pants, trousers, a
skirt, a dress, or some other "covering" for the lower portion of their
torso, on a to-be-determined day. In this way, the entire world will be able
to discern how many people think that FORTRAN is stupid by simply counting
the people who are not walking around with the lower portion of their
torsos uncovered.
Of course, nobody should be expected to actually subscribe to this group (save
Ajay's mom), so the group will be created on but a single "yes" vote.
=============================================================
Remove tongue from cheek
=============================================================
>No .edu bias that I can see in this phenomenon.
>--
>Ajay Shah, (213)749-8133, ajay...@usc.edu
^^^^^^^
Gosh, folks, sure looks like a .edu bias here. . . . Oh sorry, I guess Ajay is
above the rest of the folks in the ivory towers over at USC -- Ajay and Ajay
alone is able to transcend the transcendental transcendations of academia.
Sounds more like what Prof. Irwin Cory calls "Cacademia" to me.
Fergus James HENDERSON
>try:
>
> void subroutine(n, m, a[n][m]) {...}
>
>Like for writing something as trivial as a matrix multiply routine
>which can multiply conformable arrays of any size:
>
> void mat_mult(i, j, k, a[i][k], b[i][j], c[j][k])
> {... /* returns `a' since arrays are passed by reference */ ...}
>
>Actually, this could be done by eliminating a *single* constraint in
>the C standard - that is, the one which requires array sizes in declarations
>to be constant-expressions instead of allowing expressions in globals and/or
>preceeding parameters. I don't have the rationale document in from of me,
>so I don't know why they left that constraint in (or if the explained at
>all).
The constraint does make life quite a bit easier for compiler writers, which
was presumeably the reason it was there in the first place.
There *are* two possible remedies for this, although both have their
disadvantages. The first one is quite simple: gcc allows exactly the
construct you refer to. If you are willing to stick to the one compiler
(which *is* quite portable) then you can write code exactly like the
above. gcc even allows you to pass the array name before the array dimension,
so long as you forward-declare the dimension parameter, like thus:
mat_mult(int i, j, k; /* forward declaration of parameters */
int a[i][k], int b[i][j], c[j][k], int i, int j, int k);
The other solution is to use a C++ matrix class. Then you don't even need
to bother passing the dimensions, and you can even use natural mathematical
notation - ie. a = b * c, instead of mat_mult(i, j, k, a, b, c).
Fergus James HENDERSON
Well, you are wrong.
>pow() being a library routine, I don't think it
>would be good form (or standard-conforming) for the compiler to guess at
>the programmer's intent and to do anything more than to leave the
>reference to be resolved by the linker. After all, until the library is
>linked in, in principle the compiler knows nothing about any function
>but perhaps its prototype. This particular library function
>expects (I think) two doubles (floats?) and must be passed these.
>That's all there is to it.
No, in principle if the library function in question is a *standard*
library function, then its implementation is just a part of the
compilation system. When the compiler sees #include <math.h>, it can
- read /usr/include/math.h
- read foobar.xyzzy
- insert the appropriate declarations without reading any file.
Furthermore, when it sees
pow(a,i)
in your code, and "i" happens to be an integer then it can emit code to
- call the standard pow() function after convertin
i to a double
- call a special function the calculates doubles to
integer powers
- calculate the exponentiation using inline code.
Ie. it can make EXACTLY the same optimizations that Fortran compilers
make when they see a**i.
In other words, the _ONLY_ differences between an operator and a function are
(1) the syntax is different
(2) for the function, you should include the appropriate header file
before using it.
> In my opinion, what C lacks to be able to handle these things
>correctly is any concept of a "built-in" function. Fortran knows to
>treat sin(a) and sin(x) differently if a is real and x is double
>precision because knowledge of these primitive functions is built into
>the compiler. C can't do anything like this because of its design.
Yes it can.
Any function that is part of the standard library is a "built-in" function.
Matt Kennel
: library function, then its implementation is just a part of the
: compilation system. When the compiler sees #include <math.h>, it can
: - read /usr/include/math.h
: - read foobar.xyzzy
: - insert the appropriate declarations without reading any file.
:
: Furthermore, when it sees
:
: pow(a,i)
:
: in your code, and "i" happens to be an integer then it can emit code to
: - call the standard pow() function after convertin
: i to a double
: - call a special function the calculates doubles to
: integer powers
: - calculate the exponentiation using inline code.
Suppose in foo.c I do the above. Then in pow.c I have my own
new defintion of "pow" which does something different.
How does C know when compiling foo.c the difference :
cc -c foo.c
cc -o foo foo.o -lm
vs.
cc -c foo.c
cc -c pow.c
cc -o foo foo.o pow.o -lm
???
Or is this a resolved problem?
Question: Do you know which real live C compilers that people can buy or
steal which do in fact perform the optimizations that we're talking about?
Say, perhaps, computing pow(x,4) with *TWO* FP multiplications.
I suspect the percentage is about 85% for Fortran, and maybe 10% for C,
but I really have no idea.
: Fergus Henderson f...@munta.cs.mu.OZ.AU
: This .signature virus is a self-referential statement that is true - but
: you will only be able to consistently believe it if you copy it to your own
: .signature file!
--
Jeffrey Ungar
>
>In a previous article <DAVIS.92A...@pacific.mps.ohio-state.edu> I
>presented a C program which demonstrates that simply including math.h into a C
>program does not guarantee that `float y, x = 2.0; int i = 4; y = pow(x,i)'
>will produce the correct value for y as a previous poster suggested:
[deleted]
>
>It has been pointed out to me by several people that this is compiler
>dependent and the a true ansi compliant answer will produce the correct
>answer. This is because instead of a declaration like:
>
>the ANSI declaration would read:
>
> extern double pow(double, double);
>
>This has the effect of performing the correct typecasts before calling the
>function `pow'.
>But then this behavior contradicts something else the other poster said:
[compiler could use different methods for different argument
types, like putting x*x inline for pow(x,2)]
>Are there really any existing C compliers out there that perform such
>optimizations?
Yes. The Cray standard C compiler does this (and has "comformant arrays" and
complex data types as well) unless you turn off extensions -- it also
vectorizes all of these functions. The Watcom C compiler does not do this
but can place math functions inline in your code using 80387 instructions
like fsin and fsqrt (but it's up to you to ensure that no exceptions occur).
>
>--
> _____________
>#___/John E. Davis\_________________________________________________________
>#
># internet: da...@amy.tch.harvard.edu
># bitnet: davis@ohstpy
># office: 617-735-6746
>#
P. Jeffrey Ungar un...@Embezzle.stanford.edu
Fergus Henderson
[Example showing problems with K&R C not having prototypes]
>It has been pointed out to me by several people that this is compiler
>dependent and the a true ansi compliant answer will produce the correct
>answer. This is because instead of a declaration like:
>
> extern double pow(/* double, double */);
>
>the ANSI declaration would read:
>
> extern double pow(double, double);
>
>
>This has the effect of performing the correct typecasts before calling the
>function `pow'.
>
>But then this behavior contradicts something else the other poster said:
>
> >pow(a,i)
>
> >in your code, and "i" happens to be an integer then it can emit code to
> > - call the standard pow() function after convertin
> > i to a double
> > - call a special function the calculates doubles to
> > integer powers
> > - calculate the exponentiation using inline code.
> >Ie. it can make EXACTLY the same optimizations that Fortran compilers
> >make when they see a**i.
> >[...]
> >Any function that is part of the standard library is a "built-in"
> >function.
No, they are not contradictory.
The compiler must generate code that has the *same effect* as
simply converting to double and then calling pow(), but it is
quite free to substitute any equivalent code which may be more
efficient, for example by converting the call to a couple of inline
multiplications.
>This seems to imply that if I do:
>
>int i = 4; float y, x = 2.0; y = pow(x,i)
>
>The code for pow will recognize that 4.0 = (double) i is equivalent to the
>integer 4 and will generate code like:
>
> return(tmp = 2.0 * 2.0, tmp * tmp);
>
>as opposed something like
>
> return( exp ( 4.0 * log(2.0));
>
>Are there really any existing C compliers out there that perform such
>optimizations?
Both GNU C and Microsoft C will inline some standard library functions,
even in C (not C++) programs. This is generally used for simple functions
like strcpy, memcpy, strcmp, etc. I don't know of any compilers that
apply strength reduction optimizations to calls to pow(), but it
is certainly allowed by the standard and would not be difficult to
implement.
--
Fergus Henderson (f...@munta.cs.mu.OZ.AU) .sig truncated to avoid bugs in system
software that result in duplication of .sig apparently at random (AARRGGHHH!!!)
--
Fergus Henderson (f...@munta.cs.mu.OZ.AU) .sig truncated to avoid bugs in system
software that result in duplication of .sig apparently at random (AARRGGHHH!!!)
Marty Cohen
>Well, maybe we define modular differently, but I consider my code to be
>quite modular. My main programs consist of a rather large number of
>calls to library routines that I've written, and lots of programs use
>these library routines.
For a method of writing modular programs in Fortran 77, see: SIGPLAN
Fortran Forum 11,3, Sept 1992 (ACM Press) ppg 11-19, Data Encapsulation
Using Fortran 77 Modules, by L.L.DeLong, D.B.Thompson, and J.M.Fulford,
Hydrologists, U.S. Geological Survey, Bldg 2101, Stennis Space Center,
MS 39529.
>And if the elimination of computed GO TOs will
>help make FORTRAN more structured, then you can simply not use them.
In Fortran 77 there is no way to code a while loop without using a GOTO.
--
Marty Cohen mco...@brl.mil {uunet|rutgers}!brl!mcohen
Custom House Rm 800, Phila. PA 19106 (215)597-8377 Fax (215)597-2240
paw...@vxdesy.desy.de
> m...@hubcap.clemson.edu (M. J. Saltzman) writes:
>
>>In article <922401...@mulga.cs.mu.OZ.AU> f...@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>>m...@lyapunov.ucsd.edu (Matt Kennel) writes:
>>>
>>>>UweK...@lionbbs.bs.open.de ( Uwe Kloss) writes:
>>>>: > In addition, C has nothing equivalent to Fortrans **
>>>>: > operator nor does it have complex types.
>>>
>>>Note however that C++ does have complex types.
>> ^^^^
>>Complex types can be implemented as a class...
>
> The complex type is a standard part of C++.
> Saying that C++ does not have a complex type is like
> saying that C does not have any I/O.
> In my opinion, the fact that it can be implemented using
> the language rather than being a built-in special feature of
> the language is an ADVANTAGE.
Pardon me, but does C have any I/O? It seems to me that all it has are
functions with side-effects... Having things that 'can be implemented'
instead built-in features leads to: 1) having them implemented by various
people in incompatible ways, 2) making the programs larger, and thus harder
to read, as any program using such thing has to declare it first.
OK, don't take the above very seriously, I just wanted to show you the other
side of the coin...
Michal
.sig
#include .sig
<ESC>append FROM .sig
ADD FINALLY THIS [....] .sig!!!
OK, OK, forget it...
Jim Giles
In article <87...@amsaa-cleo.brl.mil>, mco...@amsaa-cleo.brl.mil (Marty Cohen) writes:
|> [...]
|> >And if the elimination of computed GO TOs will
|> >help make FORTRAN more structured, then you can simply not use them.
|> In Fortran 77 there is no way to code a while loop without using a GOTO.
In *NO* language is it possible to write a WHILE loop without a GOTO.
In most languages, this GOTO is *spelled* END WHILE (or in some similar
way). To be sure, this is a much better spelling*(footnote). But
semantically, a WHILE loop *IS* the following:
10 IF (cond) THEN !WHILE
... body of loop ...
GOTO 10
ENDIF !END WHILE
Proper commentary will elucidate this further, and you should never
use the label as the target of any *other* GOTO.
This whole debate about GOTOs is irrelevant to the question of whether
Fortran programs (or those in any other language) are structured or not.
*(footnote): As I have stated before, it is my opinion that syntax
is probably the *most* important aspect of a language's design. And
the lack of a WHILE loop is a very serious weakness to standard Fortran 77
(which is why most implementations - on mainframes anyway - already allow
DO WHILE --- ENDDO as an extension). In spite of this weakness, Fortran
has syntactic *advantages* over other languages for scientific/numerical
work which offset it.
--
J. Giles
Jim Giles
|> [...]
|> The compiler must generate code that has the *same effect* as
|> simply converting to double and then calling pow(), but it is
|> quite free to substitute any equivalent code which may be more
|> efficient, for example by converting the call to a couple of inline
|> multiplications.
The above is literally true only if it's the language standard `pow'
function that's being called. If a user supplied `pow' is to be used
it would probably be quite inapproptiate for the compiler to optimize
the call in the way described here. The C standard calls for some
more arcane rules involving which header files are present and how they
are defined to determine whether such optimizations are allowed.
--
J. Giles
Jim Giles
|> [...]
|> Pardon me, but does C have any I/O? It seems to me that all it has are
|> functions with side-effects... Having things that 'can be implemented'
|> instead built-in features leads to: 1) having them implemented by various
|> people in incompatible ways, 2) making the programs larger, and thus harder
|> to read, as any program using such thing has to declare it first.
C's I/O is every bit as standardized as Fortran's in that the functions
which are referred to here are defined as part of the language's required
library support. Since Fortran I/O is also *usually* supported by compiler
generated library calls, and since ANSI C allows compliant compilers
to special case standard functions anyway (by inlining them, etc. - provided
it has reliably determined that no user replacements have been made),
this makes C's I/O as built-in as Fortran's. Which is actually a better
design depends on what you're trying to do.
--
J. Giles
Michael Stemper
|>
|> Can we focus some attention on what CAN and SHOULD be taught to the
|> scientists who would prefer to write good code and are reasonably bright
|> but extremely busy. On a very practical, very pragmatic basis.
|> Suppose you can get 45 minutes of time, and hold a seminar on What every
|> scientist should know about computing but probably doesnn't... or some such.
|>
|> One shot. The room is impatient. The top people are late. (the projector
|> doesn't focus.) Now what? This is a serious question, as I'd like to do
|> precisely this, for an audience of primarily biological / chemical
|> researchers. Software Engineering 101, extremely applied, for people
|> heavily into Fortran and "getting results today."
I would stress the following points:
1. Write down your equations, formulae, algorithms, process description
on the board (or a piece of paper) first. Make sure that you under-
stand the physical reality that you are trying to model BEFORE you
ever start thinking about writing a program.
You're a scientist. You are smarter than a computer. You know lots
of math. You understand the principles of the situation. This is
why you get the big bucks. Use your talents to refine the problem
statement and simplify it if possible.
Have a firm goal in mind.
2. Before you write the code, write a program prologue or header. This
is one to five paragraphs of comments at the beginning of the module
that describes (briefly):
A. Purpose of module
B. Nature of inputs
C. Nature of outputs
D. How module goes from B to C. This can and should include references
to books, papers (even your own), etc.
E. Your name and the date
What? You don't know all of that yet? Then you're not ready to write
anything else, are you? This is the plan for your experiment or the
model of your process. If you don't know this much about it, how do
you think the computer can help you?
3. Now, start writing the module:
A. Name some variables. If you have to deal with an Oxygen flow,
call the value of that O2FLOW, not OF. But, if everything that
you are dealing with is an Oxygen flow, don't call them OFLOWA
OFLOW3, etc. Call them OFCOLD, OFHIGHP, OFXHAU, etc.
B. Write comments marking off the major parts of the module:
Get parameters
Calculate load values
Find overloads
Print results
C. Fill in the details by actually writing some code.
4. If this is truly a one-shot program written only because you left
your calculator in your car, ignore 1-3 :->
Of course, this is the same advice that I would give anybody who wanted
to write good code. The only part that I would change for a non-science-
oriented audience would be not saying "You're smarter than a computer."
--
#include <Standard_Disclaimer.h>
Michael F. Stemper
Power Systems Consultant
mste...@ems.cdc.com
Craig Burley
How does C know when compiling foo.c the difference :
cc -c foo.c
cc -o foo foo.o -lm
vs.
cc -c foo.c
cc -c pow.c
cc -o foo foo.o pow.o -lm
???
Or is this a resolved problem?
It's resolved, in essentially the same way as:
prog.f:
PRINT *,MAX(3,4)
END
max.f:
INTEGER FUNCTION MAX(I,J)
MAX = I+J
END
g77 -c prog.f
g77 -o prog prog.o ...
vs.
g77 -c prog.f
g77 -c max.f
g77 -o prog prog.o max.o ...
In Fortran, the lack of "EXTERNAL MAX" or equivalent means you've referred
to MAX the intrinsic in prog.f, independent of whether you've got an external
function named MAX. In C, the use of "#include <math.h>" means you've
referred to the "built-in" pow(), independent of whether you've got an external
function named pow(). Of course, C doesn't have to keep the built-in names
separate from the external names like Fortran, so in Fortran you can always
be sure that prog.f invokes MAX the intrinsic while other program units could
still invoke MAX your external function, while in C, you might or might not
get away with that, depending on the system you're using (i.e. it's not
portable).
Question: Do you know which real live C compilers that people can buy or
steal which do in fact perform the optimizations that we're talking about?
Well, I know GNU C has code to replace things like memcpy() with machine
code, sometimes depending on things like small amount of data being copied,
so it could use the same mechanism to handle pow() if it wanted. But I haven't
looked at this for some time. And I don't know if that code is enabled on any
machines anyway, though it might be.
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Peter S. Shenkin
>
>semantically, a WHILE loop *IS* the following:
>
> 10 IF (cond) THEN !WHILE
> ... body of loop ...
> GOTO 10
> ENDIF !END WHILE
>
>Proper commentary will elucidate this further, and you should never
>use the label as the target of any *other* GOTO.
The authors of "Numerical Recipes" observed that it is not the GOTO that
is the problem -- it is the label. When you see a GOTO, you know exactly
what is supposed to happen. But when you see a label, a branch to it could
have come from anywhere. Using GOTOs and labels as carefully as implied
by Jim's last comment is one trick to writing clean, structured Fortran.
-P.
--
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb*************************
Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027
(212)854-1418 she...@avogadro.barnard.columbia.edu she...@cunixf.BITNET
******************** The singular of "media" is "medium". ********************
Jim Giles
|> In article <922411...@mulga.cs.mu.OZ.AU>, f...@cs.mu.OZ.AU (Fergus Henderson) writes:
|> |> [...]
|> |> The compiler must generate code that has the *same effect* as
|> |> simply converting to double and then calling pow(), but it is
|> |> quite free to substitute any equivalent code which may be more
|> |> efficient, for example by converting the call to a couple of inline
|> |> multiplications.
|>
|> The above is literally true only if it's the language standard `pow'
|> function that's being called. If a user supplied `pow' is to be used
|> it would probably be quite inapproptiate for the compiler to optimize
I apologise for posting this incorrect statement. In fact, all library
function names in ANSI standard C are reserved - the user can't define
his own. So the above comment only applies to old K&R implementations
which allow the user to do so. (It's what I get for remembering an old
public review copy of the C standard better than the final version.)
This policy of C will probably come back to haunt them: suppose the next
standard wants to add new functions to the standard library? Reserving
the names will result in breaking any user codes which happen to have
functions with those new names.
--
J. Giles
M. J. Saltzman
>In article <1992Aug28....@newshost.lanl.gov> j...@cochiti.lanl.gov (Jim Giles) writes:
>>
>>semantically, a WHILE loop *IS* the following:
>>
>> 10 IF (cond) THEN !WHILE
>> ... body of loop ...
>> GOTO 10
>> ENDIF !END WHILE
>>
>>Proper commentary will elucidate this further, and you should never
>>use the label as the target of any *other* GOTO.
>
>The authors of "Numerical Recipes" observed that it is not the GOTO that
>is the problem -- it is the label. When you see a GOTO, you know exactly
>what is supposed to happen. But when you see a label, a branch to it could
>have come from anywhere. Using GOTOs and labels as carefully as implied
>by Jim's last comment is one trick to writing clean, structured Fortran.
Reminds me (though I can't place the source) of the toungue-in-cheek
proposal to add a COMEFROM statement. When it appeared in your code, you
were to assume that you arrived on a branch from a statement with the
given label. That reversed the usual problem, since you always knew
how you could get to the statement you were looking at, but you
couldn't tell what statement would follow a statement with a label.
The implications were mind-boggling!
Craig Burley
I apologise for posting this incorrect statement. In fact, all library
function names in ANSI standard C are reserved - the user can't define
his own. So the above comment only applies to old K&R implementations
which allow the user to do so. (It's what I get for remembering an old
public review copy of the C standard better than the final version.)
Hmm, I don't remember this being true. I thought pow, for example, was
a reserved word only if one #include'd <math.h>, and so on. It's hard to
be sure without trying to grok the standard right now, but the (occasionally
inaccurate) "ANSI C: A Lexical Guide" seems to suggest that pow is not a
reserved word in the way if or for is, unless #include <math.h> is present.
And, okay I pulled out the standard, and it seems to agree with this; pow
is reserved only if you #include <math.h>.
This policy of C will probably come back to haunt them: suppose the next
standard wants to add new functions to the standard library? Reserving
the names will result in breaking any user codes which happen to have
functions with those new names.
Interestingly, the standard reserves _sets_ of names for various libraries.
(See Section 14.3 of the Dec 7, 1988 draft; I doubt this has changed in the
official standard.)
So, if you #include <math.h>, not only are the existing names like pow
reserved, but so are all of them suffixed with "f" or "l" (which the lexical
guide gives incorrect examples of, IMHO, since it gives examples like "lpow",
while I think the wording means "powl").
And, if you #include <ctype.h>, not only are names like isspace reserved, but
so are all names beginning with "is" or "to" etc. (I'd give the grep patterns
of reserved names as "(is\|to)[a-z][a-zA-Z0-9_]*", but I might be getting
the first part wrong, as I don't recall the exact form of an "or" in grep.)
So, C programs _can_ avoid most problems with future versions or enhancements
of C by avoiding the larger sets of reserved names (and, fortunately, it's
quite easy to build tools that check your programs for you; actually, this
seems likely to be easy using existing UNIX tools).
However, I think Fortran programmers have it a bit easier in that they can
avoid the equivalent problem in Fortran just by saying "EXTERNAL FOO" anyplace
they want to refer to FOO as something other than an intrinsic. It's hard
to really jump up and down over either approach -- the separated "intrinsic"
reserved namespaces of ANSI C or the monolithic namespace with individual
exceptions of Fortran -- but neither of them seems fatal to small or large
applications.
Fergus James HENDERSON
>In article <1992Aug28.1...@newshost.lanl.gov> j...@cochiti.lanl.gov (Jim Giles) writes:
>
> I apologise for posting this incorrect statement. In fact, all library
> function names in ANSI standard C are reserved - the user can't define
> his own. So the above comment only applies to old K&R implementations
> which allow the user to do so. (It's what I get for remembering an old
> public review copy of the C standard better than the final version.)
>
>Hmm, I don't remember this being true. I thought pow, for example, was
>a reserved word only if one #include'd <math.h>, and so on. It's hard to
>be sure without trying to grok the standard right now, but the (occasionally
>inaccurate) "ANSI C: A Lexical Guide" seems to suggest that pow is not a
>reserved word in the way if or for is, unless #include <math.h> is present.
>And, okay I pulled out the standard, and it seems to agree with this; pow
>is reserved only if you #include <math.h>.
If you don't #include <math.h>, then "pow" is not a "reserved word";
but I think that it *is* reserved as an external identifier.
Thus something like
static double pow(double x,double y) { ... }
should be fine, but to omit the "static" as in
double pow(double x,double y) { ... }
could cause problems.
[Maybe someone with copy of the standard in front of them can confirm this.]
Note that it makes sense to prevent users from redefining standard library
functions, because doing so could have all sorts of undesireable side-effects.
For example, suppose you redefine pow as
extern double exp(double), log(double);
double pow(double x, double y) {
return exp(y * log(x));
}
So far, so good. But what if exp happened to be implemented in the
standard library as
double exp(double x) {
return pow(2.7182818284, x);
}
? Now pow() will call exp() which will call pow() which will call exp()...
Dr. Albert Hybl (UMAB-BIOPHYS)
>... Fortran 77 is out of date, everyone agrees
>with that.
Not yet. Based on usage it is still a useful programing tool.
It needs upgrades to provide better portability and enhancements
to provide modern functionality. In my opinion F90 does not do
the job.
> Fortran 90 is a modern language, ...
Perhaps fashionable, but not modern. F90 is different but not
really different, many of the old F77 warts are still present.
F90 is enhanced but not really enhanced, array indexing may be
better for (parallel machines) but F90 fails to facilitates
conforming binary data file definitions so massive data sets
can be exchanged and used interactively at and between remotely
located machines in a mixed vendor environment.
The suicide gene has not been removed: [In F77 Section 1.3.2 says
"Exclusions. This standard does not specify: ... (4) The
results when the rules of this standard fails to establish an
interpretation."] That rule effectively says vendors can add
almost any extensions to the language that they think will help
sell their machine which has contributed to the poor portability
of Fortran source code and has caused, in part, the precipitous
decline in use of Fortran among potential users.
Albert Hybl (umbc4.umbc.edu)
Bjorn Halvor Solberg
(Fergus James HENDERSON) writes:
> Any function that is part of the standard library is a "built-in"
function.
Well, I would rather say that any function that is properly prototyped is a
"built-in" function.
> Hmm... don't bet on it. Let's see:
[... program deleted ...]
> [8:52pm] /net/pacific/4/davis>cc t.c -lm
> [pacific]
> [8:52pm] /net/pacific/4/davis>./a.out
> 1.000000 = pow(2.000000, 4)
>
>
> This was compiled on a sun sparc station.
>
> Also note that all the comments and documentation in the world couldn't have
> saved this program.
The above simply proves you don't have an ANSI C compiler, or at least not ANSI
C header files. I compiled the same program on a Solbourne which is SPARC
compatible, and got this result:
16.000000 = pow(2.000000, 4)
The only thing I did was to exchange "#include <math.h>" with "double
pow(double, double);", because our header-files aren't ANSI C yet either. Need
an upgrade. :-) Conclusion: The compiler needs to know the types of the
arguments the function takes (naturally), and once it knows that it is
perfectly
able to do type conversion itself.
> _____________
> #___/John E. Davis\_________________________________________________________
> #
> # internet: da...@amy.tch.harvard.edu
> # bitnet: davis@ohstpy
> # office: 617-735-6746
> #
BJorn.
James A. Crotinger
gandalf:jac(tmp)> acc -o tc tc.c
gandalf:jac(tmp)> tc
16.000000 = pow(2.000000, 4)
It also works if you compile with a C++ compiler. However, I don't
believe either of these compilers did the optimization in question,
even after replacing 'i' with '4'. Doing 'nm' on the executable showed
various entries having to do with logs and exponentials. I don't think
these would have been there if the optimization had been done, but I'm
not certain. They also appear in a similar executable based on the
same program rewritten in Fortran.
(One interesting note is that the Fortran executable was 188K while
the C++ executable was only 32K. Fortran brings in a lot of unnecessary
garbage for such a simple program. Granted this has nothing to do with
real programs. It is just an parenthetical note 8-).)
Jim
--
-------------------------------------------------/\--------------------------
James A. Crotinger Lawrence Livermore N'Lab // \ The above views are mine
j...@moonshine.llnl.gov P.O. Box 808; L-630 \\ //---\ and are not neces-
(510) 422-0259 Livermore CA 94550 \\/Amiga\ sarily those of LLNL.
Alan Bowler
>
>I believe the real rationale for reserving these words was so that
>certain computer hardware vendors could "inline" the functions and
>boost their performance. The fact that programmers who know what
>they're doing could no longer replace pieces of the libraries for
>debugging or *performance* reasons, was apparently of no consequence.
>
>IMHO, the "safety" provided by this reservation is far outweighed by
>the crippling of standard programming practice.
>
I don't see any evidence that "programmer's who know what they are
doing" can't still do replacements for debugging an performance
reasons. If they know what they are doing, then they know how the
implementation they are working with performs, from this they can
figure out how to do the replacements. If they don't know how to do a
replacement they they clearly don't know enough to be decsribed as
"knowing what they are doing".
KMRODGERS
[much quote and reply on the neverending Fortran vs C rwar deleted]
> . . . And about 70% of the C code I had to work with was
>badly written because of:
[deleted]
>- making use of case sensitivity (i.e. symbols 'value' and 'Value' in the
> same program)
I hate contributing to this particular religious warfare (hence the changed
Subject: line), but I think that case sensitivity, WHEN PROPERLY USED, is
(IMHO) a Good Thing. The simple case cited above shows the bad features of
case sensitivity, but sometimes case is relevant to the problem domain.
Example: most of my work involves air vehicle stability and control
(Advertisement!), and I find myself constantly having to write equations of
motion routines for various analysis tools. For s&c, several quantities
known as aerodynamic stability derivatives are used. These are represented
in handwritten or typeset form as as capital "C" followed by various upper
and lowercase subscripts. The case of the subscript is important! E.g.,
cap "C" sub "L" is lift coefficient, while cap "C" sub "l" is rolling moment
coefficient -- two drastically different quantities. It is most convenient
and readable (at least to an s&c engineer, and nobody else could/would have
an interest in these particular codes) to directly translate these in my
code(s) as CL and Cl, respectively. In the absence of case sensitivity,
I must make do with CLIFT and CRM, or something similar. Sometimes, even the
case of the initial "C" is important. If I am, say, predicting lift on a
wing, it is even worse, for then I have a quantity known as section lift
coefficient, represented by (lowercase) "c" sub "l"; representing this in
non-case-sensitive systems (and, as I must often do, staying strictly F77
with 6-char variable names) would lead to something like CSECTL. For me
(and, I would venture, most other aerodynamicists and s&c engineers), writing
the three above quantities in our computer codes as CL, Cl, and cl is much more
readable (and a direct translation of the mathematical symbolism) than the
case-insensitive alternative, especially when working in the strict confines
of F77. (yes, I know that any Fortran which was case-sensitive would almost
certaintly have long variable names, but IMHO it's still more readable mixed
case.)
If one of the goals of a computer language, especially one for scientific
and engineering computation, is to try to preserve as much as possible
and reasonable the natural notations of these fields (a claim that I have
heard Jim Giles make before, and one with which I agree), then I think that
case sensitivity is important, and this is _one_ area where C is superior to
Fortran. (Note the emphasis; I make no other claims in this rwar.)
------------------------------------------------------------------------------
Kevin Rodgers Loral Vought System Co. rodgers%eng...@uunet.uu.net
Since LTV no longer has Ling, Temco, or Vought, I suggest they change
their name to MBSC (Mostly Bankrupt Steel Company).
------------------------------------------------------------------------------
Jim Giles
|> [...]
|> I hate contributing to this particular religious warfare (hence the changed
|> Subject: line), but I think that case sensitivity, WHEN PROPERLY USED, is
|> in handwritten or typeset form as as capital "C" followed by various upper
|> and lowercase subscripts. The case of the subscript is important! E.g.,
|> cap "C" sub "L" is lift coefficient, while cap "C" sub "l" is rolling moment
I, reluctantly, disagree with this. This is using case significance as
a form of `Hungarian notation' where case has an independent semantic
meaning. If you are arguing that the language should *enforce* such a
convention, then maybe I would agree with you (I'd have to see the whole
proposed use of case). As it is, case has no enforced semantic meaning
and differing conventions (as well as intentional and accidental violations
of such conventions) lead to more confusion among colleagues than the
added `convenience' is worth.
In the meantime, case *INsensitivity* allows the use of case for
emphasis and for documentation. This is also a minor convenience.
Which dominates and in what contexts is a subject for research.
But, I feel that case sensitivity is best when it has specific
meaning to the language (like: all identifiers which begin with
uppercase are function or constructor names - and the compiler
enforces that).
|> [...]
|> If one of the goals of a computer language, especially one for scientific
|> and engineering computation, is to try to preserve as much as possible
|> and reasonable the natural notations of these fields (a claim that I have
|> heard Jim Giles make before, and one with which I agree), then I think that
|> case sensitivity is important, and this is _one_ area where C is superior to
|> Fortran. (Note the emphasis; I make no other claims in this rwar.)
Yes, and conventional mathematical and scientific notation also make use of
bold vs. normal, Roman vs. Greek, fraktur vs. times-roman (font as opposed
to alphabet), etc.. Some notations even use the front half of the alphabet
for one thing and the back half for something else (and the middle `half'
for still other uses). Unless you can provide *all* of these, the programmer
must spell out most such distinctions explicitly anyway. I think that in
most programming contexts, case sensitivity is undesirable. In a symbolic
package like Macsyma or Mathematica, such notations should be supported
(including the fonts, alphabets, intensity, etc.).
In any case (alright - I noticed the pun), I think there should be some
human factors tests before anyone starts a war on the issue of case
sensitivity. Case sensitivity should be tested, and in a variety of
programming languages and contexts - and should only be adopted in contexts
where it shows a *real* advantage. I suspect it will usually be better
when the compiler enforces meaning on case sensitivity.
--
J. Giles
Steve Hobbs
>In the meantime, case *INsensitivity* allows the use of case for
>emphasis and for documentation. This is also a minor convenience.
>Which dominates and in what contexts is a subject for research.
>But, I feel that case sensitivity is best when it has specific
>meaning to the language (like: all identifiers which begin with
>uppercase are function or constructor names - and the compiler
>enforces that).
Reminds me of the original FORTRAN I definition where only variables
beginning for I,J,K,L,M,N were "fixed point" while all others had to
be "floating point" with no exceptions. Later, in FORTRAN II they added
functions. Arithmetic statement functions, the "closed" (library intrinsic),
and the "open" (built-in intrinsic) functions had to end with the letter "F"
and were fixed-point only if they began with the letter "X". (What
consistency, MOD was an integer variable while MODF was a floating function).
In FORTRAN IV they allowed the programmer more freedom with choosing his
identifier names.
David Mathog
>I hate contributing to this particular religious warfare (hence the changed
>Subject: line), but I think that case sensitivity, WHEN PROPERLY USED, is
>(IMHO) a Good Thing. The simple case cited above shows the bad features of
>case sensitivity, but sometimes case is relevant to the problem domain.
>Example: most of my work involves air vehicle stability and control
>(Advertisement!), and I find myself constantly having to write equations of
>motion routines for various analysis tools. For s&c, several quantities
>known as aerodynamic stability derivatives are used. These are represented
>in handwritten or typeset form as as capital "C" followed by various upper
>and lowercase subscripts. The case of the subscript is important! E.g.,
>cap "C" sub "L" is lift coefficient, while cap "C" sub "l" is rolling moment
>coefficient -- two drastically different quantities. It is most convenient
>and readable (at least to an s&c engineer, and nobody else could/would have
>an interest in these particular codes) to directly translate these in my
>code(s) as CL and Cl, respectively.
Sure, but it's a recipe for maintenance problems should one of the 99.999%
of C programmers who aren't s&c engineers ever be called upon to modify the
code. That said, Fortran code with variables named I12, I21, I13, I31 (and
so forth) is just about as difficult to maintain.
There must be some studies on the rate at which programmers misread code as
a function of variable length and format - anybody out there know the
results?
David Mathog
mat...@seqvax.caltech.edu
Jim Giles
|> [...]
|> Sure, but it's a recipe for maintenance problems should one of the 99.999%
|> of C programmers who aren't s&c engineers ever be called upon to modify the
|> code. That said, Fortran code with variables named I12, I21, I13, I31 (and
|> so forth) is just about as difficult to maintain.
|>
|> There must be some studies on the rate at which programmers misread code as
|> a function of variable length and format - anybody out there know the
|> results?
I have a Pascal book (at home, or I would quote it directly) which
elegantly makes the case *against* long identifiers by arguing *for*
them. They compare Fortran-like identifiers (say GRDSIZ and BOXSIZ)
to Pascal identifiers (like Size_of_Grid and Size_of_Box) and conclude
that the latter are best. Well, I disagreed (and their examples made
the point better than mine). If two identifiers specify different
things, their *differences* should be the emphasis of the names - not
their similarities. Reading lots of *long* identifiers is just as
prone to error and misunderstanding as having inadequately short ones.
I think there's no doubt that restricting identifier lengths arbitrarily
in the language design (to anything shorter than 16 or 20 anyway) is not
conducive to well written code. But, arbitrary use of extremely long
identifiers, just to use up the space, should not be the result. In the
above examples, GRID_SZ and BOX_SZ are admirable - yet are not long.
Extremely long identifiers (more than 10-16 characters, say) should
only be necessary when you're trying to emphasize something very
unusual or when you have very subtle distinctions between what two
(or more) variables do.
--
J. Giles
Alasdair Grant
>language with hundreds (like PL/I? :-)
PL/I has no reserved words. And it solves this particular problem with
a 'builtin' word, i.e.
pow: procedure (x, y) returns(float(53));
dcl (x, y) float(53), (exp, log) builtin;
return (exp(y * log(x)));
end pow;
This is like modules, except that there are only two. But C has only one.