Closed dlfivefifty closed 7 months ago
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.
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:
abstract type InfiniteSet{T} end
but little else. EDIT: Maybe we also want UncountableSet
and CountableSet
.
Interval <: InfiniteSet
, and move over the open interval code from here to that package.@SimonDanisch any thoughts on this?
(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.)
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.
Okay, thanks!
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
.
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!
I've made the PR
Here’s another one
https://github.com/tpapp/ContinuousTransformations.jl/blob/master/README.md
Here’s another one: https://github.com/JuliaReach/LazySets.jl
it seems JuliaGeometry is settling on https://github.com/JuliaGeometry/Meshes.jl. There is quite a bit of overlap, but also some similarities.
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