Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.lang.c Subject: Re: Order of evaluation, machine floating point Message-ID: <2910@jade.BERKELEY.EDU> Date: Tue, 24-Mar-87 03:58:58 EST Article-I.D.: jade.2910 Posted: Tue Mar 24 03:58:58 1987 Date-Received: Thu, 26-Mar-87 00:55:57 EST References: <4775@brl-adm.ARPA> <7779@utzoo.UUCP> <521@cpocd2.UUCP> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 33 In article <521@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >> #3 may be true for the naive, but makes the pros unhappy. > >Unless you happen to be working on an IBM 360/370 family machine. The >"single precision" arithmetic is so bad that it has often been called >"half precision". The C insistance on double precision makes a lot of >sense in such an environment. Even there, the comment about #3 is still true. I know how bad the 360/370 single precision floating point is. I also know how _expensive_ the double precision stuff is - it takes about four times as long to do things. You can have the best of both worlds by having important internal routines do things in double precision, but not having to pass double precision values to them. Of course, C's forcing things to double breaks that. K&R's forcing things to double precision, as well as not having a reasonable way (I know, use temporary variables; that's not reasonable!) to force order of evaluation made it almost completely unsuitable for doing number crunching. ANSI has fixed both of those (or made it possible for compiler writers to fix them). Now, all I need is an interface to all those FORTRAN libraries out there....