challenge: implement the max function

[Donth Ave]

Andrei Alexandrescu wrote: 

> Notice that the .max tests are guarded by if (std.is_num!(T1) && 
> std.is_num(T2)). So that code is only executed for numerical
> types. I've omitted the implementation of std.is_num because it is
> trivial. 
If it is trivial to implement, then I do not understand how. Please explain how std.is_num is able to determine whether some class represents a number type. The only way I can think of is the requirement to have some predicate isNum defined in every class.

But even if std.is_num is implemented: you haven't restricted the challenge to types who repesent sets of numbers which have a maximum. The easiest set of numbers, the natural numbers, does not have a maximum. So how will someone define a maximum on this type?

Although you might want to say "pure academic" one can implement such an infinite type by storing a concrete value on an unbounded sequence of BlueRays/DVDs/CDs and work on the values by using three ore more burners and readers.    

> In the numeric case, things are more interesting. With max it
> turns out that today's implicit numeric conversions do exactly as
> needed.
I doubt that. How can two different numerical classes be implicitely converted to each other?

> Maximum implies some kind of ordering. To me using > versus <= is
> more of an academic point than a practical one. Once you have one,
> you can reasonably define all others.
Please check to know the differences between "monotonic ordering" and "strict monotonic ordering" of which you are writing and "total ordering" or "partial ordering" which I am writing of. To compute a maximum only a "partial ordering" is required.

A set of arguments that is only partially ordered may not have a maximum---and because in the challenge there is no specification for this case, it would be okay to raise an exception as the sample solution does.

But if there is a maximum the sample solution will fail to return it.

To see that look at a type which has three elements LEFT, RIGHT and TOP. Where LEFT and RIGHT are not ordered but both are less than TOP.

Calling "max( LEFT, RIGHT, TOP)" with your implementation will result in an exception raised on comparing LEFT with RIGHT, although the return value should be TOP.


> Lazy is never deduced, and it was not part of the requirement.
It was not excluded.

> But the case max(obj,4) could be handled better. In that case, the
> built-in should be explicitly converted to the object type.

... and it will fail if obj does not have such converter. The same holds for a call min( o1, o2), where o1 and o2 are from different classes. And to have such converters was not given in the challenge.

Sorrily you failed to see the main point: if one puts a conversion into the template that conversion will destroy the otherwise possible lvalueness. If one does not put a conversion into the template one and in case of mixed types one has to prefix every access to the value returned from max with a cast. But according to the challenge that is okay, because there is no requirement for not casting.
--
Anonymity is not a Crime