Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!cica!iuvax!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.theory Subject: Re: Why not multiple out parameters? [again] Summary: O(n) is still important Message-ID: <2514@l.cc.purdue.edu> Date: 4 Sep 90 18:02:51 GMT References: <1990Aug28.203643.11214@zaphod.mps.ohio-state.edu> <4060@rex.cs.tulane.edu> Organization: Purdue University Statistics Department Lines: 81 In article <4060@rex.cs.tulane.edu>, fs@rex.cs.tulane.edu (Frank Silbermann) writes: > David C. DiNucci: dinucci@ogicse.ogi.edu <11831@ogicse.ogi.edu> | >| > ... at higher "system" levels | >| > modules are being composed which each do a fair amount of work, | >| > and thus are likely to return many different kinds of results. | >| > Plugging these results into a record structure | >| > just so they can be pulled back apart again is nonproductive. > Frank Silbermann: fs@rex.cs.tulane.edu <4019@rex.cs.tulane.edu>, > >> Every module should perform a single conceptual operation > >> i.e. produce a single conceptual result, > >> and should be treated as a unit within the program > >> (i.e. as a record). If a module's different kinds of results > >> do _not_ form a conceptual unit, then the design is a kludge. > In article <2501@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > > All of these are natural and useful multiple outputs: > > ...a result and a domain indicator, e.g. the truth of a condition. > > ...an integer quotient and a floating remainder. > > ...a short integer exponent and a mantissa. > > ...the decomposition of a word into fields -- one a sign, > > another an integer, and the rest a floating point. > (And each combination can be viewed as a single object. So...?) > > > Putting these into a record to extract later > > is very definitely non-productive, > > like encoding multiplication as repeated addition. > The time loss due to encoding multiplication > as repeated addition is O(n). Grouping atomic information > into records hurts efficiency by at most a constant factor > (and an optimizing compiler might eliminate even that). Assuming fixed length numbers being added, this is so. But if one has 64-bit numbers being multiplied, and performs an addition every nanosecond (I do not believe that this has been quite yet obtained), it can take almost 600 years to perform the multiplication. The storage and reloading process right now can impose a factor of 5 or more now. If load/store continues to get slower compared to arithmetic, the O(n) term gets larger, so maybe it is no longer O(n). > A better analogy would the claim that > "storing a register into memory, only to later load it back, > is definitely non-productive, and therefore its is better > to program in assembler language." (Such claims have in fact been made.) Given a weakly-typed, overloaded-operator, user-extensible method of representing machine operations, with a good flexible macro processor, I would very definitely prefer to program that way. At least at the present time, and for a long time to come, the compiler cannot even begin to recognize what the thinking human finds elementary. > The real question is where a program ought to lie > on the machine-oriented/human-oriented continuum. > This is an economic($$) decision, with no universal answer. > For most applications, however, the economics > are shifting to favor more human-oriented programming, > and this includes the clumping of detail into fewer, > but larger and more meaningful, concepts. > That's what records are for. So the human, who understands what is needed in terms of machine operations, is to be restricted to those clumsy manipulations which the language designer managed to comprehend. This attempt to limit humans to doing what the idiot is capable of, and leaving the rest to the machine, is frustrating to the thinking human, as well as being noneconomic. It results in library programs operating at low speed. The idea that those writing programs to be included in a software library should be restricted to what an undergraduate is expected to do in a beginning programming course is what the above quoted paragraph states. Mathematicians have been dealing with these situations for centuries. That all calculations which can be done on a computer can be done clumsily on a Turing machine does not mean that that should be the way to go. -- 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)