Scientists as Programmers (was Re: Small Language Wanted) 
Author Message
 Scientists as Programmers (was Re: Small Language Wanted)


Quote:

>(Doctor fortran) writes:

>>(Edward J. Hartnett) writes:
>>> [. . . . ] 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.
>>But I must disagree when you characterize
>>scientists as bad programmers. That's bigotry, and a stereotype to which I
>>must strenuously object.
>     It's not bigotry, it's a sociological generalization applicable to
>the vast majority of scientists who write computer programs.  You should
>see the things I've seen...
>     Edward wasn't trying to insult anyone.  He correctly identified the
>source of the problem:  Scientists think that any code that executes
>correctly and quickly is OK.  What it looks like and whether it would
>meet with the approval of CS weanies is completely irrelevant
>to us.  Of course, that also means that our "one-shot" code had better
>never need to be tweaked.

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.  They talk about optimizing compilers, but when someone brings
up something which the current styles of optimization do not handle, they
still say that the programmer must not be allowed to intervene with the
product of the compiler, and things must be left to the compiler.

If we want to do good programming for scientists, both the hardware and
the software have to take into account what the scientists with imagination
can think of, not what those doing routine can envision.  The ideas of those
who make extensive use of the computer for number theory, for example, are
entirely ignored by both the hardware people and the language people.  And
it is almost official policy to make the use of machine language other than
through the inadequate high level languages at least very difficult.

Fortran is inadequate, Algol is inadequate, C, and even C++, is inadequate.
Even if a programmer can find a good way of mixing them, there is no
possibility of having one line in Fortran and the next in C.

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.  Handling the
syntax problem alone would make for great improvement, but I see nothing in
this direction, and have asked for software to do this single job.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054

{purdue,pur-ee}!pop.stat!hrubin(UUCP)



Tue, 14 Feb 1995 23:47:10 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)
|> 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.  They talk about optimizing compilers, but when someone brings
|> up something which the current styles of optimization do not handle, they
|> still say that the programmer must not be allowed to intervene with the
|> product of the compiler, and things must be left to the compiler.

I think we, like just about everybody, are confusing computer scientist with
software engineers.  Computer scientist examine optimization techniques.
Software engineers rely upon optimizers.  We need both software engineers and
computer scientist, but they are not the same.

|> If we want to do good programming for scientists, both the hardware and
|> the software have to take into account what the scientists with imagination
|> can think of, not what those doing routine can envision.  The ideas of those
|> who make extensive use of the computer for number theory, for example, are
|> entirely ignored by both the hardware people and the language people.  And
|> it is almost official policy to make the use of machine language other than
|> through the inadequate high level languages at least very difficult.
|>
|> Fortran is inadequate, Algol is inadequate, C, and even C++, is inadequate.
|> Even if a programmer can find a good way of mixing them, there is no
|> possibility of having one line in Fortran and the next in C.

There is hope!  Anyone familiar with SGI's Explorer package?  Push button
programming.

-------------------------------------------------
Brad Wallet                 Mathematician

(703)663-4950               (AVN)249-4950
DSMAC - "Tomahawk's Eyes"
"I can neither confirm nor deny that these opinions
are entirely my own and may or may not reflect those
of the US Navy."



Wed, 15 Feb 1995 01:01:49 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)
I couldn't find previous articles in this thread, so pardon me if I'm repeating
this:  I once found the following amusing quote by Bill Gosper in an issue of
Science (vol 255, page 1150):

    ``An exciting thing was happening at Livermore.  They were building a
    supercomputer, and I will certainly confess to being a cycle junkie.
    Computers are never big enough or fast enough.  I have no patience at
    all with these damned PC's.  What I didn't realize when I went over to
    Livermore was that as long as physicists are running the show you're
    never going to get any software.  And if you don't get any software,
    you're never going to get anywhere.  Physicists have the most abysmal
    taste in programming environments.  It's the software equivalent of a
    junk-strewn lab with plug boards, bare wires and alligator clips.
    They also seem to think that computers (and programmers for that
    matter) are the sorts of things to which you submit punched card decks
    like you did in the mid-sixties.''

    --- Bill Gosper, in ``More Mathematical People: Contemporary Conversations''
                    (Donald J. Albers et. al., Eds.; Harcourt Brace Jovanovich)




Wed, 15 Feb 1995 04:39:12 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)
: 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.

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
honestly try to stay up to date.

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
"we don't really give a shit") ) and say that we're silly when we disagree.

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.

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."

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.

