AxisArrays.jl icon indicating copy to clipboard operation
AxisArrays.jl copied to clipboard

RFC: Re-enable axis checks in constructor

Open mbauman opened this issue 8 years ago • 4 comments
trafficstars

This is a major breaking change. Back before this package was officially registered, these checks were dropped. That means that many of the indexing methods that require sorted vectors are now broken. Enforcing these preconditions in the constructor is, unfortunately, terribly breaking.

I think the (slightly friendlier) alternative here would be to delay the checks until indexing occurs, but the downside there is that for non-range axes, it would require a issorted pass through the data upon every operation. We could defer to the SortedVector type more, but that easily walks us into a type-unstable API. Thoughts?

mbauman avatar Jun 11 '17 08:06 mbauman

Personally I like the idea of running the checks upon construction. Is there really a use case for non-monotonic axes?

timholy avatar Jun 11 '17 10:06 timholy

@timholy yes there is: https://github.com/JuliaArrays/AxisArrays.jl/pull/88

I agree that it's not an optimal code path but when you care about the order of your axis elements and that order is different than a sorting order, it's nice to be able to still use AxisArrays. This only applies in the Categorical case though.

iamed2 avatar Jun 15 '17 15:06 iamed2

Thanks for explaining. Sure, I agree that for categorical axes we might want to allow non-monotonicity, since there isn't really a useful notion of "range" anyway.

timholy avatar Jun 15 '17 17:06 timholy

I rebased #88 on top of this and verified that this doesn't break anything.

My plan is to merge this, but AFTER we figure out #90 since I'm guessing folks would not like to leave a broken package on 0.5, and because making a breaking change like this is a good opportunity to require 0.6 as a minimum.

timholy avatar Jun 23 '17 13:06 timholy