DomainSetsCore.jl package?

[daanhb]

I believe there was a suggestion at some point to create a new package that would define a Domain type. I can't seem to find the comment. Anyway, I think at some point it will be a good way forward, hence this issue. No rush I guess.

Possible definitions may be:
1.

abstract type Domain end

abstract type AbstractDomain end

abstract type Domain{T} <: AbstractDomain end

Base.eltype(::Type{<:Domain{T}}) where T = T

abstract type Domain{T} end

Base.eltype(::Type{<:Domain{T}}) where T = T

These possibilities of course relate to the discussion of whether or not a domain has an eltype.

My current personal stance is that domains represent discrete or continuous sets (which sets them apart from existing sets in Julia), that sets are expected to have elements, and that it is useful to convey information about that. However, we could ensure that T=Any is a perfectly acceptable option, as it is in Julia for arrays:

julia> ["1", 2]
2-element Vector{Any}:
  "1"
 2

and for dictionaries:

julia> Dict("2"=>1, 2 => "3")
Dict{Any, Any} with 2 entries:
  2   => "3"
  "2" => 1

and for sets:

julia> Set([1, "2"])
Set{Any} with 2 elements:
  "2"
  1

In that case, for simplicity I'd favour the third option above.

[hyrodium]

I believe there was a suggestion at some point to create a new package that would define a Domain type. I can't seem to find the comment.

x-ref: #106 (comment) #126 (comment)

[dlfivefifty]

Probably make it plural a la ChainRulesCore.jl and StaticArrays.jl (either DomainSetsCore.jl or DomainsCore.jl)

[dlfivefifty]

But if you are doing that I'd propose going all in the interface as opposed to an abstract type. E.g.

module DomainCore

abstract type DomainStyle end

"""
    IsDomain()

indicates it satisfies the domain interface, i.e. supports `in`.
"""
struct IsDomain <: DomainStyle end
struct NotDomain <: DomainStyle end

DomainStyle(::Type) = NotDomain()
DomainStyle(::Type{<:AbstractSet}) = IsDomain()
DomainStyle(::Type{<:AbstrctArray}) = IsDomain()

end

[daanhb]

Are there any other packages doing that?
I agree it would be the most flexible approach, but it seems like we may have to explore quite a bit of new ground for this to work.

[daanhb]

Probably make it plural a la ChainRulesCore.jl and StaticArrays.jl (either DomainSetsCore.jl or DomainsCore.jl)

DomainSetsCore.jl seems to be the most common suggestion (DomainsCore reads a bit like DomainScore)

[daanhb]

I'm warming up to the idea of an interface. Looks like it might work and solve several issues. (And perhaps create new ones, but we'll see.)

[zsunberg]

I am totally on board for an interface for continuous sets and would like to contribute! I was just in a meeting with @mykelk and @jamgochiana where we were talking about the need for this.

What if we just called it SetInterface.jl? That is a bit presumptuous, but if we got enough people on board, this could be extremely helpful!!

[daanhb]

This seems like an example of a package providing an interface not unlike what is proposed above: https://github.com/JuliaMath/DensityInterface.jl
(edit: to be clear, the interface is for a different field, not for continuous sets)

[daanhb]

Update: see here for a possible DomainSetsCore.jl package.

[daanhb]

Update: for experimentation I've made a first working version of DomainSetsCore.jl along with IntervalSets.jl and DomainSets.jl. Aiming for interfaces rather than inheritance, intervals in IntervalSets on this branch no longer inherit from Domain. The package is independent of DomainSets and DomainSetsCore. (I don't think this is a good idea, see below.)

I've adapted DomainSets to make it interoperate with sets that implement the domain interface, but that do not necessarily inherit from Domain. See this branch. The change is fairly massive, but less so than I was expecting. A lot had been done already.

Long story short: it can be made to work, but it is a bit painful and ugly here and there.

The changes to DomainSets are fine and may be worth it. Working on the library becomes more complicated, but that is invisible to an end-user. However, working with intervals changes in a way that requires user cooperation.

Here is an example to illustrate the technical solution and the implications. We essentially want to group types outside of the type hierarchy, namely the group of all types that implement the domain interface. Such grouping is pretty much the definition of traits, but Julia does not support traits and existing trait packages aren't widely used. So we have to do traits manually.

There are two ways we can indicate that an object should be treated as a domain, rather than interpreted based on its type. I'll use the union of two domains as an example. Since the domain-property is not based on type, it is not enough to define union(d1::Domain, d2::Domain). We can not change the untyped fallback definition of union(d1,d2) to check for a domain property either, as somebody else might want to do that for other traits. The two ways out are:

1. We change the function name. The method uniondomain indicates that its arguments will be interpreted as domains, regardless of their type:

julia> uniondomain(0..1, 2..3.0)
(0.0 .. 1.0) ∪ (2.0 .. 3.0)

2. We use a wrapper type. The notation AsDomain(d) means that d should be interpreted as a domain. Now we can use union:

julia> AsDomain(0..1) ∪ AsDomain(2..3.0)
(0.0 .. 1.0) ∪ (2.0 .. 3.0)

I've implemented both. The latter is what I mean by user cooperation. The user has to explicitly indicate that the interval is to be treated as a domain if he or she wants to use standard syntax. Otherwise the result is an error:

julia> (0..1) ∪ (2..3.0)
ERROR: ArgumentError: Cannot construct union of disjoint sets.

In order to get the test suite of DomainSets passing, I've had to sprinkle AsDomain's in many places. For the internals of DomainSets, it is sufficient to anticipate arguments of type Domain or of type AsDomain, the latter being just a reference to a domain (of any type).

The changes to DomainSets are an improvement, I think, though it requires some knowledge of what's going on before one can use it. For example, we can mix intervals of different types:

julia> using IntervalSets, Intervals

julia> d1 = 0..1
0 .. 1

julia> typeof(d1)
ClosedInterval{Int64} (alias for IntervalSets.Interval{:closed, :closed, Int64})

julia> d2 = Intervals.Interval(2.0, 3.0)
Intervals.Interval{Float64, Closed, Closed}(2.0, 3.0)

julia> d = AsDomain(d1) ∪ d2
(0.0 .. 1.0) ∪ [2.0 .. 3.0]

julia> 0.5 ∈ d
true

julia> 2.5 ∈ d
true

julia> 1.5 ∈ d
false

The union of the two domains even promoted the eltype of d1 to Float64.

@dlfivefifty @hyrodium @zsunberg

My suggestion for now: we use DomainSetsCore in the current form, implement the corresponding changes in DomainSets.jl, but keep the intervals of IntervalSets inheriting from Domain{T}. Strictly speaking that might not even be a breaking change. It would be a status quo for both packages involved, and a net benefit for interoperability. I think more experiments are needed for fallback downstream before changing the inheritance tree or removing the T type parameter.