: --
: Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
: Phone: (317)494-6054

: {purdue,pur-ee}!pop.stat!hrubin(UUCP)

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Wed, 15 Feb 1995 07:28:36 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)

   Handling the syntax problem alone would make for great improvement,
   but I see nothing in this direction, and have asked for software to do
   this single job.

And many have asked you for a decent specification of what you want.
If you can't tell us what you want, there is not much chance of us
coding it is there?  So come on Herman, play the game, tell us
what you want so we can finally be rid of this old chestnut.

bevan

PS did you look at any of the languages I suggested the last time you
   brought this up?



Wed, 15 Feb 1995 02:54:47 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)


:
:    Handling the syntax problem alone would make for great improvement,
:    but I see nothing in this direction, and have asked for software to do
:    this single job.
:
: And many have asked you for a decent specification of what you want.
: If you can't tell us what you want, there is not much chance of us
: coding it is there?  So come on Herman, play the game, tell us
: what you want so we can finally be rid of this old chestnut.

I have no idea what Mr Rubin really wants but here are a couple of
easy ones of the top of my head:

result1, result2 <-  function_that_returns_two_values (NOT a structured type);
E.g:

 P, D, Q <- singular_value_decomposition(A);

Array index notation:

for all i <= j: a(i,j) <- sum over (k) ( b(i,k)*c(j,N,k) )

(Thank god for Connection Machines)

I won't bore you with the obvious complex numbers, exponentiation, etc.

: bevan

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Wed, 15 Feb 1995 14:46:11 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)

Quote:

>I personally would love a "Numerical Eiffel" type of language ...

Try "Sather".  It is an object-oriented programming language that is
competitive with Fortran in speed for complex problems.  Of course,
the object oriented dispatch makes it slightly slower for some types
of problems, but the designers have gone to great lengths to make it
fast.  The principle designer, Steven Omohundro, is a physics PhD
turned computer scientist, so that may explain why he is interested in
bridging the gap, as it were.

Sather is available from Berkeley via anonymous ftp.  However, I can't
seem to find the ftp site at the moment.  The author's email address

Darrell



Thu, 16 Feb 1995 05:19:32 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)

Quote:


>: 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.  

Quote:
>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.  

- Show quoted text -

Quote:
>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.

Quote:
>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.

Quote:

>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: (317)494-6054

{purdue,pur-ee}!pop.stat!hrubin(UUCP)


Fri, 17 Feb 1995 03:53:59 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)


:
: >I personally would love a "Numerical Eiffel" type of language ...
:
: Try "Sather".  It is an object-oriented programming language that is
: competitive with Fortran in speed for complex problems.  Of course,
: the object oriented dispatch makes it slightly slower for some types
: of problems, but the designers have gone to great lengths to make it
: fast.  The principle designer, Steven Omohundro, is a physics PhD
: turned computer scientist, so that may explain why he is interested in
: bridging the gap, as it were.

I've downloaded and compiled Sather already, and I really like what I've
seen so far.  After seeing Sather, I can't understand how C++ could be so
needlessly complicated.  I'm just about ready to switch, but I worry about
not having my code usable by anybody else.

What I like:

1)  Simple class structure and rules (though I think the CS gurus have some
    problems which I don't completely understand).

2)  Garbage collection.

A couple of things tho:

1)  There is only one basic "loop" construct, which means that you have to
    write i:=i+1  all the time just do do the most basic things.  Of course
    it's only "surface syntax", but these things make a real difference
    in real life.  In the jihad for simplicity, Oberon discarded the
    FOR i:=1 TO N DO loop, but it was put back into Oberon-2 and I think
    Sather's designers should do the same.

2) Along the same lines what I really meant by "Numerical Eiffel" was array
   index notation as I've described before, or something to get rid of all
   those silly loops.  Perhaps this is taken care of as their parallel
   extension?

3) The library right now is too bare to be completely useful yet, even though
   the README spells out great plans (better for my purposes than ANYTHING
   I've ever seen.  K-D trees!).  No complex numbers yet.  Can't read binary
   (big blocks of FP numbers) yet.

Implementation issues:

1)  It compiles into "C", and the 2-d arrays are implemented in
    Numerical Recipes style (pointers to arrays of pointers). It's not clear
    this is best for speed, especially with newer compilers I guess.
    Depends on the relative cost of reading memory vs computation.

