More Spaces

[ParadaCarleton]

Hi, would you be interested in extending this package to cover non-euclidean spaces by working with manifolds from Manifolds.jl? The use case for this is Distributions.jl, which has lots of distributions with non-euclidean support--most common are the probability simplex and constrained matrices.

[daanhb]

Ideally, nothing in DomainSets assumes an euclidean space and both packages Just Work (TM) together. Practice might be different, though :-) Do you have an idea of what is missing or what should be added to do useful things with manifolds and domains? If there are any use cases then, yes, I'd like to hear about them.

[ParadaCarleton]

@sethaxen will know substantially more about this than me, I think. At the moment, I'm trying to get the maintainers for all of these conceptually-similar packages together in one room. In short, I'd like a single interface for specifying the domains of functions (or supports of distributions), including functions/distributions defined on non-Euclidean spaces, so we can easily define operators that map elements of one space onto another. Especially useful would be transformations to map arbitrary sets to R^n.

[sethaxen]

I don't really have the bandwidth to think about this right now, but I'll tag the other Manifolds devs @kellertuer and @mateuszbaran

[kellertuer]

If I can help somewhere, let me know, though this semester I have a bit of a workload.

For this package I am not 100% what would be required, but probably it should be enough to add not Manifolds.jl, but ManifoldsBase.jl as a dependency (idea: then it works with all manifolds (tm)).
Without reading about the package here too much, one could then say an https://juliamanifolds.github.io/ManifoldsBase.jl/stable/types.html#ManifoldsBase.AbstractManifold is a set and the main function required is https://juliamanifolds.github.io/ManifoldsBase.jl/stable/functions.html#ManifoldsBase.is_point

Beyond that, for distributions, that might be more complicated for general manifolds – but sure ig one or two manifolds are already (implicitly, not explicitly from Manifolds.jl) used, then one could use the Manifolds.jl-manifold to specify the domain.

edit: I just scrolled through the edit real quick. The in could just map to is_point, the eltype is maybe more tricky, since we have most points on Manifolds implicitly as arrays and not necessarily special types for that. But that is something one could discuss how to make that available here.
Would be cool to combine that :)

[daanhb]

Thanks for the answers. It's a small world @kellertuer, I have a feeling I might learn a bit more about Manifolds.jl in the next couple of months ;-) Hopefully that gives me some inspiration.

A few general comments:

• overall, what we would hope to achieve in DomainSets is to see domains as an interface, rather than any specific type that inherits from Domain{T}. Ideally, there is some non-trivial functionality that works for objects based on their behaviour rather than their type. This is limited for now, though things like unions and intersections of domains are already generic in that way. Long term, it's the only scalable way to "support" other packages without adding dependencies each time.
• we have eternal discussions about what the T in Domain{T} means (i.e. the eltype). I guess it could just be AbstractArray, but it would be good to verify and make sure (within DomainSets) that this does not come with avoidable performance hits.

[kellertuer]

Oh, indeed – HI Dean! I did not klick on your profile and did not recognise you from the username ;) Yes, sometimes the world is small.

We actually also overload Base.in but for now only in Manifolds. So indeed that part is basically available (if one loads Manifolds.jl)

And concerning the eltype – if it could also just be AbstractArray, then the only thing missing to use Manifolds (or ManifoldsBase) is to provide probably a eltype(::AbstractManifold) definition?

[daanhb]

Alright, this calls for some experimentation, time permitting. If there is some concrete scenario of an application that would benefit from ensuring these packages work together, and especially if it improves DomainSets, then I'd be happy work on it.

[kellertuer]

The experiment would be as follows:

We could define a ManifoldDomain which inherits from Domain, and has a manifold stored internally. Its in function would map to is_point and its ´eltypeis one thing where we would need a little bit of an experiment, where to get said type from (but for example we haverand(M)which directly creates a point onM` so it can infer the point type). For more details, I am also missing time today. But it would be a nice experiment to try that some time.
Maybe as a weak dependency in 1.9 that if one loads DomainSets and ManifoldsBase, then Manifolds are also automatically domain sets. Maybe something nice to think about.

[mateuszbaran]

This is an interesting idea. We do have in in Manifolds.jl and eltype should be doable but it looks like the main point about DomainSets.jl (correct me if I'm wrong) is transformations of domains. This is something we haven't worked out particularly well in Manifolds.jl yet. For example we need to add pullback metrics. But there are also positive parts. For example we have tools to deal with Jacobians of transformations that would be degenerate in the embedding. And I would be happy to push Manifolds.jl in the direction of manifold-valued numerical integration, for example -- it looks like it's one of the main applications of DomainSets.jl?

[dlfivefifty]

@daanhb are you now the Dean? 😀 "Dean Daan" I like it!

[daanhb]

This is an interesting idea. We do have in in Manifolds.jl and eltype should be doable but it looks like the main point about DomainSets.jl (correct me if I'm wrong) is transformations of domains. This is something we haven't worked out particularly well in Manifolds.jl yet. For example we need to add pullback metrics. But there are also positive parts. For example we have tools to deal with Jacobians of transformations that would be degenerate in the embedding. And I would be happy to push Manifolds.jl in the direction of manifold-valued numerical integration, for example -- it looks like it's one of the main applications of DomainSets.jl?

DomainSets.jl is part of JuliaApproximation, so the main intended use case is the approximation of functions and solutions to equations. It helps to describe domains and be able to map them, so that one can define basis functions once and use them in novel ways. Integrals are convenient to define projections and compute function norms. But I'm sure people elsewhere use the package with other goals and that's fine - we just make the functionality available and try to make it useful.

[mateuszbaran]

I see, then at least it would be useful to extend both DomainSets.jl and Manifolds.jl to work in bases constructed from eigenvectors of Laplace-Beltrami operator or something similar. I think it could be an interesting project.

[ParadaCarleton]

Integrals are convenient to define projections and compute function norms.

Can you clarify what you mean by this? Basically, what I'm looking for is an easy interface that allows for computing numerical integrals, including integrals on noneuclidean domains. (Probabilistic or sampling problems, like working with probability distributions, are a special case). Typically, this will involve applying a transformation that maps these domains to R^n.

[mateuszbaran]

Note that mapping to R^n is often quite far from the best you can do to integrate over a manifold: https://www-user.tu-chemnitz.de/~potts/workgroup/graef/quadrature/index.php.en .

[ParadaCarleton]

Note that mapping to R^n is often quite far from the best you can do to integrate over a manifold: https://www-user.tu-chemnitz.de/~potts/workgroup/graef/quadrature/index.php.en .

I wouldn't be surprised by that, but most of my use cases aren't integrating over hyperspheres (and most of them involve far more dimensions than shown here) 😅