Why no min / max

[Noob]

Hello,

I'm sure this topic has been beaten to death, but my google-fu
has apparently failed me this time.

As far as I can tell, the standard library does not provide
functions (or macros) to compute the minimum and maximum of
two values, be they integral values, or floating point values;
leaving it up to each programmer in the world to roll their own.
Is this correct?

What is the rationale for this omission in C89? in C99?

Is it because it is "simple" to implement as a macro?
Something along the lines of #define MIN(a,b) (((a)<(b))?(a)b))

Regards.

 

[Mark Bluemel]

As far as I can tell, the standard library does not provide
functions (or macros) to compute the minimum and maximum of
two values, be they integral values, or floating point values;
leaving it up to each programmer in the world to roll their own.
Is this correct?

C99 standard (I'm looking at the draft in
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>) paragraph
7.12.12...

 

[Eric Sosman]

As far as I can tell, the standard library does not provide
functions (or macros) to compute the minimum and maximum of
two values, be they integral values, or floating point values;
leaving it up to each programmer in the world to roll their own.
Is this correct?

No; you've overlooked the fmax(), fmin(), fmaxf(), fminf(),
fmaxl(), and fminl() functions.

What is the rationale for this omission in C89? in C99?

Mu.

Is it because it is "simple" to implement as a macro?
Something along the lines of #define MIN(a,b) (((a)<(b))?(a)b))

With the usual caveats about macros and side-effects, this is
a reasonable implementation for many cases. Note that it is *not*
reasonable for a system supporting floating-point NaN's: MIN(NaN,42)
could yield 42, while MIN(42,NaN) could yield NaN. I think most
people would find a non-commutative MIN surprising ...

 

[Tom St Denis]

     No; you've overlooked the fmax(), fmin(), fmaxf(), fminf(),
fmaxl(), and fminl() functions.


     Mu.


     With the usual caveats about macros and side-effects, this is
a reasonable implementation for many cases.  Note that it is *not*
reasonable for a system supporting floating-point NaN's: MIN(NaN,42)
could yield 42, while MIN(42,NaN) could yield NaN.  I think most
people would find a non-commutative MIN surprising ...

Simple just do MIN(MIN(x,y),MIN(y,x)).

Solved.

Tom

 

[James Dow Allen]

Simple just do MIN(MIN(x,y),MIN(y,x)).

Solved.

Try again. In the hypothetical (x=42, y=NaN)
MIN(MIN(x,y),MIN(y,x)) != MIN(MIN(y,x),MIN(x,y))

James

 

[Keith Thompson]

C99 standard (I'm looking at the draft in
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>) paragraph
7.12.12...

n1124.pdf consists of the C99 standard plus the first two Technical
Corrigenda. n1256.pdf includes all three TCs.

 

[Noob]

No; you've overlooked the fmax(), fmin(), fmaxf(), fminf(),
fmaxl(), and fminl() functions.

Right.

7.12.12.2 The fmax functions
double fmax(double x, double y);
float fmaxf(float x, float y);
long double fmaxl(long double x, long double y);

7.12.12.3 The fmin functions
double fmin(double x, double y);
float fminf(float x, float y);
long double fminl(long double x, long double y);

Allow me to revise my statement:

As far as I can tell, the standard library does not provide
functions (or macros) to compute the minimum and maximum of
two integral values. Is this correct?

What is the rationale for this omission in C89? in C99?

With the usual caveats about macros and side-effects, this is
a reasonable implementation for many cases. Note that it is *not*
reasonable for a system supporting floating-point NaN's: MIN(NaN,42)
could yield 42, while MIN(42,NaN) could yield NaN. I think most
people would find a non-commutative MIN surprising ...

As far as integer min/max is concerned, I suppose it would be
complicated to add them at this point? Because the whole world+dog
rolled their own (possibly slightly incompatible) version.

Regards.

 

[Noob]

C99 standard paragraph 7.12.12

