Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucla-cs!rutgers!cmcl2!lanl!nmsu!opus!ted From: ted@nmsu.edu (Ted Dunning) Newsgroups: comp.lang.misc Subject: Re: Efficient Fortran Message-ID: Date: 3 Aug 90 18:09:10 GMT References: <1991@key.COM> <2378@l.cc.purdue.edu> <8E+4_83@ggpc2.ferranti.com> <2426@l.cc.purdue.edu> Sender: news@NMSU.Edu Organization: NMSU Computer Science Lines: 80 In-reply-to: cik@l.cc.purdue.edu's message of 3 Aug 90 13:05:48 GMT 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. The several supercomputers I know, as well as the VAXen, are different from IEEE. If fact, their hardware as actually implemented on several models predates IEEE floating- point standards. so? that really doesn't cause much problem except insofar as accuracy is concerned. the actual format of the floating point numbers only matters in exceedingly rare situations. 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? 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. 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? is it that there some deep psychological need to unpack things quickly? 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. 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. 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. -- Offer void except where prohibited by law.