Move `support` and `insupport` here from Distributions

[cscherrer]

I'd like to have access to these for MeasureBase, and depending on Distributions seems backwards. Any thoughts on moving these to DensityInterface? Anything else that should move here from Distributions?

[devmotion]

support in Distributions is of quite limited use since it can't deal with more advanced domains and e.g. countably infinite sets. It doesn't work properly currently and hence I can't recommend working with support and think these issues should be solved in Distributions first before moving these functions somewhere else. There are some issues about it and there exist some suggestions (eg depending on DomainSets) but maybe for a start it is easiest to just improve the current type system for supports in Distributions as suggested in some old issue - this would also not add any additional dependencies.

[oschulz]

Well I would say these support and insupports would ideally deserve an abstract interface package of their own, as support is such a fundamental concept, beyond densities (this could link to JuliaMath/InverseFunctions.jl#8, for example). But I wouldn't be opposed to "lifting" them into DensityInterface as a first step - it's at least a more lightweight owner than Distributions.

[oschulz]

support in Distributions is of quite limited use

Hm, yes, that's true. But maybe insupport? But yes, it's tricky to get right, and to do it right we should then involve other people working on expressing support in the ecosystem.

[oschulz]

Hm - @cscherrer , for a measure, as there's not just one density, is asking about the support actually the right question? Is it about whether a point is a member of the set that the measure is defined on, or whether the point contributes mass?

[oschulz]

Also, if we go with the plan that Distributions will depend on MeasureBase, then MeasureBase could own support and insupport, it wouldn't need to move all the way up into DensityInterface.

[cscherrer]

It's definitely tricky for embeddings, usually in those cases we're in the support by construction, or sometimes we project to it.

DomainSets is very cool, we've looked into it for MeasureTheory. My biggest concerns had been the nonstandard Simplex implementaiton (https://github.com/JuliaApproximation/DomainSets.jl/issues/102) and the use of StaticArrays which don't scale (https://github.com/JuliaApproximation/DomainSets.jl/issues/91). It looks very likely both of these can be fixed or worked around very soon. Honestly, for the StaticArrays one I still need to understand it better.

[cscherrer]

Hm - @cscherrer , for a measure, as there's not just one density, is asking about the support actually the right question? Is it about whether a point is a member of the set that the measure is defined on, or whether the point contributes mass?

Oops, I had missed this. We have some guarantees about (local) absolute continuity by construction. I think we really should have

insupport(d, x) == logdensityof(d, x) > -Inf

In some cases this might be tricky to make efficient, so it could be useful to also have an overapproximation of the support, with a guarantee that values in that overapproximation won't lead to errors (no logs of negatives, etc)

[oschulz]

Maybe in that case insupport would be too generic a term when applied to a measure anyway, if we mean "within-density-support"?

[devmotion]

I think we really should have

insupport(d, x) == logdensityof(d, x) > -Inf

I don't think this would useful since it would lead to strange results (that even depend on the type of x):

julia> logdensityof(Normal(0, 1e-100), 1e100)
-Inf

julia> logdensityof(Normal(0, 1f-10), 1f10)
-Inf32

julia> logdensityof(Normal(0, 1e-10), 1e10)
-5.0e39

[cscherrer]

Good point @devmotion , I think it's pretty clear we don't want to be considered outside the support due to underflow.