Doh! That'll teach me to mention floating-point, when I was
mostly interested in the integer side of the issue.

 

[BartC]

Right.

Not quite. A proper built-in feature to compute min and max values would
work on any type.

The floating-point functions for this need a dedicated function for each
type; anyone could have created their own functions to do the same, and
could do the same for integer types too.

There would need I think to be 4 functions: signed and unsigned, int and
long int, or there would be if there was less confusion about the widths of
integer types (sometimes long int is the same as int, and sometimes the same
as long long int).

As far as integer min/max is concerned, I suppose it would be
complicated to add them at this point? Because the whole world+dog
rolled their own (possibly slightly incompatible) version.

All the standard could do at this point, is agree on what names to give
them. The actual implementations are trivial, and the semantics are not
difficult to get wrong.

(Having a standardised way to do integer min/max would make it a bit easier
for the compiler to optimise the operation, otherwise it needs to optimise
'return (a<=b?a:b);' which is not particularly demanding.)

 

[Nick Bowler]

Eric Sosman wrote: [...]

No; you've overlooked the fmax(), fmin(), fmaxf(), fminf(), fmaxl(),
and fminl() functions.

Right.

Not quite. A proper built-in feature to compute min and max values would
work on any type.

The floating-point functions for this need a dedicated function for each
type; anyone could have created their own functions to do the same, and
could do the same for integer types too.

This is a little bit dishonest, because standard C provides fmin and fmax
macros which work on every real floating type in <tgmath.h>.

 

[BartC]

Eric Sosman wrote: [...]
No; you've overlooked the fmax(), fmin(), fmaxf(), fminf(), fmaxl(),
and fminl() functions.

Right.

Not quite. A proper built-in feature to compute min and max values would
work on any type.

The floating-point functions for this need a dedicated function for each
type; anyone could have created their own functions to do the same, and
could do the same for integer types too.

This is a little bit dishonest, because standard C provides fmin and fmax
macros which work on every real floating type in <tgmath.h>.

Automatic promotions mean you can just use fmin/fmax (which are functions in
the 3 implementations I looked at) with either float or double. If you're
lucky the compiler will be clever enough to call fminf/fmaxf for floats,
otherwise it's a two-way trip to and from double (although on some machines,
that may be necessary anyway).

The same promotions mean you can also just define 64-bit int versions of
min/max (you still need signed and unsigned I think), and use these with any
width int type. But the costs of working with 64-bits on a 32-bit machine
might be more significant.

It's a bit messy. Min/max could have been defined as operators, then you
could work with signed/unsigned, 32/64-bits, and integer/floating point with
fewer headaches.

them. The actual implementations are trivial, and the semantics are not
difficult to get wrong.

Easier to get right than that sentence anyway...

 

[Eric Sosman]

[...]
This is a little bit dishonest, because standard C provides fmin and fmax
macros which work on every real floating type in <tgmath.h>.

Automatic promotions mean you can just use fmin/fmax (which are
functions in
the 3 implementations I looked at) with either float or double. If you're
lucky the compiler will be clever enough to call fminf/fmaxf for floats,
otherwise it's a two-way trip to and from double (although on some
machines,
that may be necessary anyway).

I think you've forgotten `long double'.

(And no: I'm not happy with the <tgmath.h> machinery either. But
I can only assume the problems of trying to make it "user-usable" were
just too daunting; them's the breaks.)

 

[lawrence.jones]

(And no: I'm not happy with the <tgmath.h> machinery either. But
I can only assume the problems of trying to make it "user-usable" were
just too daunting; them's the breaks.)

Fixed in the next release.

 

[Eric Sosman]

Fixed in the next release.

Be still, my heart!

 

[Nick]

Fixed in the next release.

I hope so. It always felt contrary to the spirit of C somehow. Once
you had varargs and the like, there was nothing that the standard
library could do that the user couldn't (except for the implementation
specific stuff it had to do, and you could do that if you knew how and
were prepared to wander away from portability). tgmath broke that.