make sure interpreted and compiled orderings agree

[cseed]

Builds on: #4869

ExtendedOrdering on rows and containers now matches CodeOrdering by using lt instead of compare in lt, etc.

FYI @tpoterba since this could potentially (e.g. comparing arrays with nans) cause a user-visible change in behavior.

[tpoterba]

I'm fine with this.

[tpoterba]

do you have an example of something that changed?

[tpoterba]

(would like to include that in patch notes)

[cseed]

Consider [NaN] < [0.0]. Before, array compare used compare (the total ordering) to compare elements, and would have returned true or false. Now, it always returns false (since NaN compare false to everything), and something similar for -0.0, and rows, sets and maps. I think that's it.

[cseed]

But only when ExtendedOrdering is used, which I think is pretty rare, now, just in Interpret (so eval, top-level expressions) and aggregators.

[tpoterba]

Is this technically a file format change? If I have something keyed by array<float64>, we've just invalidated the ordering.

[catoverdrive]

Ordering should always use compare, I think

[tpoterba]

er, the interpreter isn't used for file formats. carry on

[cseed]

Yes, what @catoverdrive said, so the file formats should be OK.

[catoverdrive]

rebase?

[catoverdrive]

I feel like these should maybe be using compare, no? otherwise (I think) we can get things like

hull([-0.0, 1.0], [0.0, 1.0]) = [0.0, 1.0]
hull([0.0, 1.0], [-0.0, 1.0]) = [-0.0, 1.0]

[cseed]

Yeah. In fact, I think Interval should use compare (total ordering) everywhere. That matches the old behavior, too. Fixed.

addressed