worley@eddie.mit.edu.uucp (Dale Worley) (09/13/88)
> 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 <think!compass!worley@eddie.mit.edu.uucp>] -- 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
wendyt@pyrps5.pyramid.com (Wendy Thrash) (09/21/88)
Me: >> [I]f 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. Dale Worley: >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!". That is precisely what I would like to do: unleash a horde of one hundred thousand numerical analysts clamoring for a useful programming language; then the next ANSI committee will have a harder time shouting them down. >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. We could debate this point, but perhaps we'd best do so in talk.origins. I am an evolutionist; I believe that computer languages evolve. I believe that this is a good thing. Others may disagree. Certainly I'd be greatly distressed if I were required to make *(a+1) be the same as b after an int a,b; declaration, but if it would sell a hundred thousand systems I'd find a way to do it. (I'd also make it an option, since it would absolutely kill us on performance. :-) ) Six or eight years ago I held a hard line against extensions; if it wasn't in the standard, I wouldn't do it, and I'd say "dweeb" or worse to anyone who thought that because his compiler did it, mine should. I've mellowed with age, and I find that many of those dweebs out there actually know more about their needs than I do. By the way, it seems to me that ANSI C provides a way to do what I want and stay within the language definition. Something like #pragma associativity off could disable the use of the associativity by the compiler for floating-point computations, n'est-ce pas? [No, pragmas aren't supposed to change the semantics of code. It seems to me, though, that since floating point operations are not in general associative the "as if" rule would rule out rearranging such operations except in the rare case where the compiler can prove that the results are the same. If someone who really knows the proposed standard can comment on this, I'd be pleased to hear about it, otherwise I consider this topic wrapped up -- it's getting too close to theology. I wouldn't mind some suggestions about what sorts of things to provide in a language for numerical analysis, whether a superset of C or anything else. -John] [From wendyt@pyrps5.pyramid.com (Wendy Thrash)] -- 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
henry@zoo.toronto.edu (Henry Spencer) (09/22/88)
In article <2671@ima.ima.isc.com> our moderator writes: >[No, pragmas aren't supposed to change the semantics of code... A common misunderstanding. In fact, the last two drafts have not clearly specified whether they are allowed to or not. Neither interpretation is self-contradictory. The most common argument against is that one is not supposed to interpret one paragraph of a standard without considering the rest, and therefore #pragma is bounded by the rest of the standard. The counter-argument is that the same reasoning applies in reverse: one cannot understand the rest of the standard without considering that that one little paragraph about #pragma may have the power to change it all. There was some sentiment for resolving this ambiguity, but I don't know whether anything will be done now (nothing was done in the May draft). >... since floating point operations are not in general >associative the "as if" rule would rule out rearranging such operations >except in the rare case where the compiler can prove that the results are >the same... This indeed appears to be the case. The sloppy old C wording about how the compiler is free to rearrange is pretty much gone, replaced by the "as if" clause. But the "as if" clause is more restrictive, since it seldom applies to floating point, and in general doesn't even apply to integers (although in fact the only real problem with integers is the occurrence of overflow, and an implementation which ignores overflow can rearrange integer expressions to its heart's content). Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu -- 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