Broadcasting with Set returns an arbitrarily-ordered array

[tkf]

Currently (Julia 1.4-DEV), broadcasting with Set produces a result that relies on iteration order of Set which is not meaningful:

julia> Set([1,2]) .+ Set([3,4])
2-element Array{Int64,1}:
 6
 4

This is due to the fallback to collect in broadcastable definition:

julia/base/broadcast.jl

Line 664 in 9a8b2fd

broadcastable(x) = collect(x)

A sensible definition may be to use set arithmetic (ref: JuliaMath/IntervalSets.jl#55) such that, for example,

op.(set1, set2) == Set([op(x, y) for x in set1, y in set2])

holds. However, given that "join" on indices/keys is proposed as a generalized form of broadcasting #25904 (and special handling for singleton axes), it is not clear how taking "product" for broadcasting with Sets can fit in a bigger picture.

So, as a short-term solution, I propose to forbid broadcasting with Sets which can easily be done by defining broadcastable(::AbstractSet), as done with Dicts:

julia/base/broadcast.jl

Line 665 in 9a8b2fd

broadcastable(::Union{AbstractDict, NamedTuple}) = throw(ArgumentError("broadcasting over dictionaries and `NamedTuple`s is reserved"))

This, of course, requires core devs to decide that this can be treated as a "minor change."

As a longer-term solution, does it make sense to use set arithmetic (which, I suppose, implementable using the style mechanism)? Is there a guiding principle in which it is natural to have "product" for Sets and "join" for associative data structures (including Arrays)?

[dlfivefifty]

I’m in favour of adding a SetStyle for broadcasting sets as set definition, for the reason it’s useful.

As a counterpoint, we sort of already have this with adjoints in the sense if x and y are vectors then

z in f.(x,y’)

if and only if z = f(x[k],y[j]).

[tkf]

As a counterpoint, we sort of already have this with adjoints

I would still treat this a join combined with a special treatment (= broadcasting) of a singleton axis. I added "(and special handling for singleton axes)" in the OP to clarify my point.

[tkf]

If we were to use set arithmetic for broadcasting with sets, I'd argue we should forbid mixing it with arrays. It may be tempting to "promote" arrays or any iterators as sets. However, it would produce different results depending on how you associate operators. For example, in

x :: Set
y :: Vector
z :: Vector

a = x .+ y .+ z  # equivalent to (x .+ y) .+ z
b = x .+ identity(y .+ z)

a and b would have different results. This is very odd given that + is associative.

[dlfivefifty]

I would propose the following:

1. f.(x::Set) should return a Set, so the following is wrong:

julia> x = Set([1,2,3])
Set([2, 3, 1])

julia> exp.(x) # Should return `Set([exp(2),exp(3),exp(1)])`
3-element Array{Float64,1}:
  7.38905609893065 
 20.085536923187668
  2.718281828459045

2. f.(x::Set, 2) should also return a Set
3. f.(x::Set, y::Set), f.(x::Set, y::Vector) etc. should probably just error out

So the rough implementation would be:

struct SetStyle <: BroadcastStyle end
BroadcastStyle(::Type{<:AbstractSet}) = SetStyle()
BroadcastStyle(::SetStyle, ::DefaultArrayStyle{0}) = SetStyle()
BroadcastStyle(::SetStyle, ::SetStyle) =error("Cannot broadcast sets together")
BroadcastStyle(::SetStyle, ::AbstractArrayStyle) = error("Cannot broadcast sets and arrays")

copy(b::Broadcast{SetStyle}) = Set(broadcast(b.f, collect.(b.args)))

[dlfivefifty]

If we really want to argue that f.(x::Set, y::Set) should be defined, we could say that a set behaves like a singleton/scalar and by the definition of broadcast

Singleton and missing dimensions
are expanded to match the extents of the other arguments by virtually
repeating the value

which would essentially be equivalent to set functions. But I think that may be pushing things....

[nalimilan]

See also previous attempt at making this an error at #28491. Not sure why it wasn't merged at the time, since map was deprecated (#26980).

Cc: @mbauman

[tkf]

@nalimilan Thank you. Reviving #28491 seems to be the easiest short-term option.

[dlfivefifty]

The decision to deprecate map seems odd to me, the discussion in #26359 didn't really clarify the problem.

Based on those issues and PRs however the current behaviour is desired. Unfortunately its not very compatible with uncountable sets a la IntervalSets.jl , and its not clear what the analogue of map or broadcast should be....

[tkf]

we could say that a set behaves like a singleton/scalar and by the definition of broadcast

@dlfivefifty I'm thinking that we don't have to follow the current definition strictly if there is a way to generalize the definition to have useful broadcasting with sets. Taking product is certainly useful and probably OK provided that mixing sets with arrays and dicts is an error but I'd be interested in what others think about this.

[dlfivefifty]

I suppose the issue is that there is a desire for broadcast(f, a, ...) to return the same thing as broadcast(f, collect(a), ...). With set products that wouldn't be true. But for other cases I would say it is true, for a certain point of view: e.g., x in broadcast(f, Set([1,2,3]), ...) if and only if x in broadcast(f, [1,2,3], ...) so the two "sets" are the same.

[vtjnash]

iteration order of Set which is not meaningful

It's not defined, but it is meaningful, and so it's not "broken". For example, here's a fairly useless one-liner for doing random things to the values in a dictionary by iterating 3 sets:

julia> D = Dict(1 => 2, 3 => 4, 5 => 6);
julia> Dict(keys(D) .=> tuple.(values(D), values(D) .^ 2))
Dict{Int64,Tuple{Int64,Int64}} with 3 entries:
  3 => (4, 16)
  5 => (6, 36)
  1 => (2, 4)

This also doesn't consider OrderedSet, where the order is defined.

not sure why it wasn't merged at the time, since map was deprecated

map was deprecated because it was doing a special case to make it return a Set which gave surprising results due to the failure to preserve order and count (#26359) and meant associativity was broken for Set. broadcast has currently generally fallen back to iteration (c.f. decision on Ref usage vs. scalarization. Emphasis on currently, since there are open issues proposing to use indexing more heavily.)

f.(x::Set) should return a Set

This is what map used to do, which is why that method was deprecated and not the other.

[tkf]

@vtjnash I think your observation is that current broadcasting definition is useful when the order has some meaning as in the case of KeySet? My main concern is when there is no meaning in the iteration order, as in Set.