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

make value API more generic, allow arbitrary payloads #56

Closed
tpapp opened this issue Dec 20, 2019 · 1 comment
Closed

make value API more generic, allow arbitrary payloads #56

tpapp opened this issue Dec 20, 2019 · 1 comment

Comments

@tpapp
Copy link
Owner

tpapp commented Dec 20, 2019

Occasionally it is useful to return an extra "payload" along with values and gradients. Examples include

  1. generated quantities (eg in Stan),
  2. simulated interim data (eg for indirect inference)

Before fixing the API for a longer time, some thought should be given to supporting this.

Here is what I am thinking of:

  1. Define accessors get_logdensity, get_gradient, get_payload for values returned by logdensity and logdensity_and_gradient,

  2. make the latter two return some lightweight container, which has default methods for the above,

  3. with get_payload defaulting to nothing.

The accessors can be introduced at little cost, some dubious workarounds can make the rest non-breaking (dispatch on NTuple) but perhaps a deprecation cycle would be better.

@tpapp
Copy link
Owner Author

tpapp commented Aug 25, 2022

I experimented with this, and found it impractical. You can always refactor to generate interim values easily from posteriors etc. For small problems the runtime cost is trivial, but for large problems saving interim values that are not needed (eg Hamiltonian steps) would generate a ton of unnecessary allocations.

@tpapp tpapp closed this as completed Aug 25, 2022
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

1 participant