max of min

[R.Biloti]

Hi

I defined two usual macros for max and min:
#define max(x,y) ( (x) > (y) ? (x) : (y) )#define min(x,y) ( (x) <
(y) ? (x) : (y) )

I need to compute max( x1, min( x2, x3) ).
Is it efficient to perform such operation in that way? I mean, this
macro is firstly expanded as
( (x1) > (min(x2,x3)) ? (x1) : (min(x2,x3)) )
and so the comparison in min(x2,x3) could be done twice. Should I
define an auxiliar variable to store min(x2,x3) and then call
max(x1,aux)? Is there a way to fix the macros so that the user
shouldn't care about?

Thanks
R. Biloti

 

[David Resnick]

Hi

I defined two usual macros for max and min:
#define max(x,y) ( (x) > (y) ? (x) : (y) )#define min(x,y) ( (x) <
(y) ? (x) : (y) )

I need to compute max( x1, min( x2, x3) ).
Is it efficient to perform such operation in that way? I mean, this
macro is firstly expanded as
( (x1) > (min(x2,x3)) ? (x1) : (min(x2,x3)) )
and so the comparison in min(x2,x3) could be done twice. Should I
define an auxiliar variable to store min(x2,x3) and then call
max(x1,aux)? Is there a way to fix the macros so that the user
shouldn't care about?

Thanks
R. Biloti

IMHO function macros usually should be avoided anyway.
Do you have a compelling reason to be using them? The only
real virtues I see above is that you can use the same macros
on different types. And you save the function call overhead,
which likely doesn't matter and may not exist if there is
optimization done by the compiler to inline the
(small) functions. And by using the macro you face issues
of side effects with multiple evaluation, the usual gripe
about function macros, particularly ones that don't give
themselves away by putting their names in all caps like
"min". Why not write functions to do what you want?

If you need to define an additional variable you lose one of the
virtues of this macro which is that you need to choose a type...

-David

 

[Mark McIntyre]

Hi

I defined two usual macros for max and min:
#define max(x,y) ( (x) > (y) ? (x) : (y) )#define min(x,y) ( (x) <
(y) ? (x) : (y) )

I need to compute max( x1, min( x2, x3) ).

you could write a specific macro to handle this case

#define maxmin(x1,x2,x3) /* definition left as execise for reader */

Is it efficient to perform such operation in that way?

very likely, if an auxiliary could be used, your compiler will be
smart enough to use it when in fully optimising mode. Its rarely worth
trying to outsmart the compiler.

Also: Learn the Three Rules of Optimisation....

There are three rules of optimization:

1. Don't optimize yet.
2. Don't optimize yet.
3. Don't optimize yet.

Translation : First produce quality code. /Then/ see if there are
performance problems. Then do a _careful analysis_ to find out where
bottlenecks exist Finally, do some optimization once you know where
its needed.

 

[Martin Ambuhl]

Hi

I defined two usual macros for max and min:
#define max(x,y) ( (x) > (y) ? (x) : (y) )
> #define min(x,y) ( (x) < (y) ? (x) : (y) )

These "usual" macros are quite unsafe, since they involve evaluating one
of the arguments twice. The only excuse for macros here is being too
lazy to use different functions for different signatures:

inline int maxi(int x, int y) {return (x > y) ? x : y;}
inline int mini(int x, int y) {return (x < y) ? x : y;}

I need to compute max( x1, min( x2, x3) ).
Is it efficient to perform such operation in that way? I mean, this
macro is firstly expanded as
( (x1) > (min(x2,x3)) ? (x1) : (min(x2,x3)) )
and so the comparison in min(x2,x3) could be done twice.

Just be glad you aren't using expressions for x1, x2, or x3 that have
side-effects.

 

[Malcolm]

IMHO function macros usually should be avoided anyway.
Do you have a compelling reason to be using them?
Why not write functions to do what you want?

It would be nice if that were the case. Unfortunately trivial functions like
min, max, clamp, lerp, rgb, and the like have a way of appearing in the
inner loop of critical functions, and so the function overhead is
prohibitive. An example is colour calculations where you need to clamp
channel values to the range 0-255. This operation can easily consume a large
chunk of your processing time.

 

[Martin Ambuhl]

It would be nice if that were the case. Unfortunately trivial functions like
min, max, clamp, lerp, rgb, and the like have a way of appearing in the
inner loop of critical functions, and so the function overhead is
prohibitive.

inline functions will, with a compiler not braindead, will avoid the
overhead, give you type checking, and avoid the problems of multiple
evaluations or arguments.

 

[zhaokai115]

shortly, you can x = min (x2, x3) then compute max (x1, x)