Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!umich!samsung!uunet!husc6!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Efficient Fortran Message-ID: <2428@l.cc.purdue.edu> Date: 3 Aug 90 21:28:25 GMT References: <1991@key.COM> <2378@l.cc.purdue.edu> Organization: Purdue University Statistics Department Lines: 149 In article , ted@nmsu.edu (Ted Dunning) writes: > > In article <2426@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > > Which machine's floating point representation are you going to use? > > whichever machine you are on. Then you do not have full portability. In using a Monte Carlo procedure, you will get an acceptance on one machine rejected on another. If many random inputs go inot an observation, all observations after this happens are different. This is a lack of portability, and is not merely a matter of accuracy. ...................... > c{'z} ={tc} {-}{|}{ta}a{'x} OP{mod} {|}{tb}b{'y} {/\{~}w} > > is the way I would write the general vector instruction on the > CYBER 205. > > care to justify this? or is the fact that you would write it that was > sufficient to make everyone want to write it that way? Only partially. I do not expect someone else to come up with exactly the same thing, but it would be very similar. The vector c is the destination vector, with z an optional offset; tc overrides the type (half or full) of the operation, - means negation, | means absolute value, ta and tb can override the vector or scalar aspect of the corresponding type, and if vectors they can have an offset, if present w is a bit vector determining which values are substituted, and ~ means complementation. OP is the operator, and some of the operators have modifications, with defaults depending also on the types. Compare this with the customary assembler type of statement for ease of understanding. > Packing and unpacking floating-point numbers are portable > constructs, but I know of no HLL which has them. > > actually this isn't even true, since the sizes of and limits on the > components can very tremendously from machine to machine. So can the sizes of the various types in C or Fortran. It is no less portable than the arithmetic operators in the HLLs. > These should be operators, not function calls. > > you don't ever seem to answer the point that you only need to do fast > what you do often. do you really unpack as many floats as you > multiply? why does this operation need to be an operator instead of a > function call? Even if the function is totally inlined, so that it is as fast as an operation, I see no more reason why =PACK (or something like that) should be a function call than +. There also is the problem, lacking in most languages (I believe this can be done in LISP) of multiple returns from an operation. +UP (unpack) returns two values, as does division with quotient and remainder. > is it that there some deep psychological need to unpack things > quickly? Why do some computer scientists seem to have some deep psychological need to make things clumsy? If I want to unpack things, I see no reason why I should have to use inadequate notation because the language guru does not see why someone would want to unpack. Nor should I have to pass an address and load because they forgot, more than 30 years ago, that natural operations can return more than one result. Why should I have to do things slowly because of the antipathy of some computer scientists to the idea of the user using the relatively simple structure of the machine? Why do they want to leave out the natural hardware operations? By a natural hardware operation, I mean one which can be done easily by simple use of computer circuits and at most nanocode. > The idea of open subroutines, a cross between macros and inlining, > existed at the time of Fortran I. Fortran VI on the CDC3600 > allowed 3 additional types (to make a total of 8), and allowed the > user to define the Fortran operations on these types, but only by > subroutine calls. > > these seem irrelevant. unless, of course, you are still programming > in fortran I, or on the 3600. > > Why can we not have additional operator SYMBOLS added to a HLL? > > you can. note prolog. > > C and C++ allow additional types, only they do not call them types. > > they do if you define them with typedef in c. if you don't, then they > aren't really types since they are syntactically distinguished. > > in c++, they call them structures or classes. the fact that they are > types is never denied, this only recognizes the etymology of the > situation. At least according to all the C manuals I have read, typedef does not allow one to add types, only add aliases. That there were other types was explicitly recognized long before C and C++. > I was informed by soeone at ATT that the non-allowance of > additional operator symbols in C++ was an unfortunate oversight. > > only partially. it does preserve the ability of the language to be > parsed by a static parser. if you allow new operators and new > precedences, then you get into the serious problem of needing to > extend the parser in non-trivial ways *at compile time*. the lisp > community has been trying to get this just right for decades and is > still trying. prolog newcomers still cause insiders to giggle by > asking for a context free grammer for the language. This is true. I would be willing to give up a heck of a lot on precedence structure, however. The precedences, except for the common arithmetic operators, are fairly arbitrary, anyhow. Why not allow the parser to ask the programmer for the preference order, as well as evaluation order if it makes a difference? A lot can be helped by allowing explicitly temporary variables to handle intermediate results. There are ways around the problem of precedence. Maybe we should get rid of it completely, like APL. There are parentheses. The compliler can ask the programmer these facts. When coding myself, I have had only trouble with these arbitrary precedences. Which has higher precedence, << or +? > why don't you admit that the fact that *you* don't see any reason for > something does not mean that there isn't a reason. you have provided > ample evidence that it only means that you don't see. The only reasons I have seen advanced are that not too many people would use them. Suppose someone comes to me with a new type of statistical problem. After some work, an appropriate class of numerical procedures is produced for that problem. I see how a given machine works on the various procedures, and it is definitely not the case that the same procedure works well on all machines. Now, I have to go into contortions to get the procedure reasonably implemented. One does not use a different part of statistics for problems in biology and problems in physics. One should not have to use a different programming language for different types of problems. If a mathematical notation is clumsy, it usually does not last long. Neither should clumsy notation in Fortran or C or Lisp or assembler. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)