Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!watcgl!onfcanim!dave
From: dave@onfcanim.UUCP
Newsgroups: comp.lang.c
Subject: Re: Optimizing Floating-Point Expression Evaluation
Message-ID: <15296@onfcanim.UUCP>
Date: Wed, 29-Apr-87 11:01:09 EDT
Article-I.D.: onfcanim.15296
Posted: Wed Apr 29 11:01:09 1987
Date-Received: Thu, 30-Apr-87 06:42:06 EDT
References: <16646@sun.uucp> <4616@utcsri.UUCP> <589@omepd>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 70

In article <589@omepd> jimv@omepd.UUCP (Jim Valerio) writes:
>
>But I think you are asking the wrong question.  I would ask: why
>partake in the reprehensible practice of hiding the floating-point
>arithmetic behind a macro name if you don't want it to be taken a an
>indivisible entity?  Why declare `THING' unless you want to treat it in
>the program as a single variable?  If `THING' is imitating a single
>variable, then the parentheses should be honored.  If `THING' is
>imitating a cheap function call, then following the parentheses exactly
>mimics the desired semantics.
>
>My point is that this is an example of intent to evaluate the expression
>in the parenthesized order, or plain poor code.

I strongly disagree.  For example, I have the following macros in a
piece of code that calculates the voltage levels of portions of a TV
waveform:

	#define SETUP 7.5

	#define IRE(mv)	((mv)*140.0/1000.0)
	#define MV(ire)	((ire)*1000.0/140.0)

Now, these are macros for the usual good reasons:

1) conversion from IRE units to millivolts and vice versa are "logically"
   functions, and I want the code to read that way rather than be cluttered
   by the details of the computation every time it is done - this improves
   the readability of the code a great deal.  Yet there is no need to
   make them actual function calls.

2) All of the definitions above are appropriate for NTSC, but wrong for
   one of the European colour systems, so I use a #ifdef to conditionally
   define these macros.  This seems cleaner to me than conditionally-
   compiled code scattered through the program, conditionally-compiled
   real functions, or an "if" statement in a real function

So will you grant that I have good reasons for using a macro?

Yet, when I actually use

		y = MV(y*(100.0-SETUP) + SETUP);

I would be happy to have the compiler rearrange the entire expression
in any way that it wants, regardless of where the parentheses in the
macro happened to fall.  I just want the approximate answer.
Any expression rearrangement or constant folding that speeds execution
is fine with me; I don't care about order of evaluation because the
roundoff errors will be smaller than I care about no matter what.

In fact, there are many calculations done in computer graphics where
only the first 12 or 16 bits of the mantissa are significant, and
roundoff need not be worried about.

To restate that:  Yes, the macro is written like a function call because
I want to *think* about it as a function call.  But I don't want nor
expect it to be *evaluated* as if it were a function call, since no
macro is in fact evaluated like a function call.

Macros are *not* exactly the same as a function call - anybody who calls
a macro with parameters that have side effects has to be aware of this.
If I *really* want a function call's semantics - all arguments evaluated
first, the computation performed, then a single value returned for
further use - I'll *write* a function.  But if a macro is adequate for
what I want, I'll use it.  Please credit me with the intelligence to
determine which is appropriate.

People who expect macros to behave exactly like functions are wrong.
Let's educate them, or instruct them not to use macros at all, rather than
hobbling the language to make it fit their expectations.