NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/edu/1555

Internet Message Format | 1992-09-08 | 3.4 KB

Xref: sparky comp.edu:1555 comp.lang.misc:2952
Newsgroups: comp.edu,comp.lang.misc
Path: sparky!uunet!wupost!spool.mu.edu!umn.edu!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: na
Date: Sun, 6 Sep 1992 13:18:15 GMT
Lines: 53

In article <[e-mail]> [e-mail] (Edward S. Hirgelt) writes:

>On 3 Sep 92 15:25:12 GMT,
>[e-mail] (Amr Sabry) said:

>Amr> In article <[e-mail]>, [e-mail] (Herman Rubin) writes:
>Amr> |> There is generally no single algorithm optimal on all machines, so the
>Amr> |> hardware considerations at least have to be known to the programmer.

>Amr> Don't forget: you also need to know about the design of your car to
>Amr> drive it optimally, the design of your fridge and oven are also
>Amr> crucial, so is the design of your TV.

>I suspect that Amr means this humorously. However, there is a kernel of
>truth in it. Herman is talking about optimal, wringing the last ounce of
>performance out of an algorithm. To do the same to your car, you better
>know that you ought not exceed 6500 RPM on the engine (or whatever the
>limit is for your engine/transmission combination) or that your
>car or truck wasn't designed to tow a 8000 pound trailer.

It may be more serious than just wringing out the last ounce.  It may be
doing a job in one minute rather than one hour, or not even getting it
done.  It is often possible to see that for a particular type of algorithm
to do the job, far too many resources are needed.

One of my colleagues was interested in a problem with many cases.  Now he
did check out what had to be done using _Mathematica_.  But it was necessary
to reprogram the computations in C to get them done in minutes rather than
tying up the multi-user machine for days.

>The point in many of these and related discussions is knowing when you
>need to be truly optimal. If you're pushing the limits with your
>algorithms and/or problems, you need the fastest solution. Sometimes
>that requirement exceeds the need to be portable or to be readable.

>When solving a problem, know what the problem is first, then you can
>decide on the tools to solve it and evaluate the trade-offs involved.
>Sometimes that takes a software developer, sometimes that takes a
>scientist, sometimes it takes both. It also takes a good knowledge of
>the tools that are available that might be applicable to the problem.

There are algorithms which are, from a standpoint of the number of bits
used, quite cheap, and yet, the question remains as to whether they are
even worth the effort programming them.  The present languages are
cetainly inadequate to allow this; looking at the next bit in a bit
stream is costly even in assembler, when one has to consider that the
algorithm cannot know where in a word the bit is, or even whether the
bit buffer has run out, without explicitly checking.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!pop.stat!hrubin(UUCP)