Don't use totality when defining the (potentially) partial order relation <=

[andreasnoack]

No description provided.

[yuyichao]

I think this should be wrapped in a custom type e.g. struct SortType x end. While no other test should be relying on this, there could be future interference should another test want to do something similar.

[alyst]

Potentially it's 2 comparisons vs 1. What would nanosoldier say?

[andreasnoack]

Potentially it's 2 comparisons vs 1. What would nanosoldier say?

For integers, the generated code is very similar, but why guess when you can just ask

@nanosoldier runbenchmarks(ALL, vs = ":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[StefanKarpinski]

This came up on discourse: https://discourse.julialang.org/t/behavior-of-when-isless-or-is-defined/10114. Looking at it again, I'm wondering what the motivation for the change was. As a general fallback since even if this doesn't cause a performance problem for built-in types, user-defined types may have expensive < and == operations and this always calls them both.

[andreasnoack]

The main motivation was correctness. We state that < is a partial order relation so it seemed a bit odd to use totality here. I think fallbacks should be correct and special cases optimized. The problem is that it is not easy to communicate that users might benefit from defining special <= for their type.

Just thinking out loud a possible alternative: my impression is that the isless/< thing is mainly there because of floats and not because of some deeper order theory considerations. Hence an alternative could be that < should generally be a total order and then clearly state that floating points are special and has a very special isless function that are not supposed to be used for anything but floats.

[StefanKarpinski]

I do agree that < being a partial order is a bit fishy.