Overlapping packages

[dlfivefifty]

Here's a list of packages that overlap with this and might influence the design:

https://github.com/JuliaGeometry/GeometryTypes.jl
https://github.com/zenna/AbstractDomains.jl
https://github.com/tpapp/ContinuousTransformations.jl/blob/master/README.md
https://github.com/JuliaReach/LazySets.jl

[daanhb]

There is indeed some overlap with all of these packages, perhaps most with GeometryTypes, yet they are all rather distinct in their purpose too. It begs the question what exactly the purpose of this package is. We are mostly concerned with approximating functions defined on a domain. Clearly, Domains.jl is too general a name for us to register this package.

[dlfivefifty]

They each have their own distinct purpose, but also are representing the same objects, and for simple things this is silly.

Here's a proposal:

1. Make a super package called, say, InfiniteSets.jl that encodes the interface for infinite sets and defines

abstract type InfiniteSet{T} end

but little else. EDIT: Maybe we also want UncountableSet and CountableSet.
2. Make a PR to IntervalSets.jl so that Interval <: InfiniteSet, and move over the open interval code from here to that package.
3. Make a PR to GeometryTypes.jl, and merge the relevant types from here
4. What's left over here would mostly be maps and spaces.

@SimonDanisch any thoughts on this?

[daanhb]

(What type would the Cartesian product of a CountableSet and an UncountableSet be? They are interesting properties, but perhaps not ideal supertypes.)

Looking at GeometryTypes.jl, the AbstractGeometry{N, T} type is just like our EuclideanDomain{N,T} and indeed all it takes is one supertype that could be InfiniteSet{SVector{N,T}}.

The eltype of that would be SVector{N,T}, which clashes with the eltype of AbstractGeometry{N, T} which is T. That can easily be fixed on either end. Still, I'd feel uneasy about enforcing a joint supertype on different packages, when integration in Julia can be done less intrusively by respecting a similar interface without sharing an inheritance tree. (It does look like the simplest option and I'd like to use the meshes.)

[dlfivefifty]

IntervalSets.jl is more crucial, as the whole point of that package was to avoid having multiple definitions of interval.

Having a single abstract type can be very useful, e.g. AbstractArray is a type, not just an interface.

I think I’ll put in a PR moving the more versatile interval defined here to IntervalSets.jl. I’ll include an abstract type InfiniteSet in the PR to initiate the conversation.

[daanhb]

Okay, thanks!

[dlfivefifty]

I'm starting to think you are right about not needing an abstract type at all. There's tons of types floating around that may be useful as a domain but are never going to be <: InfiniteSet:

julia> 1 in 1
true

julia> 1 in Set([1,2,3])
true

What if instead of trying to make everything <: InfiniteSet, I rewrite ApproxFun so domains can be any type? For example, I could have domain(DiracDelta()) === 0, domain(DiracDelta(0)+DiracDelta(2.3)) === Set([0,2.3]), domain(SequenceSpace()) === countfrom(1), etc. This removes the extra layer of wrapping an object in a Domain.

[SimonDanisch]

I'm behind anything, that makes these packages more coherent :) I wouldn't mind depending on a lightweight math package, if that's what needed. But of course, if you figured it out without changing any packages, that does sound simpler!

[dlfivefifty]

I've made the PR

JuliaMath/IntervalSets.jl#26

[dlfivefifty]

Here’s another one

https://github.com/tpapp/ContinuousTransformations.jl/blob/master/README.md

[dlfivefifty]

Here’s another one: https://github.com/JuliaReach/LazySets.jl

[daanhb]

it seems JuliaGeometry is settling on https://github.com/JuliaGeometry/Meshes.jl. There is quite a bit of overlap, but also some similarities.