2)  It doesn't yet output code in such a way that little methods can
    be inlined, say by compiling with GNU CC.  If this were to happen, I'd
    think that Sather programs could be quite a bit *faster* than C++, as it
    generates new, specialized, code for classes with type parameters.
    (I.e LIST{INT} gets special treatment vs. LIST{FOOBAR})

: Sather is available from Berkeley via anonymous ftp.  However, I can't
: seem to find the ftp site at the moment.  The author's email address

:
: Darrell

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Thu, 16 Feb 1995 06:55:05 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)

Quote:

>>>>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.
>>     Edward wasn't trying to insult anyone.  He correctly identified the
>>source of the problem:  Scientists think that any code that executes
>>correctly and quickly is OK.  What it looks like and whether it would
>>meet with the approval of CS weanies is completely irrelevant
>>to us.  Of course, that also means that our "one-shot" code had better
>>never need to be tweaked.

        I think whoever wrote that last paragraph is quite correct.  One
should also remember that scientists are programmers of necessity: they
program because they have to, not because they're good at it or (generally)
like to do it.  This certainly doesn't improve the quality of the code,
let alone the maintainability...

Quote:
>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.

        So?  That's a lot of why they exist.  They weren't created solely to
make life easier for physicists.  (Not that that's an invalid thing to do -
but your statement implies that all else is unimportant.)

Quote:
>  They talk about optimizing compilers, but when someone brings
>up something which the current styles of optimization do not handle, they
>still say that the programmer must not be allowed to intervene with the
>product of the compiler, and things must be left to the compiler.

        Intervening in compiler output (as you call it) is at best dangerous,
doubly so for someone whose training isn't in software.  With highly optimising
compilers, when wading through compiler output I'll often say "that move is
useless", and then find out 50 instructions later it was highly useful.  With
heavily pipelined processors it's easy to produce subtle bugs, since things
don't always happen in the order they appear to from the list of instructions.
Etc.  If you need to write in assembler, do so, don't try to sneak behind
the back of other tools - you'll save yourself a lot of grief.

Quote:
>The ideas of those
>who make extensive use of the computer for number theory, for example, are
>entirely ignored by both the hardware people and the language people.

        And what are these?  I've never heard a suggestion from these people
(I think); give examples (and make them apply to more than just number-
theory research).

Quote:
> And
>it is almost official policy to make the use of machine language other than
>through the inadequate high level languages at least very difficult.

        It's mainly difficult because programming in assembler is fundamentally
more difficult - that's why we invented higher-level languages.  It's also
more difficult on most architectures because few people do it, therefore few
people bother to write better tools.  Processors that are primarily programmed
in ASM, such as the AT&T DSP3210, have very readable assembler syntax (for
an assembler) - it almost reads like C.

Quote:
>Fortran is inadequate, Algol is inadequate, C, and even C++, is inadequate.
>Even if a programmer can find a good way of mixing them, there is no
>possibility of having one line in Fortran and the next in C.

        I don't even want to _think_ about how hard that would be to deal
with...  There is a lesser alternative: link functions from different
languages together.  If you want to be really sick, make each line a "function"
and use some sort of preprocessor to build it by compiling each separately.
I don't think you'd be pleased with the results, though.

Quote:
>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.  Handling the
>syntax problem alone would make for great improvement, but I see nothing in
>this direction, and have asked for software to do this single job.

        Not every language is appropriate for every job, which is what I
think people told you last time this came up.  If there are specific problems,
give examples.  Also, I suspect that a large part of it is that (not
suprisingly) scientists don't want to learn N languages, they want a kitchen-
sink that does it all, AND they want it to be simple, AND they want it to
generate the tightest code theoretically possible.  This is like the old
cliche: fast, small, soon, pick any 2.  Those requirements are pretty close
to contradictory (certainly wanting all of them will greatly increase to
cost to produce any such compiler, if it can be done at all).

--
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.

Disclaimer: Nothing I say is anything other than my personal opinion.



Thu, 16 Feb 1995 08:18:29 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)
   I have no idea what Mr Rubin really wants but here are a couple of
   easy ones of the top of my head:

    P, D, Q <- singular_value_decomposition(A);

How about :-

(p,d,q) = singular_value_decomposition A

   Array index notation:

   for all i <= j: a(i,j) <- sum over (k) ( b(i,k)*c(j,N,k) )

I'm not _exactly_ sure what the above does (e.g. is N constant?), so
the following may be wrong (but it is better than my previous attempt
which I hopefully cancelled correctly :-)

