C Floating point arithmetic

[Daniel R. Levy]

In article <42 at brl-tgr.ARPA>, gwyn at brl-tgr.ARPA (Doug Gwyn <gwyn>) writes:
>> >No -- on most machines, single-precision does not offer enough significance
>> >for serious number-crunching, so people tend to use double-precision
>> >anyway if they care about the results.
>> Now, this is a most disingenious argument.  If this were really true, one
>> would map 'float' to the double-precision operations and totally ignore the
>> single-precision ones.
>> Let's face it - this, as well as several other "features" of the Unix system
>> (such as the treatment of parameters passed to functions) is left over from
>> the PDP-11 days, and puts the lie to Unix's claim of machine independance...
>
>I agree that in most cases where the loss of speed might really
>matter, double precision is usually needed anyway to get
>meaningful results.  Some people, though, judge code more on how
>fast it runs than on whether it performs a useful function
>correctly.

Sounds a bit pejorative.  If for example I were to attempt to speed up crun-
ching in, say, a Fortran program by using real [float] instead of double
precision [double] I might well want to include both versions of a critical
routine in the code, and every so many steps run the double as well as the
single, or otherwise check the sanity of the results.   I am not a numerical
analysis guru, but I surmise there might be testable conditions whereby it
could be determined (without an overly large computational penalty) whether
a computation could be entrusted to single precision or whether double precision
should be used, prior to actually performing the computation.  Any crunch
gurus out there care to comment?
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!ihnp4!ttrdc!levy