Re: Programming skills required by mathematicians?

On Jul 2, 4:01=A0pm, hru...@[EMAIL PROTECTED]
 (Herman Rubin) wrote:
> In article
<7b49f964-7b90-445e-8df5-b52754301...@[EMAIL PROTECTED]
>,
>
> aruzinsky =A0<aruzin...@[EMAIL PROTECTED]
> wrote:
> >On Jul 1, 10:16=3DA0am, hru...@[EMAIL PROTECTED]
 (Herman Rubin)
wrote=
:
> >> In article
<84498550-6584-4d29-8703-d737ffe2e...@[EMAIL PROTECTED]
> >com>,
> >> aruzinsky =3DA0<aruzin...@[EMAIL PROTECTED]
> wrote:
> >> >On Jun 25, 2:40=3D3DA0am, rAgAv <ragav.pa...@[EMAIL PROTECTED]
> wrote:
> >> >> Hello,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .....................
>
>
>
>
>
> >> Computers have been used in number theory, algebraic geometry,
> >> computational problems which are more abstract than concrete,
> >> as well as more "practical" problems. =3DA0My technical re****ts,
> >> available from the Purdue Statistics Department, are a combination
> >> of an odd type of numerical analysis, and involve using Boolean
> >> operations on the bit patter of floats, something which is not
> >> in any HLL to my knowledge.
> >> Efficient random number procedures can be mainly done in HLL,
> >> but not with full efficiency. =3DA0And I doubt that anyone can
> >> get a full accuracy efficient procedure to generate
> >> f(x) =3D3D x - ln(1+x) to full machine precision without using
> >> the hardware structure. =3DA0Also, on most machines, multiple
> >> precision (I consider what is called "double" to be single)
> >> arithmetic is a mess because of the forced normalization of
> >> floats and the hidden bit. =3DA0The factor may be higher than 10.
> >> This is partly due to the HLLs, which have discounted fixed
> >> point arithmetic.
> >> >If you were an "applied mathematician," I would recommend Fortran
and
> >> >Algol only because there are many legacy programs written in these
> >> >languages. =3DA0In particular, the Collected Algorithms from ACM Vol
=
I to
> >> >III are mostly in Algol and Fortran.
> >> At that time, those were the only moderately well known HLLs.
> >> Machine independence is fine, but one must take into account
> >> the machine to get efficiency.
> >With modern compilers, one can easily mix a HLL with assembly
> >language. =A0For example, Visual C++ object code can be disassembled
> >into assembly language, modified, and then recompiled back to object
> >code.
>
> This is not good with the usual assemblers. =A0Often,
> the compiled code is "optimized" in such a way that
> it is hard to follow. =A0Optimization is needed later,
> not at compile time.
>
> Few current assembler languages are concise enough
> for easy coding. =A0Typing 50 characters when 5 would
> suffice leads to errors. =A0Something like the Cray
> assembler language with simplifications and overloading
> is needed.
>
> >For mental exercise and development, I recommend learning Forth which
> >uses Reverse Polish Notation (RPN), i.e. operands precede operators,
> >as in reality. =A0Forth and RPN foster efficient programming and
> >utilization of RAM. Standard Forth does not use floating point, but
> >Forth can be modified to do anything because it is easily extensible.
> >Some modified versions directly use the PC FPU stack very efficiently.
>
> RPN is moderately easy to write, and is my choice for
> a calculator. =A0I am less fond of the stack idea of
> Forth for a computer. =A0I do know how to juggle registers,
> and providing the appropriate information for a machine
> which offers many registers is quite different from doing
> good programming on a stack machine.
>
> --
> This address is for information only. =A0I do not claim that these views
> are those of the Statistics Department or of Purdue University.
> Herman Rubin, Department of Statistics, Purdue University
> hru...@[EMAIL PROTECTED]
 =A0 =A0 =A0 =A0 Phone: (765)494-6054 =A0 FAX:
(765=
)494-0558- Hide quoted text -
>
> - Show quoted text -

It is not a problem of juggling registers so much as juggling RAM.  To
prevent fragmentation of heap memory, the heap must be treated like a
stack, i.e., last in - first out (LIFO).  About 30 years ago, I
modified Forth for matrix operations.  The actual matrices were
allocated in heap memory, but the operand references to those matrices
were placed on the Forth stack which, along with RPN, forced LIFO
allocation of matrices in the heap.  Now, I find this experience
useful when writing image processing programs in C++, because heap
fragmentation is often a problem when processing large images.