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 > > >>> > >> > >
