Don't Rename to InfiniteSets.jl about domainsets.jl HOT 5 CLOSED

I agree with a name-change to somethingSet, if this package does end up implementing Base.Set, as in:
https://docs.julialang.org/en/stable/stdlib/collections/#Base.Set
and
https://github.com/JuliaLang/julia/blob/9d11f62bcb124327831206089967f93020e84200/base/set.jl

However, I think something like EuclideanSet might be a better name, since all of the types in this package represent subsets of a Euclidean space. An infinite set could be something much more general, like the set of all words from the Roman alphabet, or the set of all binary trees.

from domainsets.jl.

Hmm, I suppose would imply having everything <: AbstractSet.

This actually goes against my other leaning, is that anything that supports in is a valid domain: that is, no need to use Point(1.0) since 1.0 itself supports in:

julia> 1.0 in 1.0
true

So maybe leave it as Domains and define the "domain interface" as implementation of in?

from domainsets.jl.

See related discussion in SciML/PDERoadmap#4 (comment)

@jlperla @ChrisRackauckas any updates on how you you decided to design "domain"s?

from domainsets.jl.

Not yet. I need to discuss some things with the Modia.jl people.

from domainsets.jl.

Some thoughts on a domain interface:

1. DomainError gives precedence for what Domain means in Julia
2. domain should be to Function what axes is to AbstractArray and keys is to AbstractDict

More details:

(Hypothetical) Axes interface for AbstractArray

At the moment, axes(::AbstractArray) is required to return an AbstractUnitRange, but one could imagine this restriction being relaxed to support fractional indices (e.g., finite-differences), or even continuous indices (e.g., continuum limits). In this case, the "axes interfaces" would probably only require the following:

• A[k...] does not throw a BoundsError if and only ifk in zip(axes(A)...)

Keys interface for AbstractDict

In this hypothetical world where arrays support even more general indices, the difference between an array and a dictionary becomes subtle, in fact, one could propose that AbstractDict{I,T} <: AbstractVector{T}. But in any case, the current behaviour satisfies the following:

• A[k] does not throw a KeyError if and only if k in keys(A)

Proposed domains interface for Function

Now we get to Functions, and the proposal is that domain plays the same role as axes and keys. Here's a subtlety: we want to work with functions but domain is only well-defined for methods. For example, the domain of log has different behaviour depending on the argument type:

1. for log(x::Float64) it is (0.0,Inf),
2. for log(x::Int) it is 1:∞
3. for log(x::Complex{Float64}) it is ComplexPlane()

So I'd propose the following:

• f(x...) does not throw a DomainError if and only if x in domain(f, typeof(x))

What about Fun?

Unlike functions like log, Funs currently have a default ambient type. For example Fun(exp, 1..2) lives naturally in Float64. This might be true for other functions, so we could have the default implementation domain(f) = domain(f, ambienttype(f)) where functions with ambient types override ambienttype.

I don't think the classical special functions exp, log, have a natural ambient type (who's to say domain(exp) should be RealLine{Float64}() and not ComplexPlane{Float64}() or even SquareMatrices{Float64}()), so they would just throw an error.

from domainsets.jl.