Re: Programming skills required by mathematicians?

On Jul 1, 7:40 am, hru...@[EMAIL PROTECTED]
 (Herman Rubin) wrote:
> In article <ddfb7$48688db5$82a1e228$25...@[EMAIL PROTECTED]
>,
>
> I have programmed in Fortran, C, and assembler for
> different machines.

Yes, those are sure good ones. Fond memories. Have
you had a chance to work with any of the languages
that have come out in the last 35 years? Some of them
are quite good.


> I am quite aware of even the
> fact that efficiency for subroutines requires taking
> into account the differences in the different machines,
> and I have also stated that I can see how to produce
> a somewhat high level assembler language easy to use.

Certainly high level assembler is easier to use
than low level assembler. Or machine language. But
it will be harder to use than pretty much anything else.


> Those who think HLLs are such a great idea, here is a
> challenge.  The function I am giving arises naturally,
> and it is quite difficult to do EFFICIENTLY in any HLL.

One might have an application that has to respond in
such-and-such a way within x number of milliseconds.
But "efficiency" by itself is not a goal for software
development. It might be a means to an end, but never
a goal in its own right.


> Let x be a positive real number, whose binary expansion
> is x = \sum a_i/2^i, a_i = 0 or 1.  Then
>
>         f(x) = \sum i*a_i/2^i.
>
> I have done some work on methods of generating non-uniform
> random variables from uniform bits.  There are some technical
> re****ts available from the Purdue Statistics Department.
> Among them are some I call "infinite precision", in that
> no computer roundoff is involved.  The easiest one of these
> is to generate the density 2x from 0 to 1.  The entire
> algorithm is
>
>         I = distance to the first 1 in a random bit stream;
> discard this part of the bit stream
>         X = U with the I-th bit after the binary point
> changed to 1.
>
> Alas, few of these are efficient, except possibly on an FPGA,
> but the amount of work is finite random for all distributions
> in any number of dimensions with lower semi-continuous density.
>
> I have a recent paper with Brad Johnson on acceptance-replacement
> generation of exponential and normal random variables, using
> exponentials to test and reuse of successful test exponentials.
> These vectorize or parallelize well if one changes the "control"
> part of the algorithm somewhat, and that consideration also went
> into the design of the algorithm.

So, how many times is this code going to get executed, and
in what application, and in what context? Unless the answers
are severe, the correct course of action is to code it in
the most straightforward way and forget it.


> I do know something about getting the power of the machine, and
> doing operations beyond the low precision hardware.  Even if only
> partial, there should be a convenient way of including assembler
> instructions in a program without losing "optimization"; I have
> done that on the CYBER 205.  I have also in my files a design for
> a decent quick assembler for the 780; I cannot find what I did
> on the 205, but I remember some of it, including the most complicated
> single one.

I never worked with the CYBER, but I did a lot of coding in
Fortran on the good ol' 780. But you do know, don't you, that
those days are gone? Not only are those machines obsolete,
but the companies that made them are largely forgotten.
I'm sure there are people reading this who have never heard
of Control Data because they were born after it ceased to
be a computer company. DEC was acquired by a bigger
fish ten years ago which was then itself consumed by an
even larger fish. Today my iPhone has more than 100 times
the computing power of a 780.

The idea of assembly code inline in high level code made
sense in the 1980s but not since. The idea of hand-coded
assembly routines for speed made a lot of sense in the
1990s, for performance-critical inner loops anyway. There
are still a few scant places where that idea makes sense,
but they are getting fewer and fewer. It is harder every
year to outperform the compiler, and there is less reason
every year to try.

I used to write assembly code for some different Adobe
apps in the early 1990s: Photoshop and Premiere. The
processor being targeted was the 486, and there was
a nice chart you could flip through and see how many
cycles each instruction was. You could come up with
different approaches, sum up the cycle count, and
compare.

When the Pentium came out, that got a lot harder.
Now there was a pipeline, and the cycle count wasn't
so straightforward. You might be able to pair these
two instructions, or not.

These days the situation is ridiculous, with very long
pipelines, multiple execution units, etc. etc. and you
can't even *get* a chart.


> One danger of HLLs is that the user has no idea
> of how long something will take.

That's just simply not true. Languages like C++ and
Java have quite transparent performance models; in
fact this may even be a good part of why they're
so successful. Even when using something wildly
abstract like SQL, one can still get an execution plan
out of the engine, and do various tweaks to change
it. Not that one ever has much need to.


> As for gotos, I find them easy to use,
> and spaghetti code is best for spaghetti algorithms.

Sure, gotos are easy to write, but what's usually im****tant
for code is that it be easy to read and easy to maintain,
and gotos are anathema to that.


Marshall