Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More Spaces #130

Open
ParadaCarleton opened this issue Jan 18, 2023 · 18 comments
Open

More Spaces #130

ParadaCarleton opened this issue Jan 18, 2023 · 18 comments

Comments

@ParadaCarleton
Copy link

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
Copy link
Member

daanhb commented Jan 18, 2023

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
Copy link
Author

@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
Copy link

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
Copy link

kellertuer commented Jan 19, 2023

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
Copy link
Member

daanhb commented Jan 19, 2023

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
Copy link

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
Copy link
Member

daanhb commented Jan 19, 2023

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
Copy link

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
Copy link

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
Copy link
Member

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

@daanhb
Copy link
Member

daanhb commented Jan 19, 2023

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

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) 😅

@mateuszbaran
Copy link

High dimensionality shouldn't be an issue, points and weights could be recomputed. What kind of manifolds would you be interested in?

@ParadaCarleton
Copy link
Author

Typically, Bayesian models.

@mateuszbaran
Copy link

Intersection of Bayesian models and manifolds is a fairly broad subject with many tools like RMHMC or Riemannian symplectic integrators 😅 . I think the discussion would be more productive if it was aimed at solving some specific problem? Things like Stiefel-valued random variables require different tools than Euclidean RVs with constraints specified by user-defined equations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants