Schauble@mit-multics.arpa (Paul Schauble) (12/23/85)
From: jimc at UCLA-CS.UUCP
The preliminary draft "C" standard X3J11/85-138 says in sect. B.1.2.3 (program
execution) line 171 that the compiled code has to produce the same (sic)
result as double precision, but needn't actually be double. Line 163 makes
a similar statement about promoting char to int.
By the way, it's hard to be sure that
(float)x * (float)y == (float) ( (double)x * (double)y)
down to the last bit in every pathological case, but in practice all we
really need is that the answers differ less than an implementation-defined
maximum, typically 1 least significant bit of float. How do people think
about interpreting "same" in this way?
James F. Carter (213) 206-1306
UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024
UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU
------------------------------
I don't like it. The point of my original posting, which started this
whole discussion, it that I, the programmer, should have control over
the precision of the operations. Many other languages have reasonable
rules about doing <float> <op> <float> in single precision and <double>
<op> <float> in double with appropriate conversions.
I don't know how the standard people should handle this. I am asking to
be able to apply C to a problem domain that it has never traditionally
handled. This requires a change in this "feature" of promoting to
double. I believe that unless this can be changed that C will have to be
written off for most numeric work and for a large range of control
problems. Much as I hate to, I am presently investigating Pascal and
Modula-2 for my current work.
Paul
Schauble @ MIT-Multics