Semantic of "VoidSet"? about lazysets.jl HOT 6 CLOSED

Can we create this subtype in Reachability instead?
I think it does not make much sense in this library.

from lazysets.jl.

the VoidSet type was introduced as a "useful type" having both behaviors (neutral and absorbing, depending on the operation), and i didn't find any standard name at the moment.. that said, maybe it's time to discuss & do something about this!

the convention is that for any binary set operation op(., .) and any set X:

• op(AbsorbingEelement_op, X) -> AbsorbingElement_op (aka annihilating element, or zero element in some contexts)
• op(NeutralElement_op, X) -> X (aka identity element)

(and similarly when the arguments are swapped)

I think it is a bit confusing, maybe we have to split both concepts?

we can do it by eliminating VoidSet in favor of both EmptySet and ZeroSet, ensuring that:

i think we had this discussion about evaluating the support vectors for these special sets. ATM the support vector of a VoidSet V along direction d is zeros(length(d)) (irrespective of the dimension of V). what do you think for the new types?

from lazysets.jl.

I agree that we use this type in different contexts with different meanings, which is confusing.

We need it to support the application Reachability.jl for two reasons:

1. empty inputs: This is why we need it to be the neutral element of +. I agree that we better use a ZeroSet for this purpose. On the other hand, maybe empty inputs can be represented differently.
2. "useless" dimensions in Cartesian product: This is an annoying issue that there already was a discussion about. It is needed for the projection through a linear map where all array cells have to be written. Hence I do not think that we want to "absorb" here; it is just a specific placeholder with no additional meaning; there is probably no corresponding algebraic concept.

It is worth noting that a VoidSet is currently created at only two places:

• by the user (see 1. and 2. above)
• as the result of a linear map with a zero matrix

I guess we should return a ZeroSet in the second case.

Correspondingly, I do not see the need for an EmptySet at the moment.

Conclusion (personal view):

• Add a ZeroSet type.
• Keep the VoidSet type as a dummy type (maybe rename it? DummySet?).
• Remove the operations on VoidSets because they do not make sense anymore, and give most of them to the ZeroSet where they make sense.
• In Reachability.jl (1.) change empty inputs to ZeroSet and (2.) continue using VoidSet whose meaning should be "I have no meaning" (in contrast, the empty set has a well-known meaning); or solve 2. differently and get rid of VoidSet completely.

from lazysets.jl.

great, that's all we need to know. +1 for DummySet too. in the docs we'll add a table like the one above but explaining these three types. for the alternative solution of missing values, i presume it shall go in the line of using the special type Nullable. but this is subject to change in upcoming julia versions, so IMO we can defer this approach.

from lazysets.jl.

should we have a ZeroSet2D as a subtype HPolygon? in Reachability typically we do
Xhatk = Vector{LazySet}(b), and i was wondering if we can use instead a concrete type.

from lazysets.jl.

see mforets/dummy_set for the part left out of the scope of PR #33

from lazysets.jl.