🚀 go-pugleaf

In article <1046@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes:
> In article <1370@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> 
>     In article <1035@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes:
>     > In article <1989Jun26.195044.4197@cs.rochester.edu> crowl@cs.rochester.edu
>     > (Lawrence Crowl) writes:
>     > 
>     > 	[1] You are not supposed to write assembler programs on a RISC
>     > 	    machine. The compilers have sophisticated algorithms to generate
>     > 	    "optimal" multiplication/division out of simpler instructions.
>     
>     I find this attitude arrogant.  Neither you nor anyone else knows what 
>     complicated operations I want to do.
> 
> Ehi! Two notes: First, I wrote point [1]. Lawrence Crowl has no fault :->.
> 
> Second, The attitude of RISC designers is not "arrogant"; one of the well
> publicized tenets of their philosophy is to make the instruction set
> simpler, and compensate at the compiler level. This is in most cases
> remarkably successful.

You do not understand.  A very good optimizinng compiler (and I have not
seen one) can do a better job of doing a particular complex operation than
I can, PROVIDED that I want to do that operation.  If my algorithm is
necessarily broken down into operations that the compiler writers have
taken into consideration. the compiler might be able to do better than
I can.  But even this has a caveat; I am not confined to a single algorithm,
and my choice of algorithms is decidedly influenced by machine properties.
In most cases, I do not need run-time profiling; I know my algorithms.

>     Why should you try to make it difficult for me to use the power of the
>     computer?

And what if my algorithms use instructions which I can form out of the machine
primitives easily, but which are at best very clumsy in the HLL operations the
unknowing HLL designer provides me?  You do not know what I have thought of.
I do not know what I will think of tomorrow.  I have both "portable" and
highly non-portable examples of this.

> Well, RISC advocates don't try to make life harder for you; they try to make
> the machine faster by having simpler hardware at the price of more complex
> code generation. They don't see more complex code generation as a goal in
> itself (well, occasionally I have my doubts :->).
>     
>     > 	[2] Fixed point and the "muldiv()" idea to me look very much in the
>     > 	    RISC philosphy of minimalism. Fixed point, and multiple precision
>     > 	    integer arithmetic, are in many many cases preferable to floating
>     > 	    point and its complexities. Too bad that mathematicians are lulled
>     > 	    in a false sense of familiarity by floating point's "scientific
>     > 	    notation" and apparent support for real numbers.
>     
>     Do any mathematicians take this attitude?
> 
> A lot, a lot. Most mathematicians doing programming are not numerical
> analysts (and even numerical analysts often are not as diffident of floating
> point as they should be).

>     Maybe if their only knowledge of computers comes from HLLs and they
>     swallow the hype.
> 
> Fortran is very popular, isn't it?  Well, I would also argue that Fortran is
> so popular with mathematicians precisely because it was *designed* as a
> FORmula TRANslator, i.e. to give the illusion of dealing in familiar
> mathematical formulas, to the point of using the same temrinology.

It is.  And anybody who thinks that Fortran is an adequate language for any
serious mathematics is either ignorant or stupid.  To quote the number
theorist D. H. Lehmer, pioneer in computational number theory even BC (before
computers) [quote from memory; may be inaccurate]

	None of the high level languages are adequate for number theory.
	Furthermore, I would not be able to design an adequate one.

Now Algol had already been produced, with the claim that it was a good
language for any problem in numerical mathematics.  It is not.

Few mathematicians know, unlike Lehmer and me, just how a computer works.
They are given to believe that it is a black box executing Fortran or
whatever.  Like the example cited by Klamkin of the use of oodles of
computer time to solve an initial value problem, where < 5 minutes of
thinking (I am not assuming that they are very good) and a small amount
of computation give an accurate answer, more accurate than they achieved.

What is there to know?  I have not seen a computer instruction set where
the user instructions (I am excluding much of the supervisory and kernel
stuff, which a user will not be able to access on a multi-user system,
although the user should be able to discuss problems with those who can)
are anywhere near as complicated as Fortran or C.

>     Mathematicians who know that floating point numbers are, in reality, only
>     approximations to real numbers will not be so confused.
> 
> But in my experience many mathematicians (or physicists) are not numerical
> analysts at all, and expect the computer to do their calculations as they
> intend them to be. Such people are not aware of the fact that floating point
> is *not* (emphatically!) an approximation of R^n; floating point is
> *radically* different from R^n (even fundamental properties of arithmetic are
> not the same!).

So why not let them know what's going on?

> As a palliative, a lot of effort in the design of the IEEE floating point
> standard has been devoted to make floating point calculations *safer*, i.e.
> a bit less surprising to those that think in terms of R^n. A laudable goal,
> in some respects, but one that has costs in architectural terms, and in
> perpetuating comfortable delusions.

This is, as stated, a palliative.  Palliatives do not always work.  BTW, I
find the IEEE standard frequently a pain; I would prefer the option of
having unnormalized floating point when I want it.  If you cannot see
why I want it, and I assure you that those cases are not handled as well
with normalized, you are in no position to criticize.

I am not saying that these HLLs may not save time.  I use them myself.  But
they are not adequate.  They are not complete.  They do not have the ability
to accommodate simple extensions.  And no matter what you put in, tomorrow
somebody will want something else, easily handled at the machine level.

I had to write a function program in our horribly designed assembler language
because the HLLs available did not have the constructs needed.  The machine
is easy to understand, but most assembler languages are designed to make life
difficult for the programmer.  Some HLL ideas can, and should, be used at the
assembler level.  Some should not even be considered.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)