[erlang-questions] erlang:max/2 and erlang:min/2
Sat Sep 11 01:53:02 CEST 2010
This is fairly standard as far as I know in languages without strong typing
in function arguments (when that is the case, usually coercion happens which
hides this behavior from you).
For example in ruby:
>> [1, 1.0].min
>> [1.0, 1].min
And again in python:
>>> min([1, 1.0])
>>> min([1.0, 1])
For these languages (and erlang), order DOES matter.
This isn't unlike a naive implementation of min/max in C++:
#define max(A, B) A >= B ? A : B
However, even using c++0x:
auto SomeResult = max(1, 1.0); // what happens here? what is the type of
SomeResult? (float) See note below
auto SomeResult = max(1.0, 1); // what happens here? what is the type of
SomeResult? (float) See note below
*** Note below (really a side note, you can skip this) ***
The 'ternary' operator is special (in C/C++). In the case above, both A and
B can't be of different types. The type will be coerced to a common base
type only if possible, otherwise compilation will fail.
See for details:
http://msdn.microsoft.com/en-us/library/e4213hs1%28VS.71%29.aspx (applies to
other compilers as well)
The ternary operator can also be used as an l-value (for fun and profit) :)
((A >= B) ? A : B) = 123; // Don't do this.. otherwise your coworkers will
want to kill me for teaching you
In C++ at least, both types will be converted to a common base type with the
ternary operator or you'll traditionally write functions which will coerce
the arguments for you in order to use hardware specific instructions to do
max(A,B) becomes 2 instructions for floats/doubles (on powerpc, same for
min): C = A - B, C >= 0 ? B : A (powerpc has an instruction to compare a
float against zero and select the result (fsel))
For integers, you can go either with a branch or branch-free version.
Mixing types will always go to the float/double impl for obvious reasons.
As far as I know, in a loosely type language like erlang, you have to know
your data... if you sort/compare mixed types (integers/floats/otherwise),
you have to handle that case and be aware of the (potential) consequences.
I for one disagree with the global/total ordering imposed on mixed types.
But then again, I mainly come from strongly typed languages and I am not
aware of the original logic behind it, perhaps it makes perfect sense.
This thread should perhaps be merged with the 'strictly less then' thread
since it voices a similar issue regarding term comparison and ordering.
On Thu, Sep 9, 2010 at 12:33 AM, Richard O'Keefe <> wrote:
> I see that max/2 and min/2 are now in Erlang.
> You would expect them to satisfy
> [min(X,Y),max(X,Y)] is a permutation of [X,Y]
> max(X,Y) is max(Y,X)
> min(X,Y) is min(Y,X)
> amongst other things.
> When X and Y are distinct terms that are equal as numbers,
> max(X,Y) and min(X,Y) both return X.
> sort3([A,B,C]) ->
> [U,V] = sort2([A,B]),
> [W,Z] = sort2([V,C]),
> [X,Y] = sort2([U,W]),
> sort2([A,B]) ->
> You'd expect this to sort. But it doesn't:
> > sort3:sort3([0,0.0,-0.0]).
> It really is very confusing for it to make a difference
> whether you write max(X, 0) or max(0, X), but in R14A it does.
> The *really* big problem here is that max/2 and min/2 are
> (otherwise) based on *term* comparison, and there *can't* be
> two identical but distinguishable terms.
> In order to get a total order on numbers, it seems necessary
> to rule that
> -0.0 < 0 < 0.0
> and this extends to a general rule that
> if X and Y are numbers that are numerically equal
> but of different types, the floating point one is
> smaller if its sign bit is set, otherwise the
> floating point one is bigger.
> The root of the problem is trying to make one ordering
> serve as both a numeric ordering and a term ordering.
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
More information about the erlang-questions