foo b c = array bds vs
  where
    vs = [ (i,j) := f i j | (i,j) <- range bds, i <= j ]
    f i j = sum [ b!(i,k)*c!(j,n,k) | k <- range (klb,kub) ]
    bds = ((ilb,jlb),(iub,jub))
    ((ilb,klb),(iub,kub)) = bounds b
    ((jlb,_,_),(jub,n,_)) = bounds c

An alternative (and possibly more efficient) version of _vs_ is :-

  vs = [ (i,j) := f i j | i <- range (ilb,iub), j <- range (i,jub) ]

Note this is untested as I currently don't have a compiler installed.
As to the notation, I'll do you a deal: you explain the one you're
using and I'll explain the one I'm using :-)

   I won't bore you with the obvious complex numbers, exponentiation, etc.

Why not, you may be pleasantly suprised.

bevan



Thu, 16 Feb 1995 02:15:07 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)


:    I have no idea what Mr Rubin really wants but here are a couple of
:    easy ones of the top of my head:
:
:     P, D, Q <- singular_value_decomposition(A);
:
: How about :-
:
: (p,d,q) = singular_value_decomposition A

This is perfectly sensible.

:    Array index notation:
:
:    for all i <= j: a(i,j) <- sum over (k) ( b(i,k)*c(j,N,k) )
:
: I'm not _exactly_ sure what the above does (e.g. is N constant?), so
: the following may be wrong (but it is better than my previous attempt
: which I hopefully cancelled correctly :-)

What I mean is that the upper triangular part of "a" is equal to B *
transpose("C"), but where the matrix "C" is "spread" out through different
parts of a 3tensor arrays.

:
: foo b c = array bds vs
:   where
:     vs = [ (i,j) := f i j | (i,j) <- range bds, i <= j ]
:     f i j = sum [ b!(i,k)*c!(j,n,k) | k <- range (klb,kub) ]
:     bds = ((ilb,jlb),(iub,jub))
:     ((ilb,klb),(iub,kub)) = bounds b
:     ((jlb,_,_),(jub,n,_)) = bounds c

This is perfectly ridiculous!  I have no clue what that means.
I don't think one should have to write a subroutine to implement each simple
array statement.

: An alternative (and possibly more efficient) version of _vs_ is :-
:
:   vs = [ (i,j) := f i j | i <- range (ilb,iub), j <- range (i,jub) ]
:
: Note this is untested as I currently don't have a compiler installed.
: As to the notation, I'll do you a deal: you explain the one you're
: using and I'll explain the one I'm using :-)

What's called "implied summation convention" means "sum over repeated
indices"on the right hand side of the assignment
and iterate over covarying indices on both sides.  (No I didn't invent
this...heard it's also called "Einstein summation convention" as it's
very useful in relativity calculations).

So if C(i,j,k) is a 3-tensor, then

T(i) = C(i,j,j)

means for each matrix C(i,*,*) compute its trace and assign to T(i).
(Yes the indices should automatically figure out their bounds).

I think it wouldn't be so bad to allow you to explicitly say these things:

for all i T(i) = sum_over(j) C(i,j,j)

sum_over or sum or whatever is the of course just the traditional capital
sigma symbol used in math, and of course all it means is add everything
up.

:    I won't bore you with the obvious complex numbers, exponentiation, etc.
:
: Why not, you may be pleasantly suprised.
:
: bevan

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Thu, 16 Feb 1995 11:14:34 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)

! I've downloaded and compiled Sather already, and I really like what I've
! seen so far.  After seeing Sather, I can't understand how C++ could be so
! needlessly complicated.  I'm just about ready to switch, but I worry about
! not having my code usable by anybody else.

It's easy to see why C++ is so complicated (I am not saying that it is
not usable) and Sather is not. C++ has evolved for quite some time and
in short intervals someone has come up with a 'neat idea' of what he/she
would want to see in the language. That 'neat idea' is incorporated in the
language and it becomes just a tiny little bit more complicated. Sather has
not been around long enough for this to happen. But it will happen eventually,
I suppose.

Please note very carefully that your (or mine) 'neat ideas' are no different.
They may be _very_ useful and we want them _very_ much, but they no less
clutter up the language. Here comes the job of the language designer. He/She
must decide if that 'neat idea' is generally useful and fits into the language.
As a result it is incorporated in the language or left out. The more that
are left out, the less complex the language will be. The result may be
a language that you (or I) don't want to use. But don't worry. There are
many languages, and no single language will be 'best' for all applications
or all users.

! 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
! honestly try to stay up to date.

! 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.

