Happy Happy Joy Joy (was: On to Hydro)

[Jonathan S. Shapiro]

> But it does exist and have a well defined behavior.  What would you have
> these containers do when asked to store and retrieve NaNs?  Remember, the
> containers don't know about numbers, only things with the properties
needed
> for these containers to hold them.

In general, if a container is to be expected to hold unorderables, then it
must not rely purely on the < operator.  In practice, my suggestion is to
build containers to separate the comparison operator from the objects
compared. I should specify the comparison operator when initializing the
container.  As a trivial example, this lets me build a red-black tree in
which the order is reversed or in which all even numbers sort before all odd
numbers.

Why I would want to do this example I cannot venture to guess. The point is
that there are many possible valid total orderings, and there is no reason
to inherently prefer one to another. Default to the usual < operator if you
like to keep things simple.

If you allow change to the operator at initialization time, then the user
can introduce an operator that arbitrarily assigns a position for NaN in the
collating sequence.

Else, it is an error to store NaN in an ordered collection, because NaN is
outside the ordering.

Last possibility is to simply store NaN outside the tree as a special case,
but this surely does make a mess of iterators.

BTW this is not just an issue for ordered collections. It makes a mess of
sets as well.

shap