Array indexing vs. pointers...
Walter Bright
bright at Data-IO.COM
Sat Oct 8 06:16:37 AEST 1988
In article <8267 at alice.UUCP> ark at alice.UUCP (Andrew Koenig) writes:
>In article <1703 at dataio.Data-IO.COM>, bright at Data-IO.COM (Walter Bright) writes:
>> The result may differ in the last bit of the significand because
>> of this. However, in most cases, that is irrelevant and the
>> multiply will be significantly faster.
>If, however, you want your compiler to implement IEEE floating point,
>you had better not substitute a multiply by 0.1 for a divide by 10.
>
>IEEE defines the results of addition, subtraction, multiplication,
>division, square root, and a few other operations precisely -- down
>to the last bit. Either you get the right answer or you don't.
>It is true that in many cases users don't need the last bit or so,
>but a language implementer has an obligation to give it to the
>people who demand it.
You (and some others) misunderstood me. In no case did I recommend
the *compiler* perform the substitution. I recommended that the
*programmer* do it, of course after making sure that the semantics
for *his application* were the same.
For example, suppose you wished to convert Celsius to Farenheit
in a tight loop. Multiplying by the scale factor is much faster
than dividing by the reciprocal, and the answer will be correct
to the desired accuracy.
Another example is scaling things for a graphics display. It's faster
to design the system using a multiplicative scale factor rather than
a dividing scale factor.
In fact, for all you numerologists, the * may be what the algorithm
required instead the / to get the correct result.
In floating point, there is a speed/accuracy tradeoff, not a
right/wrong answer. Different applications require different
approaches. I suggested the replacement of a divide with a
multiply because:
1. Many programmers aren't aware that * is much faster than /.
2. Many applications don't care about the difference in result.
3. It's just another thing to look for.
I stand by my original comments.
More information about the Comp.lang.c
mailing list