Where should the type information be 227
Where should the type information be 229
Herman Rubin ? buttembler has zero precedence. Most (all, as far as I know) compilers check types and produce optimum...
Why not? There are things which should not be machine independent. We are not going to continue for long to follow Moore's law, and we need to prepare for efficient procedures. We need efficient semi-portability; the procedures for I-O and for the basic transcendental functions are not fully portable, and the same is the case for multiple precision arithmetic and the like.
THAT is something I would not consider, unless it was at least made part of a processor alternative which could be switched. buttembler coding does not have much operator precedence, and I am perfectly willing to add parentheses. In fact, it might be a good idea to have parentheses with degree indicators, as was done (without parentheses) in Whitehead and Russell.
Where should the type information be 231
On Thu, 31 Mar 2005 20:50:58 -0500, Herman Rubin Many modern compilers will do constant propagation. If your pow function is in-lined, then the constant propagation will follow naturally, and...
This is not necessary. buttembler code, as I would write it, would be more portable than you seem to think. If the code is x=y-z, with x, y, and z having compatible types, it would be almost fully portable.
Where should the type information be 232
I don't think it is that simple. While the "taste of the designer" is important, there are other facotrs. To use your examples, COBOL was designed from the beginning to...
No, I am viewing the problem from a semi-portable flexible users' point of view, buttuming the user is not an idiot. Compiler designs now try to make things idiot proof, which lowers the flexibility and usefulness.
Interpreters are just as rigid as compilers. I have used many of them. Mathematica is an interpreter language; its syntax is worse than most compilers.
I was not discussing what is usually called random access, but the use of random numbers. Most generation of non-uniform random numbers uses acceptance-rejection or related methods, and this will require programmer output for optimization. In fact, by considering optimization problems, one might well improve generators where they do not occur. SIMD really points out the problems.
In the fragment of code I presented, I know that the branching to case1, case2, case3, and case4 (fallthrough) are 1-6, 1-3, 1-3, and 1-6. I also know that the fallthrough structure eliminates many branches, and thus will essentially save time.
It seems that the philosophy is that the user should not be able to find out so he cannot complain about how inefficient the code is.
One of the problems now is that of cache boundaries. A student and I have written a paper on a fast method of generating exponential and normal random variables; it has been accepted for publication. These methods use tables; using larger tables is more efficient from the standpoint of the methods, but will cause caches to be loaded and unloaded if too large. This is something which the one implementing the process on a given machine should know about; should the table size be 256 or 1024? Give the user the full information about timing and the available buttembler operations; you will find that the ones "which nobody would use" will be used intelligently.
Where should the type information be 228
We are getting into the deep bowels of OS memory Debt Management here. It is the job of the OS to...
Probabilities do not change with the machine.
There are ways of checkpointing a program; these are usually put with the debuggers. But it is still the case that the producer of the algorithm usually has a good idea of what is rare and what is common.
-- This address is for information only. I do not claim that these views are those of the Statistics Department or of Purdue University. Herman Rubin, Department of Statistics, Purdue University