issue with acceptance_fraction sampler property when using sample(...,store=False)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.6k
- Forks
- 440
- PR merge metrics
- No merged PRs in 30d
Description
[re emcee version 3.0.3.dev40+g408f422]
I use sample(..., store=False). Most of the important information (to me) is stored and recoverable from the State which EnsembleSampler.sample yields (ensemble.py, line 362). Unfortunately, "accepted" which is computed in ensemble.py line 347 is lost (not recorded, not recoverable), except via the Backend but only if one uses sample(..., store=True).
This is not an issue per se since many EnsembleSampler properties don't make sense when using the sampler via sample(..., store=False) anyways. However, since I want to do my own storing (store=False), in order to track the acceptance_fraction, I have written a (bad, minimal) work-around for myself for now by modifying ensemble.py line 347 to "yield state, accepted".
But I am wondering if maybe you agree this is perhaps a property that should be recoverable after (a) step(s)? If so, it would maybe make sense to add "accepted" as a State property? Or maybe there's a more emcee-minded way to make this info available when running sample(..., store=False)?
Or maybe you don't think that's appropriate at all, in which case please feel completely free to ignore this (non)issue and close it. I just thought I would raise it as a possible issue and see what you think.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading ensemble.py around lines 347 and 362, focusing on how accepted is computed, how State is yielded, and how sample(..., store=False) differs from backend storage. Determine whether acceptance information should be recoverable after steps without using the backend, and define the expected behavior for the proposed State or sampling API.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100