Refactor to allow containers to be directly used as spaces

[zsunberg]

@findmyway Here is my start to a PR related to #8 . I haven't started implementing anything yet, just wrote down my ideas in the README. Let me know what you think.

@mossr, @mykelk, @jamgochiana, feel free to chime in if you have any comments.

[codecov-commenter]

Codecov Report

Merging #9 (9ee91b5) into main (ddfd7ab) will increase coverage by 28.76%.
The diff coverage is 86.90%.

@@             Coverage Diff             @@
##             main       #9       +/-   ##
===========================================
+ Coverage   58.13%   86.90%   +28.76%     
===========================================
  Files           1        3        +2     
  Lines          43       84       +41     
===========================================
+ Hits           25       73       +48     
+ Misses         18       11        -7     

Impacted Files	Coverage Δ
src/product.jl	74.19% <74.19%> (ø)
src/basic.jl	82.35% <82.35%> (+24.21%)	⬆️
src/array.jl	100.00% <100.00%> (ø)

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[findmyway]

Another more common function is clamp

[findmyway]

we may also have eltype implemented

[findmyway]

For Hybrid Spaces, I think we can still use product(s1, s2) to create a hybrid space.

To help access each sub space easily, s1 and s2 may be named spaces and the hybrid space need to support getindex.

[zsunberg]

Ok, I have now added Box. A few things that I would like feedback on:

1. I removed the size parameter from the space styles because this seems like a trait that is orthogonal to continuity, and it only really fully makes sense for array spaces.
2. By default, Box uses StaticArrays even when constructed with builtin arrays.

[findmyway]

Looking at the definition. The Box seems to be a specialized case of a HybridSpace.

I mean it's more or less the same with the result of product(intervals...), except that it provides two extra information on the element:

1. Its element is an Array, which also means we know the eltype and size
2. The bounds are preallocated

Such information are usually environment specific. Some may want a tuple instead of array. Or others do not care about the preallocation feature.

This makes me wonder that, maybe we can just define some traits to recognize some common elemental spaces. We don't need to care too much about the container type (the result type of product). It may be an Array, a Tuple, a NamedTuple, a Dict or whatever. To sample an element from the hybrid space, we simply create a similar container, except that each subspace is replaced with an inner sampling. So that we can still keep the name, type or size info from the container.

In some extreme cases, we can still add a dedicated implementation like Box above if we need the preallocation feature.

With the traits defiend above, I think this issue can be addressed JuliaMath/IntervalSets.jl#66

Note that we may need our customized definition of rand, in, eltype and elsize here to avoid type piracy.

rand(x) = rand(rng, x)
rand(rng, x) = rand(rng, SpaceStyle(x), x)

rand(rng, ::DiscreteSpace, x) = Random.rand(rng, x)
rand(rng, ::ContinuousSpace, x) = ...

rand(rng, ::Any, xs) = map(x -> rand(rng, x), xs)

This means product and HygirdSpace are replaced with more concrete constructors, like tuple and Tuple{DiscreteSpace, ContinuousSpace}.

[zsunberg]

@findmyway , thanks for the comments! This was very helpful in my thinking about product. I agree that we should not care too much about the type that product returns.

Do you agree with this statement that I just added to the README:

The Cartesian product of two spaces a and b can be constructed with c = product(a, b).

The exact form of the resulting space is unspecified and should be considered an implementation detail. The only guarantees are (1) that there will be one unique element of c for every combination of one object from a and one object from b and (2) that the resulting collection conforms to the interface above.

The TupleProductSpace constructor provides a specialized Cartesian product where each element is a tuple, i.e. TupleProductSpace(a, b) has elements of type Tuple{eltype(a), eltype(b)}.

That is my guiding principle for implementing product. I'll try to finish more of the implementation as soon as I get a chance, but it is not finished yet.

The Box seems to be a specialized case of a HybridSpace.

By the way, I was thinking that "hybrid" in HybridSpaceStyle should refer to whether the space is continuous or discrete, i.e. in addition to FiniteSpaceStyle and ContinuousSpaceStyle, we would also have HybridSpaceStyle. So not every product of two spaces should be a HybridSpaceStyle, and in particular Box is always ContinuousSpaceStyle (see the docstring I added for Box for clarification about what it is).

[findmyway]

Yes, I agree.

And thanks for the explanation of HybridSpaceStyle. Now I have a better understanding of hybrid here.

[zsunberg]

Ok, I think this is almost ready to merge, except for a few docstrings and updating the readme. I should be able to add those tomorrow or so. I am very satisfied with how these basics turned out, so I hope everyone agrees that it is a good starting point.

It is currently missing any interface for hybrid continuous-discrete spaces, but we can add that in another chunk. There are also some other issues that I will file later (the two broken tests have raised some questions).

[zsunberg]

OK, I think this is ready to merge. @findmyway feel free to merge, or I will do it tomorrow if no one objects. I'll add issues tomorrow outlining the things that aren't done yet.