Path: utzoo!utgpu!water!watmath!clyde!ima!compilers-sender From: think!compass!worley@eddie.mit.edu.uucp (Dale Worley) Newsgroups: comp.compilers Subject: Optimizations and Language Definitions Message-ID: <2658@ima.ima.isc.com> Date: 13 Sep 88 14:26:59 GMT Sender: compilers-sender@ima.ima.isc.com Reply-To: Dale WorleyLines: 43 Approved: compilers@ima.UUCP > From: wendyt@pyrps5.pyramid.com (Wendy Thrash) > > Moreover, I'm concerned about the application of arithmetic > "identities" at compile time: if I write y = (x - 1.0) + 1.0; > there's a very good reason for it, and I don't want the compiler > to mess it up, no matter what it is allowed to do by the language > definition. Please, at least honor my parentheses in > floating-point computations. Oh, God! Please, please, please, never say "I don't care what the language definition says"! You will unleash a horde of one hundred thousand dweebs who say "it works on *my* compiler, it should work everywhere!". The ultimate example was the fellow who wanted (in C) "&a + 1 == &b" when he declared "int a, b;"! (That is, the order of storage allocation must exactly match the order in which the declarations are written.) The only way to control this chaos is to *absolutely* respect the language definition, both in terms of what it guarantees, and in terms of what it does *not* guarantee. But this still leaves problems for, particularly, numerical code. Sometimes we want the order of evaluation to be very particularly controlled, and other times we don't. There are times when applying something as nasty as the distributive law to even F.P. calculations is innocent, and others when applying something as "innocent" as the associative law is disastrous. It would be nice if there was a language in which the programmer could specify which details were important and which weren't, but I haven't seen any. The ANSI C committee (with its unary + operator) made a valiant effort, but was shouted down. Oh, well. Dale [Your point about language defintions is very well taken. It's peculiar that people who design languages in which numerical computations are performed seem so often to fall prey to the traditional hacker misconceptions about floating point arithmetic, e.g. "since floating point results are approximate, they're not well defined," or "adding a little extra precision at random times won't hurt." -John] [From Dale Worley ] -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request