I think you are being unfair. There are CS-people who apreciate the computing
needs of scientists. I would claim that most do. The problem really seems to
be that we don't understand each other properly. For a good example, see below.

! 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
! "we don't really give a shit") ) and say that we're silly when we disagree.

It sometimes is the case that a language feature is best implemented in
a library. (Really!) This need not necessarily be any slower than implementing
it in the core-language itself (depending on the language.) It also has the
advantage that the core-language is less complex. You yourself have indicated
that you like a less complex language. Right? And as I see it, one of the
most important reasons why FORTRAN is so popular is "a quality of implementation
issue". FORTRAN compilers are very good at what they do, or so I'm told.

! 1)  There is only one basic "loop" construct, which means that you have to
!     write i:=i+1  all the time just do do the most basic things.  Of course
!     it's only "surface syntax", but these things make a real difference
!     in real life.  In the jihad for simplicity, Oberon discarded the
!     FOR i:=1 TO N DO loop, but it was put back into Oberon-2 and I think
!     Sather's designers should do the same.

Yes, I would myself like to see these loop-constructs in Sather:

loop       until <xxxx> loop   while <xxxx> loop  for <xxxx> to <yyyy> loop
  <xxxx>     <yyyy>              <yyyy>             <zzzz>
end        end                 end                end

The first two are the standard loop-constructs already in Sather. The
alternative form of the last loop would be 'for .. downto .. loop .. end',
decrementing the counter by one instead of incrementing it.

! : Sather is available from Berkeley via anonymous ftp.  However, I can't
! : seem to find the ftp site at the moment.  The author's email address

! :
! : Darrell

WHERE    HOSTNAME               ANON FTP DIR     CURRENT HOST ADDRESS

USA:     ftp.icsi.berkeley.edu  /pub/sather      128.32.201.55
EUROPE:  ftp.gmd.de             /pub/Sather      129.26.8.90
AUS:     lynx.csis.dit.csiro.au /world/sather    192.41.146.1
JAPAN:   sra.co.jp              /pub/lang/sather 133.137.4.3

-rw-rw-r--  1 hws      sather    4355259 Mar 30 01:53 sa-0.2g.tar.Z

! : How about :-
! :
! : (p,d,q) = singular_value_decomposition A

! This is perfectly sensible.

There was discussion of implementing a very similar construct in Sather.
I don't know what the current status of that is.

! I think it wouldn't be so bad to allow you to explicitly say these things:

! for all i T(i) = sum_over(j) C(i,j,j)

That is perfectly reasonable, but only in a language that was designed
for that. It is not at all wise to put it into Sather (or C++ or Simula
for that matter) afterwards. There is also the technical matter that
such a construct might be difficult to describe with a context free grammar.

Also, I would like to see a newsgroup called comp.lang.sather. Sather
related discussion is now spread over many different newsgroups. The email-
list that exists does not work. It's almost dead.
--
...............................................................................
Ari Huttunen
...............................................................................



Fri, 17 Feb 1995 00:21:30 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)
   [ Matt accepts the multiple value return syntax ]

   : foo b c = array bds vs
   :   where
   :     vs = [ (i,j) := f i j | (i,j) <- range bds, i <= j ]
   :     f i j = sum [ b!(i,k)*c!(j,n,k) | k <- range (klb,kub) ]
   :     bds = ((ilb,jlb),(iub,jub))
   :     ((ilb,klb),(iub,kub)) = bounds b
   :     ((jlb,_,_),(jub,n,_)) = bounds c

   This is perfectly ridiculous!  I have no clue what that means.

array <bounds> <elements>  - create an array with the given _bounds_
                             (as a tuple of lower and upper bounds)
                             and _elements_ (a list of the elements)
b!(i,k) - same as b(i,k) in your notation
sum <list> - sum over all elements in the list
[ <expr> | <control> ] - create a list of exprs, one for each value
                         defined by _control_
<index> <- range <bounds> - assign _index_ each value in the range of
                            the _bounds_
bounds <array> - return the bounds of the array as a tuple.
<index> := <value> - assign _value_ to the given position in the array

