An interface package for working with domains as continuous sets of elements.

Examples of domains may be geometric sets such as intervals and triangles, or the complex plane without the negative real line. However, domains are not limited to geometry. A domain could also be a collection of vectors or arrays, such as the set of all orthogonal 3x3 matrices.

Existing types may add the interpretation of being a domain by implementing the domain interface. They gain the ability to interact with other domains.

A domain is a set of elements that is possibly continuous. Continuous sets are defined mathematically, not by an exhaustive list of their elements. In practice membership of the set is defined by the implementation of in. The function call in(x, domain) evaluates to true if the domain contains an element y such that y == x.

In principle, the function in(x, domain) should not throw an exception even if the types seem mathematically nonsensical. In that case, the correct return value is false. This mimicks the behaviour of in for finite sets in Julia:

julia> in(rand(3,3), 1:3)
false

Indeed, a 3x3 matrix is not equal to any of the numbers 1, 2 or 3.

The defining mathematical condition of a continuous set might be satisfied by variables of different types. Still, the interface defines the domaineltype of a domain. It is a valid type for elements of the set.

Functions that generate elements of the domain should generate elements of that type. As a consequence, for finite sets such as an AbstractArray or AbstractSet, the domaineltype agrees with the eltype of that set. For intervals on the real line, the domaineltype might be Float64. When there is no clear candidate the domaineltype might simply be Any.

The domain interface is formally summarised in the following table:

Optional methods include:

Several extensions of this minimal interface are defined in the DomainSets.jl package.

A domain behaves as much as possible like the mathematical set it represents, irrespective of its type. Thus, for example, two domains should be considered equal if their membership functions agree.

It is not always possible to realize this intended behaviour in practice. Indeed it may be difficult to discover automatically whether two domains are equal, especially when their types are different. Still, the principle serves as a design goal.

This package defines the abstract type Domain{T} of continuous sets with domaineltype equal to T. No concrete domain types are defined in this package.

The package also defines the trait DomainStyle. Any type can declare to implement the domain interface by defining

DomainSetsCore.DomainStyle(d::MyDomain) = IsDomain()

Objects of type Number, AbstractArray and AbstractSet are declared to be domains in this package.

With the exception of subtypes of Domain, the set of types implementing the domain interface is not based on a common abstract supertype. Functions that are intended to manipulate domains may simply omit the type of the domain in the function signature. However, functions defined in other packages can not be extended to work for domains, as there is no common type to dispatch on. For that reason this package defines the DomainRef reference.

In the absence of function ownership, the practice of domain references requires active intent both by users and by developers. For a user, passing DomainRef(d) to a function indicates that d is to be treated as a domain. For a developer, the implementation foo(d::DomainRef) may be used to extend the functionality of foo to domains.

The reference DomainRef(d) is not in itself a domain, it is merely a reference. The developer of foo(d::DomainRef) may use domain(d) to access the domain object. More generally, one can implement foo(d::AnyDomain) and use domain(d) in the function definition. In that case the user may invoke foo both indirectly with a domain reference and directly with a concrete subtype of Domain.

An example of this practice is the functionality of union in the DomainSets.jl package. First, the package defines a generic function uniondomain(d1,d2) with no restrictions on the types of d1 and d2. The function returns an object that behaves as the mathematical union of the two arguments. It always interprets the arguments as domains, regardless of their types.

A user wanting to use the standard ∪ syntax for this purpose has to make this intention explicit by writing DomainRef(d1) ∪ DomainRef(d2). The outcome is equivalent to uniondomain(d1, d2), and could be different from what d1 ∪ d2 means in other contexts for the combination of types of d1 and d2. That original behaviour of ∪, quite possibly an error in fact, is not changed.

A developer may make the ∪ syntax more accessible to users as follows. As soon as one of d1 or d2 is a Domain, or a reference to a domain, the call to union can safely be interpreted as the union of domains. Thus, a developer may write:

union(d1::Anydomain, d2) = uniondomain(domain(d1), d2)
union(d1, d2::AnyDomain) = uniondomain(d1, domain(d2))
union(d1::AnyDomain, d2::AnyDomain) = uniondomain(domain(d1),domain(d2))

These definitions are safe in the sense that there is no ambiguity and no possible clash with any existing definition of union(d1,d2) in other packages.

The goal of the domain interface is to make objects from different packages interoperable with minimal interaction between packages and, thus, maximal independence in their development.

Say package A and package B both define a type that can be interpreted as a domain, respectively objectA and objectB. Package C may define the domain interface for objectA using the DomainStyle trait. Package D may similarly define the domain interface for objectB. Package E could load DomainSets and packages C and D. A user of package E can type uniondomain(objectA,objectB).

This construction requires no active collaboration between the developers of packages A, B, C, D and E. They can all be developed independently. Package C relies on package A and on DomainSetsCore. Package D relies on package B and on DomainSetsCore. Package E relies on packages C, D and DomainSets. Packages C, D and E could be developed as package extensions.

Unions and intersections of domains, as well as many other set operations, are implemented generically in the DomainSets.jl package.

Intervals inheriting from the Domain supertype are implemented in IntervalSets.jl.