Julia: Return index vectors from unique

[ViralBShah]

In Matlab, unique can return optional index vectors, such that one can construct the unique version from the input and vice versa. This is quite handy, and would be nice to have in julia.

http://www.mathworks.com/help/matlab/ref/unique.html

We would probably need the function to be called unique_ind or something, until we have keyword args.

[johnmyleswhite]

This is closely linked to the sortperm and order discussion we had some time back. I've since come to wonder if maybe we should call these sorts of things indunique and indsort to be consistent with indmax and indmin. Kind of ugly names, but it has the benefit of being very consistent.

[ViralBShah]

I prefer the consistency but I would prefer ind to be a suffix making the functions discoverable through auto completion when you press tab.

[StefanKarpinski]

A more composable solution would be better here. Consider the way that sortperm is implemented in terms of applying sort! to an index vector and using the Perm ordering type. The same approach could be used to generically allow using the exact same code for all of these functions and getting back indices instead of the sorted data.

[ViralBShah]

+1 to following a similar approach here as well.

[ViralBShah]

What we need is uniqueperm and then implement unique using that.

[tkelman]

Would uniqueperm return the second output from the Matlab version, or the third output? Both are quite useful in different applications.

Side note, one of the most aggravating things Mathworks ever did IMO was changing the default result ordering of the index outputs from unique from "last match" to "first match." That broke so much of my code...

[StefanKarpinski]

Unique perm wouldn't actually return a permutation, would it?

[tkelman]

ah yeah it's not really the same thing, you get a many-to-few index map and/or a few-to-many index map

[StefanKarpinski]

Let's not call it "perm" then.

[ViralBShah]

Yes, it is not strictly a permutation. Perhaps a selection or something.

[johnmyleswhite]

Hi @DrGar, I'm really glad you're excited about Julia. Unfortunately, posting GPL code in a public forum puts us in legal danger, so I deleted all of the code you posted without reading it. It's a frustrating limitation, but you cannot safely post code to GitHub that you don't own the copyrights to.

[johnmyleswhite]

Don't worry about it. I caught it fast enough that it's not an issue. I just wanted to make sure you understood why I edited your comment.

[nalimilan]

@johnmyleswhite I think your statement is a bit too strong here. Posting the GPL code in public does not create any legal danger. Please don't spread the idea that GPL is something dangerous.

The problem is only about Julia developers being suspected of having read and taken inspiration of this code when writing BSD-licensed code in Julia. (So I agree it's better remove the code from this issue.)

[johnmyleswhite]

@nalimilan: You're right. The correct summary is that posting GPL code in a public forum read by Julia developers is dangerous. Posting GPL code on the internet is harmless. It's only when you post the code somewhere that could be construed as influencing Julia's development that Julia is put in jeopardy.

[StefanKarpinski]

We probably err on the side of being more vigilant than necessary, but we really do not want to accidentally create a situation – or the perception of one – where Julia is violating the copyrights of other projects, GPL or otherwise. If our GitHub repositories are littered with GPL code and even vaguely similar code – written independently – ends up in Julia, that could cause some very unfortunate legal doubts. This is why we're very careful not to post any GPL or proprietary code around here.

[AndyGreenwell]

Please review the PR in #14142 and provide any comments related to implementation (choice of output arguments, efficiency of algorithmic choices, etc.) as well as documentation, and function name. I do still need to add a few tests for automated testing purposes, but there are a few examples of usage in the doc string.

[ViralBShah]

This functionality was further discussed in https://github.com/JuliaLang/julia/pull/15503 implemented in https://github.com/AndyGreenwell/GroupSlices.jl. We can decide to refactor it, or bring into base as necessary.

[tribut]

Given that the package is abandoned and unusable on current Julia, is there any interest to bringing this to Base eventually?

[kmsquire]

@tribut see https://github.com/AndyGreenwell/GroupSlices.jl/pull/9.

[ueliwechsler]

Since GroupSlices does not seem to be maintained. Maybe this functionalities, as other julia implementations of Matlab functions could be added to the package https://github.com/ChrisRackauckas/VectorizedRoutines.jl.

[StefanKarpinski]

The way forward with GroupSlices (Andy seems unresponsive—he probably never looks at GitHub anymore), is to figure out if there's a clean and relatively simple API to be extracted from it that covers the common use cases and then maybe import that into Base or put it into a new package. As I recall, there was a PR to put it into Base but it was just a little too sprawling of an API to be satisfying.

[biona001]

Has anything been done to include the functionalities of GroupSlices.jl into Base?

[StefanKarpinski]

That’s what my last comment was addressing: what was attempted, why it wasn’t satisfactory, and what would need to be done to make forward progress.

[juliohm]

From the discussion in this thread it is not clear what is the current status of this more general interface (i.e. sort/sortperm, unique/uniqueind, ...). Is there a package where the ideas discussed here are being explored?