Velocity Reviews > Why no min / max

# Why no min / max

Noob
Guest
Posts: n/a

 11-26-2010
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
Guest
Posts: n/a

 11-26-2010
On 11/26/2010 03:12 PM, Noob wrote:
> 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
Guest
Posts: n/a

 11-26-2010
On 11/26/2010 10:12 AM, Noob wrote:
>
> 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 ...

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid

Tom St Denis
Guest
Posts: n/a

 11-26-2010
On Nov 26, 10:54*am, Eric Sosman <(E-Mail Removed)> wrote:
> On 11/26/2010 10:12 AM, Noob wrote:
>
>
>
> > 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 ...
>

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

Solved.

Tom

James Dow Allen
Guest
Posts: n/a

 11-26-2010
On Nov 26, 10:58*pm, Tom St Denis <(E-Mail Removed)> wrote:
> On Nov 26, 10:54*am, Eric Sosman <(E-Mail Removed)> wrote:
> > ... 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.

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
Guest
Posts: n/a

 11-26-2010
Mark Bluemel <(E-Mail Removed)> writes:
> On 11/26/2010 03:12 PM, Noob wrote:
>> 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...

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

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Noob
Guest
Posts: n/a

 11-29-2010
Eric Sosman wrote:

> On 11/26/2010 10:12 AM, Noob wrote:
>>
>> 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.

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?

>> 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 ...

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
Guest
Posts: n/a

 11-29-2010
Mark Bluemel wrote:

> On 11/26/2010 03:12 PM, Noob wrote:
>
>> 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 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
Guest
Posts: n/a

 11-29-2010

"Noob" <root@127.0.0.1> wrote in message
news:id04d0\$cnp\$(E-Mail Removed)...
> Eric Sosman wrote:
>
>> On 11/26/2010 10:12 AM, Noob wrote:
>>> 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.

>
> 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.)

--
bartc

Nick Bowler
Guest
Posts: n/a

 11-29-2010
On Mon, 29 Nov 2010 12:37:50 +0000, BartC wrote:
> "Noob" <root@127.0.0.1> wrote in message
> news:id04d0\$cnp\$(E-Mail Removed)...
>> 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>.

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Albert Hopkins Python 31 02-04-2008 07:37 PM Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM juergen Java 3 09-20-2006 04:20 AM Vijai Kalyan C++ 1 03-21-2006 02:39 PM Lois HTML 1 12-27-2004 03:03 AM