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