osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (10/05/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
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 <manis%ubc.csnet@CSNET-RELAY.ARPA>
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.