NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/edu/1408

Internet Message Format | 1992-08-30 | 8.9 KB

Xref: sparky comp.edu:1408 comp.lang.fortran:3281 comp.lang.misc:2804 sci.math:10695
Path: sparky!uunet!charon.amdahl.com!pacbell.com!att!linac!uwm.edu!rpi!gatech!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Date: 30 Aug 92 19:53:59 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
Lines: 157

In article <[e-mail]> [e-mail] (Matt Kennel) writes:
>[e-mail] (Herman Rubin) writes:
>: The problem is that the CS people are, in this sense, like the purissima
>: mathematicians (if it can be applied, it is time to work on something else.)
>: They concentrate on what no scientist is particularly worried about, like
>: making the printed output look neat, or even making life easy for the
>: compiler.


>: Most good scientists can think of their problem, and how reasonable operations
>: can attack it.  But the languages do not facilitate this, and often even if
>: the features are present, they are in some obfuscated syntax.

>I agree.  I believe the CS vs. Science programming divide is cultural, but
>I'm going be somewhat partisan and blame the programming authorities a bit more
>than the scientists.

>My view of things:

>1) There are scientists who don't know the value of organized software
>    engineering.  I mean basic things like type-checking subroutine
>    arguments, modularization, modern data types, and other things like
>    that.  They write the infamous spaghetti Fortran.

This statement is too broad.  Modularization is not a problem for the
scientist, but it can be a major time-waster if the current software is
used.  Subroutine calls are, at this time, and for the foreseeable future,
quite expensive.  This was not the case when Fortran and Algol were first
produced; there were few registers then, transfer was the fastest instruction,
and context switching cost less than one multiplication.

I have deliberately violated types to get the job done.  In fact, I see no
good way out of it.  Now there might be some point to informing the programmer
that types are violated, but very definitely not to insist on it, or to force

Also, mathematicians especially use lots of operators.  Despite what the CS
gurus say, allowing the introduction of additional functions is not the
same thing.  Also, mathematicians and scientists are accustomed to using
whatever syntax they like, as long as it does not lead to confusion.  But
the CS people insist that only the standard operators are to be allowed to
use infix notation, and all others must be prefix, except in reverse Polish
systems, in which all must be postfix.

>2)  There are computer scientists who don't understand the demands of
>    scientific computing, which is understandable, because they never
>    write scientific programs.
>
>The problem is this:
>
>There are scientists who *have* learned the value of good software
>engineering and believe what the comptuer scientists have said for years, and

>
>Too many CSoids however dismiss the concerns of scientists as being
>narrow and "uninformed", assuming that they're all like the nerds in
>#1 above.  Or they claim that language X does what scientists need
>(or "no we don't need to bother because it's possible to implement that
>in a library" or "a quality of implementation issue" (a euphemism for

Scientists generally come up with types in a logical manner which are not
included in the list presented by the language.  Some languages have allowed
the introduction of additional types.  But C is a bad example here; typedef
was usurped for something of little use anyhow, and should have been called
typealias, reserving typedef for a special case of struct, or class in C++.

Also, mathematicians especially use lots of operators.  Despite what the CS
gurus say, allowing the introduction of additional functions is not the
same thing.  Also, mathematicians and scientists are accustomed to using
whatever syntax they like, as long as it does not lead to confusion.  But
the CS people insist that only the standard operators are to be allowed to
use infix notation, and all others must be prefix, except in reverse Polish
systems, in which all must be postfix.

>Software technology and practice for addressing the particular concerns of
>computer scientists has advanced tremendously since the early days, but the
>model of scientific computation hasn't changed much since early Fortran
>except vicariously through the progress in "regular" computer science.

>I personally would love a "Numerical Eiffel" type of language, but I bet the
>Eiffel gurus would say "eeuy yuck, you're polluting our pristine creation
>with needless cruft".  One of the Modula-3 people has said that one of
>their design goals was to make it good for numerical computation (a
>refreshing attitude).  One of the examples was "easy access to the IEEE
>rounding modes" (what the f*???) as standard in the library, but admitted that
>complex numbers weren't, much less array operations.

>I don't want "good for numerical computation" to mean "not all that much
>worse than Fortran 77"!

>I believe Herman Rubin and other mathemeticians when they say that they want
>good performance and easy use of multiprecision integers and fixed point
>numbers, even though I and most physicists, would never have a use for
>them.  So can the computer scientists accept our needs as well?  Remember,
>it's the scientific programmers who *DO* want change who are doing all the
>complaining--the "old farts" just keep on banging out Fortran and mind their
>own business.

>Scientists don't want to needlessly accept *regress* in concrete areas in
>order to make supposed "progress" in areas they haven't been convinced they
>want.  The progress has to be good enough to convince departmental computer
>comittees to buy a new $2000 compiler.  Notice that scientists aren't
>all that hidebound by tradition---they enthusiastically take up Maple
>and Mathematica---because they can immediately recognize progress, and
>even despite their lack of "goto". :-)

>And finally the old standby "why speed is in fact, important".  Why does
>factor of 2 matter?  It's the old "the program is everything" view.  Running
>any particular one program faster is not, in fact, what matters.  What does
>matter, is that with a faster machine and a faster language I can do *more*
>and *better* science.  (I could easily use up a 10 teraflop machine next
>month.) Many times we're running things on hardware far too underpowered to
>"do the job right" in any case, but science accepts approximate solutions.

The previous reference to such things as Mathematica is an example of the
need for speed.  One of my colleagues set something up on Mathematica, and
for checking a single case, that was fine.  But for the production run, the
speedup of over 100 garnered by converting from Mathematica to C was needed
to get the job done.

>Take the statement, "Scientific progress is proportional to the logarithm of
>computer power."

>The computer scientist hears this and says "You silly fools, if you
>saw the big picture you'd realize that the constant factor doesn't matter
>one bit so quit complaining."

>The scientist hears this and says "Well that's why we need to get
>all we can get, and then some, in order to make progress."

Even more, how much speedup do you think we will get in the future?  Our
current switching time is about 10^-10 second, maybe 10^-11.  Probably
10^-15 will be obtained, but 10^-18 is the length of time for light to
cross a small molecule.  Wave lengths of X-rays are comparable to the
interatomic distances.
>
>I think there is in fact some hope.

>Specifically, the parallel- and super- computer research community.
>In it, there are people who truly understand both the computer scientists
>and the scientific users and are committed to progress rather than
>defining away the problem as uninteresting or trivial.

But these have their problems as well.  Vector computers which can only
handle "rigid" vectors (the spacing between elements cannot change) run
into problems, and parallel processors even more so.  To give a simple
example ot such a problem, consider the problem of computing a function
for which there are several different parts of the domain, each calling
for a different algorithm.  Parallelism is almost a curse here.  Or a
simulation in which about 0.01% of the cases take 1,000 times as long?
A parallel processor with 2^14 or more processors is going to be doing
one of those most of the time.  Now this problem is partly hardware and
partly software, and I can handle some of them myself.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!pop.stat!hrubin(UUCP)