Support for non-static dimensionality?

[oschulz]

For higher-dimensional problems it would be great to have support for non-static dimensionality and argument types like Vector in addition to SVector. E.g. a ProductDomain based on AbstractVector{IntervalSet} should allow for in(x::AbstractVector, d::ProductDomain). N-dimensional hyper-spheres with N not fixed at compile time would also come on very handy.

[daanhb]

That sounds doable. Currently the spheres are hardcoded to be EuclideanDomain, but ProductDomain already mostly works more generically. If you comment out the two checks in the inner constructor here, then you get this behaviour:

julia> using DomainSets

julia> b = 0..1.0
0.0..1.0

julia> domains = [b for i in 1:10]
10-element Array{Interval{:closed,:closed,Float64},1}:
 0.0..1.0
 0.0..1.0
 0.0..1.0
 0.0..1.0
 0.0..1.0
 0.0..1.0
 0.0..1.0
 0.0..1.0
 0.0..1.0
 0.0..1.0

julia> p = DomainSets.ProductDomain{typeof(domains),Vector{Float64},Vector{Float64}}(domains)
0.0..1.0 x 0.0..1.0 x 0.0..1.0 x 0.0..1.0 x 0.0..1.0 x 0.0..1.0 x 0.0..1.0 x 0.0..1.0 x 0.0..1.0 x 0.0..1.0

julia> rand(10) ∈ p
true

julia> 2*rand(10) ∈ p
false

(The final test will succeed with some probability.) I've invoked the constructor explicitly here. It would be a matter of modifying the computation of the element types, plus finding a nicer way of invoking the constructor. Perhaps when invoked with an array of domains, a ProductDomain could use array's as type. When invoked with an argument list of domains, it could be a tuple.

It is similar with the spheres: there could be an AbstractHyperSphere{T} <: Domain{T} and an AbstractEuclideanHyperSphere{N,T} <: AbstractHyperSphere{SVector{N,T}}. And some syntax for constructing them. Care to look at it?

[oschulz]

Maybe, yes. I have something similar in BAT.jl, for boundaries for likelihoods and priors and I was looking for a solution that's more generic. DomainSets may be a great fit.

[daanhb]

Cool, I hope using DomainSets works out. You suggested an interesting generalization that fits well in the package, because the whole aim is to be general and avoid repetition in other packages. I will try to get to this particular issue soon, and update here.

[oschulz]

Great, thanks! I think this could be a valuable building block for statistics/fitting/optimization/etc. applications, to avoid redundant functionality across packages.

[daanhb]

Working on it in #55. It motivated working on some other issues as well, and #55 will perhaps take some time and additional effort before we can merge it I'm afraid.

[oschulz]

Thanks, @daanhb! I'l try to pitch in at some point, I'll try to get a clearer idea on requirements - and how to represent them more cleanly than I do at the moment - first, for such applications (statistics/fitting/optimization/...).

[daanhb]

The changes have been merged into version 0.3. The README is updated with a few examples of basic usage. Issues are to be expected - please report! :-)

[oschulz]

Thanks a lot - will do!