Any algorithm for producing unique permutations obviously needs to rely on some notion of element equality. That could be user-defined but default to something sane. I suspect that isequal or === would be good choices; == is not a good choice since NaN is not even == to itself.
On Mon, Nov 23, 2015 at 8:03 AM, Tamas Papp <tkp...@gmail.com> wrote: > IMO permutations should maintain the following invariant: for any vector > v, > > isequal(map(i -> getindex(v,i), collect(permutations(1:length(v)))), > collect(permutations(v))) > > Bringing equality and uniqueness into the issue disposes of this > property, which is desirable in many applications. > > Best, > > Tamas > > On Mon, Nov 23 2015, Glen O <gjo1...@gmail.com> wrote: > > > Logically, the same definition being used by "unique" would be applied, > > unless specified otherwise (which should also be available for unique - > > it's silly that you can't specify the level of inequality necessary for > > uniqueness). > > > > Incidentally, in the example you gave, unique gives > > [0.0,-0.0,NaN,Foo(),Bar(NaN),Bar(NaN)] > > > > On Monday, 23 November 2015 05:08:12 UTC+10, Tamas Papp wrote: > >> > >> Also, "unique" permutations require a notion of equality, and which is > >> hard to define in general (classic essay is [1], about Common Lisp, > >> but applies to Julia mutatis mutandis). At least Julia has bits types > >> for numbers, which makes life a bit easier. > >> > >> Whether one picks is, isequal, or == for comparison, it easy to come up > >> with cases which go against user expectations (at least for some > >> users). For example, given > >> > >> type Foo end > >> type Bar x end > >> > >> what should be the unique permutations of > >> > >> [0.0,-0.0,NaN,NaN,Foo(),Foo(),Bar(NaN),Bar(NaN)] > >> > >> ? > >> > >> Best, > >> > >> Tamas > >> > >> [1] http://www.nhplace.com/kent/PS/EQUAL.html > >> > >> On Sun, Nov 22 2015, Ratan Sur <ratan...@gmail.com <javascript:>> > wrote: > >> > >> > I think julia more than other languages has a tendency to stick with > >> > mathematical consistency over some user preferences, which is good. > For > >> > that reason, I would be in favor of permutations remaining as is but > >> having > >> > multiset_permutations renamed to something more intuitive, like > >> > uniqueperms, or unique_permutations. > >> > > >> > On Sun, Nov 22, 2015 at 2:16 AM Glen O <gjo...@gmail.com > <javascript:>> > >> wrote: > >> > > >> >> While it is true that an interpretation of arrays is multisets, > that's > >> not > >> >> the only reasonable interpretation. And while the strict > interpretation > >> of > >> >> "permutations" suggests it should include duplicates, you have to > >> consider > >> >> what the user would most likely expect it to do. Most would think > that > >> a > >> >> list of the permutations would include unique permutations only. > >> >> > >> >> So perhaps both functionalities should be available in the same > >> function > >> >> with a keyword argument. At the very least, the description of the > >> function > >> >> should directly inform the user that it's going to give duplicate > >> >> permutations if the array contains repeat elements. > >> >> > >> >> On Saturday, 21 November 2015 04:24:51 UTC+10, Jiahao Chen wrote: > >> >>> > >> >>> The current behavior of permutations is correct and should not be > >> >>> changed. Combinatorially, arrays are multisets, not sets, since they > >> allow > >> >>> for duplicate entries, so it is correct to produce what look like > >> identical > >> >>> permutations. The redundancy is important for operations that can be > >> >>> expressed as sums over all permutations. > >> >>> > >> >>> Combinatorics.jl currently provides multiset_permutations for > >> generating > >> >>> only distinct permutations: > >> >>> > >> >>> > >> >>> > >> > https://github.com/JuliaLang/Combinatorics.jl/blob/3c08c9af9ebeaa54589e939c0cf2e652ef4ca6a0/test/permutations.jl#L24-L25 > >> >>> > >> >> > >> > >> >
