The issetequal docstring says that issetequal(a, b) is equivalent to a ⊆ b && b ⊆ a, but I found this isn’t the case when there are duplicate elements. In v1.0.0:
julia> a = [1,2,3];
julia> b = [1,1,2,3];
julia> a ⊆ b && b ⊆ a
true
julia> issetequal(a, b)
false
Is this the intended behavior?
Good catch. The implementation assumes there are no duplicates, as it is just:
issetequal(l, r) = length(l) == length(r) && l ⊆ r
Can you file an issue on GitHub? At the very least the documentation should mention this
The name of the function, issetequal(a,b) kind of indicates that a and b should be sets. Indeed,
julia> a = Set([1,2,3])
Set([2, 3, 1])
julia> b = Set([1,1,2,3])
Set([2, 3, 1])
julia> issetequal(a,b)
true
So an alternative question is: should the function respond with true/false with other argument types, e.g., vectors (in original question), tuples, etc.? Or should the function give an error message if the arguments are not sets?
My understanding was that it treats other collections implicitly as sets (eg equivalent to calling Set(...) on the arguments).
But looking at the docs I am not sure why I think this, perhaps it could be documented? (or I read this ages ago and I just cannot find it 
)
There are quite a few set operations that work correctly for non-sets, eg setdiff, union, intersect. So it’s not unreasonable to expect this to work correctly as well, especially given that it doesn’t throw a no method error.
If the arguments are sets, should not issetequal(a,b) be the same as a==b? Thus, if it was restricted to sets, issetequal would be useless…
Perhaps. But do you then say that issetequal(a,b) == isequal(Set(a),Set(b)) (or rather: should be like that)? If so, perhaps issetequal() is not an essential function?
I don’t know what essential means in this context, but building a Set may be a cost that one can avoid.
That is, of course, a valid argument.