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

Questions about getdof #74

Open
cscherrer opened this issue Jul 30, 2022 · 4 comments
Open

Questions about getdof #74

cscherrer opened this issue Jul 30, 2022 · 4 comments
Assignees

Comments

@cscherrer
Copy link
Collaborator

I have some questions about getdof. Here's the current docstring:

help?> MeasureBase.getdof
  getdof(μ)

  Returns the effective number of degrees of freedom of variates of measure μ.

  The effective NDOF my differ from the length of the variates. For example, the effective NDOF for a
  Dirichlet distribution with variates of length n is n - 1.

  Also see check_dof.

First and easiest, is it right that we can now drop the "effective" from this? Or does it add anything?

Next, I'm wondering if we can pin down the behavior of this a little bit. Currently in MeasureBase I'm getting

julia> getdof(Normal())
NoDOF{LebesgueMeasure}

This is wrong, but I'm not sure of the best way to fix it. Is there a reason getdof can't just check the dimensionality of the root measure? [And, did we already discuss this?]

Then, I'm wondering what conditions should guarantee that getdof is defined? I don't think the root measure should be requried to be LebesgueMeasure() ^ n for some n, since this doesn't hold for manifolds, including affine transforms.

@oschulz
Copy link
Collaborator

oschulz commented Jul 31, 2022

First and easiest, is it right that we can now drop the "effective" from this?

Definitely, that's left over from an early draft.

Currently in MeasureBase I'm getting ... NoDOF{LebesgueMeasure}

That should definitely work, getdof should go down the base-measure stack recursively. With the current releases it does work, though:

pkg> st MeasureBase MeasureTheory
Status `/user/.julia/environments/measuretheory/Project.toml`
  [fa1605e6] MeasureBase v0.12.2
  [eadaa1a4] MeasureTheory v0.16.5

julia> getdof(Normal())
static(1)

Then, I'm wondering what conditions should guarantee that getdof is defined?

I'm not quite sure what the correct approach for discrete measures is here. For contiguous measures it shouldn't be limited to Lebesgue-based measure, of course - but getdof will have to be specialized of course. For manifolds based on affine transformations (I'll see that I get that package done), I guess we can specialize on PushforwardMeasure{<:AffineTransformation}?

@cscherrer
Copy link
Collaborator Author

Definitely, that's left over from an early draft.

Ok great, that's a quick update :)

That should definitely work, getdof should go down the base-measure stack recursively. With the current releases it does work, though

Ah ok, I think I just needed to update this. Thanks

I'm not quite sure what the correct approach for discrete measures is here. For contiguous measures it shouldn't be limited to Lebesgue-based measure, of course - but getdof will have to be specialized of course. For manifolds based on affine transformations (I'll see that I get that package done), I guess we can specialize on PushforwardMeasure{<:AffineTransformation}?

Is the only purpose of getdof to have a global dimensionality to use for transforms? I was about to say we could make it local -- allowing an x argument -- but that doesn't make sense if we're only ever interested in this globally.

@oschulz
Copy link
Collaborator

oschulz commented Aug 1, 2022

Is the only purpose of getdof to have a global dimensionality to use for transforms?

So far, yes, I've only used it globally, and often need to use it before x i known.

@cscherrer
Copy link
Collaborator Author

Thanks @oschulz . Let's leave this open until the docstring is updated, then we can close.

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

2 participants