Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83 based; site hou2d.UUCP Path: utzoo!watmath!clyde!cbosgd!ulysses!mhuxr!mhuxt!houxm!hou2d!osd From: osd@hou2d.UUCP (Orlando Sotomayor-Diaz) Newsgroups: mod.std.c Subject: mod.std.c Digest V11#1 Message-ID: <765@hou2d.UUCP> Date: Fri, 4-Oct-85 17:13:51 EDT Article-I.D.: hou2d.765 Posted: Fri Oct 4 17:13:51 1985 Date-Received: Sat, 5-Oct-85 07:48:51 EDT Organization: AT&T Bell Labs, Holmdel NJ Lines: 93 Approved: osd@hou2d.UUCP From: Orlando Sotomayor-Diaz (The Moderator) mod.std.c Digest Fri, 4 Oct 85 Volume 11 : Issue 1 Today's Topics: float/double floats ---------------------------------------------------------------------- Date: Wed, 25 Sep 85 08:41:39 pdt From: Vincent Manis Subject: float/double To: cbosgd!std-c@LOCAL.Berkeley.EDU The point which I was trying to make in my earlier posting was that the present C rules make the language somewhat laughable to numerical analysts. If a language is to have types at all, the types should tell the programmer what precisions, etc., are to be used. Relying on the stated properties of an implementation, or on an extra-linguistic feature such as a compiler flag, certainly doesn't render programs particularly portable. I must admit that I hadn't really thought of passing floats by address; the resulting program would look extremely grotty. There are two ways of doing it; my preferred method would be with a pragma (thus getting the compiler into the act); another method, which would only work on IEEE-conforming implementations, would be to have a routine which sets the effective runtime precision. Because this second method is not terribly portable, it shouldn't be in the standard (though there would be nothing to stop implementors from providing it if they can). ------------------------------ Date: 26 Sep 85 07:01:14 CDT (Thu) From: ihnp4!utzoo!henry Subject: floats To: ihnp4!cbosgd!std-c > I vote for at least _allowing_ an implementation to use float arithmetic. This has been permitted by the draft standard for a long time now. Whether the implicit float->double conversion appears in various places is said to be "implementation-defined", which means that it's the implementor's choice but he must document it. > The coercion of floats to doubles as procedure parameters is just plain wrong, > regardless of whether it makes programs more or less efficient... Apart from some annoying implementation issues, it means you don't have to have two different sets of library routines, with all the potential for error that ensues. > What I'd like is the ability to disable that coercion (perhaps by means of > a pragma). That way, if I really want floats to be floats, I can get that > behaviour... In the new standard, it is possible to declare the types of a function's parameters. If they are float, the float->double conversion does not occur. All the standard library functions still take double, so you don't need two different sin() routines and such unless you really *want* them. > (Some machines would probably prefer doubles, but most would probably prefer > floats.) Actually, most non-numeric users would probably prefer double, to give maximum protection for things they don't want to analyze in depth. > C has even a bigger problem with floating point than the use of double > precision for all floating point calculations. Floating point computations > are not really associative and distributive, and the fact that C will reorder > such operations (EVEN IN THE PRESENCE OF PARENTHESIS!!) means that for most > numeric applications C is quite useless... I hate to mention it, but this is a generic problem of optimizing compilers and is *not* restricted to C. Fortran compilers have been known to do this sort of thing as well. Yes, even in the presence of parentheses. The fact is, if this level of detail matters to you, you simply must find out what your compiler's view of the issue is. Using Fortran rather than C does not guarantee safety. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry ------------------------------ End of mod.std.c Digest - Fri, 4 Oct 85 17:11:04 EDT ****************************** USENET -> posting only through cbosgd!std-c. ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C) In all cases, you may also reply to the author(s) above. Brought to you by Super Global Mega Corp .com