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

Using ManifoldsBase? #7

Closed
cscherrer opened this issue Aug 24, 2021 · 7 comments
Closed

Using ManifoldsBase? #7

cscherrer opened this issue Aug 24, 2021 · 7 comments

Comments

@cscherrer
Copy link
Collaborator

From a Julia Slack DM with @sethaxen
image

cc @mateuszbaran @kellertuer

A super-lightweight dependency would be great, since that would help keep this package light :)

@cscherrer
Copy link
Collaborator Author

Currently, we only use AbstractDomain as a parameter for Lebesgue or Counting measure. So we just have a couple of functions for taking intervals and testing membership.

A secondary question to the OP is whether there's a benefit (to MeasureTheory, and/or to ManifoldMeasures) in having MeasureTheory depend on ManifoldsBase, in addition to any lightweight dependency to replace AbstractDomains

@kellertuer
Copy link

Currently we indeed do not have much support for non-Riemannian manifolds, but if you want we can surely go towards that, too, with the interface.
I am biased here, but I think the dependency would be nice, and since ManifoldsBase will stay lightweight, should be ok?

Sure we have to check for the R indicating the reals, I have no clue whether that would be over-engineering to have these three types in their own package...

@mateuszbaran
Copy link

We have some support for manifolds with just an affine connection. On the other hand, there are sampleable spaces that we are unlikely to ever support (for example spaces that are not locally Euclidean). Also note that currently Manifolds.jl is heavily skewed towards supporting embedded manifolds and we currently don't really support manifolds with boundaries (although that's a valid goal for us).

If all you need is testing membership then ManifoldsBase.jl doesn't look like the right abstraction.

@cscherrer
Copy link
Collaborator Author

Thanks all. The idea for doing this came from @sethaxen's mention of Euclidean in JuliaManifolds/ManifoldMeasures.jl#14. We'll have some spaces that are not locally Euclidean, but I think the majority of them will be. And of course most of the manifold specifics should go in ManifoldMeasures. I'm just wondering, would it make things easier/harder for any/all of us to bring some of the very core functionality into MeasureTheory? For example,

  1. Our AbstractDomain is kind of hacky, maybe changing it could make connecting these ecosystems more natural?
  2. Lots of measures happen to be on a manifold, or a manifold with boundary at least. Would it help to "declare" this is MeasureTheory, even if we don't do much with that information until ManifoldMeasures?

@gdalle
Copy link
Collaborator

gdalle commented Aug 26, 2021

Just popping by to mention https://github.com/JuliaApproximation/DomainSets.jl as part of the discussion of AbstractDomains.

@cscherrer
Copy link
Collaborator Author

Thanks @gdalle , I'd like to better understand the relationship between this and the manifolds-verse. I didn't end up doing much with it at the time, but
JuliaApproximation/DomainSets.jl#32

@cscherrer
Copy link
Collaborator Author

Talking some more with @sethaxen, there may not be much advantage in this. We can reopen if this changes (or if I'm misunderstanding, which... let's not rule that out) , but for now let's instead consider #16

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

4 participants