For MeasureTheory.jl, we need a nice way to represent some domains, like

continuous sets ℝ, ℝ₊, and 𝕀 (unit interval)

Infinite discrete sets ℤ, ℤ₊, ℤ₀₊

Also finite sets a:b, but that’s easier

Eventually we’ll need to be able to represent measures on manifolds, either as in Manifolds.jl or as in Bijectors.jl or TransformVariables.jl. That’s further down the line, but I want to be sure to set things up in a way that doesn’t lead to headaches going forward.

To be a little more specific, we define most measures in terms of a density over some base measure. The most common of these is Lebesgue(X) for some X.

We’ve been using Lebesgue(Real) for a while, but…

The type hierarchy approach is kind of rigid, for example getting in the way of things like symbolic evaluation

There’s not a clean way to have subsets like ℝ₊ and 𝕀.

We could build ℝ, ℝ₊, and 𝕀 as part of MeasureTheory, but I want to be sure we can play nice with other packages, especially Manifolds.jl and the JuliaApproximation ecosystem.

What’s a good approach to keep consistency with these packages?

We currently have a little different approach, maybe call it implicitly. If the points we have on a manifolds (or tangent vectors at a point) are represented in some embedding (imagine the sphere of unit vectors in R2 embedded in R3) we use check_manifold_point(M,p)(or p ∈ M for short) to check whether p is a point on m in Manifolds.jl.

But sure both @mateuszbaran and @sethaxen can also help how to represent domains for measures. I would really like to have that in a unified way .

I’m rather fuzzy about these details, since I am just a physicist , but in QuasiArrays.jl, we use the axes machinery to indicate that one or more axes of a quasi-array span a continuous interval using IntervalSets.jl [on the real line; I’m also interested in getting this to work in the complex plane]. @dlfivefifty would know more about the details.

I guess my big concern was just working in terms of one ecosystem or the other, and limiting compatibility with the other or one down the road. But maybe these primitives are simple enough that it’s not really an issue.

Is there actually any fundamental incompatibility between Manifolds.jl and Bijectors.jl? I haven’t looked too closely at the interface of Bijectors.jl but it looks like we could relatively easily make a bridge package between these two, so that distributions on manifolds and their transformations could be defined. Manifolds.jl actually needs some updates regarding distributions (currently it builds upon only Distributions.jl) so I think building distributions on manifolds upon Bijectors.jl may be a good way forward. In any case please don’t feel restricted by what Manifolds.jl does right now in terms of distributions.

Ooo, this is interesting! I played around with this a bit some time ago because I wanted a nice way to handle constraints and whatnot in Bijectors.jl, e.g. you specify domain and codomain and then we return the corresponding bijector. On my “wanted feature”-list indeed was compatibility with Manifolds.jl. I remember running into some issues that resulted in me just going “Ughh, another time maybe”; don’t recall what that was though.

DomainSets.jl looks pretty sick.

Is there actually any fundamental incompatibility between Manifolds.jl and Bijectors.jl? I haven’t looked too closely at the interface of Bijectors.jl but it looks like we could relatively easily make a bridge package between these two, so that distributions on manifolds and their transformations could be defined.

Regarding this in particular, I’d love to chat more:) I could also see a package which bridges the two, but if we could do it “properly” through MeasureTheory.jl, that would of course be preferable. I’ll have a look at it and maybe just make a separate issue for this on Bijectors.jl where we can chat about a “bridge package” while MeasureTheory.jl is still being hammered out.

EDIT: Regarding the last topic, I remember @setaxen had an issue in Bijectors.jl on certain distributions he thought could easily be implemented in Bijectors.jl if we dropped the requirement for bijectivity. At the time we weren’t entirely certain about the design, and so the issue just turned into a discussion about whether or not this was a good idea. I’d be more open to such now that Bijectors.jl is rather stable:)

The most pressing thing right now for MeasureTheory.jl is a simple, clean representation for some common spaces. Right now I’m thinking something like this:

Ideally, these could be provided in a separate package, and used for the basis of both DomainSets and Manifolds. But it should be ok anyway, since most of this is at the type level and is easy enough to manipulate.

The point of this is to be able to say things like

@measure Beta(α, β) ≃ Lebesgue(𝕀)

This means

Beta is an AbstractMeasure

The default parameterization is in terms of α and β. So e.g., Beta(2.0, 3.0) is converted to Beta(α=2.0, β=3.0)

basemeasure(::Beta) = Lebesgue(𝕀)

It’s an equivalent measure to Lebesgue on the unit interval, meaning it’s absolutely continuous (≪) wrt Lebesgue and vice-versa