For a more detailed definition find a Haskell manual, the easiest
place for most people would probably be in either the April or May
edition (I can't remember) of SIGPLAN Notices.

   I don't think one should have to write a subroutine to implement each simple
   array statement.

You don't _have_ to, I chose to do it that way.  If you want it as an
expression, then you can have it as an expression, but it doesn't
become much shorter :-

  a = array bds [ (i,j) := f i j | (i,j) <- range bds, i <= j ]
    where
      f i j = sum [ b!(i,k)*c!(j,n,k) | k <- range (klb,kub) ]
      bds = ((ilb,jlb),(iub,jub))
      ((ilb,klb),(iub,kub)) = bounds b
      ((jlb,_,_),(jub,n,_)) = bounds c

You can even stuff the function _f_ inline if you want, but IMHO it
gets pretty unreadable if you do.  The part that takes the most space
is the last three lines which determine the bounds for the arrays.
However as you note, you want this done automatically for you so you
probably consider it as unnecessary detail.  I can't help on that, but
then where do you put the bounds information in your notation if you
don't want to iterate over the whole matrix.  For example in Choleski
factorization, Hermite Interpolation or Cubic Spline interpolation
(guess what I wrote recently :-)

   What's called "implied summation convention" means "sum over repeated
   indices"on the right hand side of the assignment
   and iterate over covarying indices on both sides.  (No I didn't invent
   this...heard it's also called "Einstein summation convention" as it's
   very useful in relativity calculations).

It certainly is a concise notation, but isn't it a {*filter*} to spot
errors when using this notation?  For example, I once spent 2 hours
trying to find a bug in a program which was due to having a variable
called _a'_ when it should have been _a''_.  The prime convention
works fine in small formulae on paper, but I don't think it translates
well to programs, so now I avoid it even if the language allows me to
do it.  Note this should not be construed as me telling scientists
that their notation is all wrong, it is just a warning that nice
implicit notations on paper don't always transfer well to programs.
With that in mind, I'd probably write :-

   T(i) = C(i,j,j)

as

  t = trace c

and hide all the details in _trace_.  However, I'm sure this is
anathama to any scientists.

   I think it wouldn't be so bad to allow you to explicitly say these things:

   for all i T(i) = sum_over(j) C(i,j,j)

Well the best I can do for this is :-

t = array (m,n) [ i := sum [ c!i!j | j <- js ] | i <- is ]
  where
    js = range (jlb,jub)
    is = range (m,n)
    ((m,jlb,_),(n,jub,_)) = bounds c

and even then the c!i!j stuff may be wrong :-<

BTW, what happened to the complex variable or exponential notation,
was the above so bad that it wasn't even worth discussing?

bevan



Thu, 16 Feb 1995 22:23:17 GMT  
 Scientists as Programmers (was Re: Small Language Wanted)

   Yes, I would myself like to see these loop-constructs in Sather:

   loop       until <xxxx> loop   while <xxxx> loop  for <xxxx> to <yyyy> loop
     <xxxx>     <yyyy>              <yyyy>             <zzzz>
   end        end                 end                end

IMHO the above are quite poor syntax for expressing the kinds of loops
that I see in numerical code.  Quite often it is possible to work in
parallel, and all the above do is make it harder to extract the
parallelism (of course so does the FORTRAN notation, but there is not
reason to make the same mistake :-).  In the cases where it is not
numerical, syntax like the above is often useless as it is usually
restricted so that you can only iterate over integer indices (cf
Oberon-2).  Note some languages get this right and let you iterate
over whatever you want e.g. Eiffel and C (given Sather's parentage I
guess it does to)

Anyway, I think the following are "better" approaches :-

1. use a language that achieves the same effect in a "better" way
   e.g. Haskell with list comprehensions or Lisp + loop macros /
   series package.

2. use a language that allows you to extend the syntax yourself e.g.
   Scheme and Lisp so that you can do whatever you want.  There is
   potential for getting this badly wrong, but as it takes someone
   with a discerning taste to use Scheme/Lisp in the first place it
   usually works out ok :-)

3. Have a special notation for numerical iteration (that covers the
   4th example), and leave everything else to a generic 1 1/2 loop
   e.g. "loop ... exit when ... end".

Of course, it is all just concrete syntax so who cares anyway :-)

bevan



Fri, 17 Feb 1995 01:25:05 GMT  
 
 [ 809 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54]

 Relevant Pages 

1. Scientists as Programmers (was Re: Small Language Wanted)

2. JOB: Tcl/Tk/Java programmer/scientist wanted

3. Lisp Programmer wanted for small high-tech firm in San Diego

4. ST programmer wanted for small DB2/2 job

5. Wanted: small meta-data language

6. Summary: Small Language Wanted

7. Summary: Small Language Wanted

8. Small Language Wanted

9. Summary: Small Language Wanted

10. Small Language Wanted

11. Summary: Small Language Wanted

12. Small Language Wanted

 

 
Powered by phpBB® Forum Software