Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Newsgroups: comp.lang.c Subject: Re: C and Floating Point (really parentheses) Message-ID: <3091@jade.BERKELEY.EDU> Date: Wed, 8-Apr-87 17:04:28 EST Article-I.D.: jade.3091 Posted: Wed Apr 8 17:04:28 1987 Date-Received: Mon, 13-Apr-87 05:37:46 EST References: <6748@brl-adm.ARPA> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 46 AAAAAARRRRRGGGHHHH!!!! ENOUGH! C started life as a language for building systems tools, not for doing number mangling. I've worked with C compilers that didn't have floats, and never noticed. About the only time I've ever used a float in C is for examples & exercises, _never_ for a useful tool. Floats weren't handled very well in early C compiler. If the PDP-11 hadn't had a floating type, C might not have had floats at all. In spite of the problems with floats in C, people tried going number crunching in it. The ANSI standard makes some concessions to people foolish enough to want to do number crunching in C. Now they start shouting that it's not enough, and ask for more, and start asking for a "more readable" language. If you find C inadequate as it is, go find another language! Better yet, design your own, write a good compiler for it, put that in the public domain (or at least make it freely redistributable), then write a good textbook on how to use that language for fooling around with floating point numbers. Not only will you have what you want, you'll have done the world a favor, and probably have become famous. But let the C community have a language that does what it was designed to do as well as possible: systems-level programming. Sure, you may think a few extra instructions in an expression is minor, but when that expression is in the inner search loop of vi, it will chew up a lot of machine time. Final comment: from the looks of ANSI C, an attempt was made to only add features that wouldn't require complete compiler rewrites; changes to the parser, or tweaks to the optimizer (I don't do enough compiler work to be sure, though). Making parens "specify order of evaluation" instead of "override operator precedence" would require major work on the one C compiler I'm familiar with. It throws out parens in the parse as it builds the tree, and then manipulates that. You'd need a new tree node, and....