Status of uniqueind groupslices etc.

[juliohm]

Based on previous issues, it is not clear if there are plans to incorporate the implementation of groupslices from GroupSlices.jl into Base. This function is quite common when one needs to just find the unique columns in a large array for further processing.

Past discussions include:

• Proposal for function uniqueslices #14142
• Replacement implementation for groupslices and associated functions #15503
• Return index vectors from unique #1845

The current registered version of GroupSlices.jl in Julia 1.x is a fork from the original author's version. Any chance this functionality could be part of Julia v1.5?

[StefanKarpinski]

Seems overly complex to include. What wrong with letting it be a package?

[juliohm]

The code hosted under the name groupslices in GroupSlices.jl is a copy of the function _unique_dims in Base plus a few lines to return the indices of the unique entries already computed in the algorithm as opposed to the unique entries themselves. It would be nice to have this feature built-in and well-maintained. Perhaps a keyword argument to return indices vs. uniques? Or something on the lines of findmin vs. argmin.

[StefanKarpinski]

built-in and well-maintained

These are at odds with each other. You've expressed on various occasions that you want more things to go into the stdlibs or Base in order to be better maintained, and while I appreciate the vote of confidence implied by being volunteered to maintain more code, frankly Base is where complex APIs like this go to die. If we put this in Base, they we would literally never touch it again except to fix clear bugs since anything else would change the API in some way and is therefore not allowed. There was a reason this didn't get merged into Base after all those discussions: the best API was very non-obvious. It is much better for this to live in an external package and be able to evolve and improve its API. Perhaps moving it to @JuliaCollections would be good though.

[juliohm]

I agree. I just thought that in this specific case, almost all the code is already there in Base and one would just need to provide a keyword argument to return the indices. Wouldn't that be reasonable? I also agree that a more general package could be started in @JuliaCollections, but since currently we don't have an example package that incorporates this single feature discussed here, I think it may still make sense to add this keyword argument or some other variant name like uniqueind. What do you think? It is basically exposing some internal code that is already in Base.

[StefanKarpinski]

It is basically exposing some internal code that is already in Base.

This is the problem—that internal code becomes a huge boat anchor as soon as you expose it. I don't want to do that. I'd much rather duplicate some code and/or have an external package depend on some internal detail and then have other code depend on that, so that if we change the internal thing in Julia there's only one place to fix instead of many of them.

[juliohm]

Will close the issue then, thanks for clarifying 👍

I've ended up copying/pasting the code in GroupSlices.jl in my own package to avoid a dependency on a package with a single function.

[juliohm]

I've closed this issue but I still think the current state of affairs is suboptimal. Every time I need this "unique indices" functionality I end up copying/pasting that function from GroupSlices.jl in multiple places because depending on a tiny package with a single function is not ideal.