Add non-vectorised option for rvs in StructDist

[MercuryBench]

For some cases (in certain more complicated conditional distributions), rvs cannot be sampled all at once, and might need to be looped over. Proposed bugfix for #99

[nchopin]

Please read CONTRIBUTING.md first when you want to do pull requests to any repo. I am going to reject all your PR because they directly target master, and not experimental (or another branch if you propose breaking changes, e.g. different function signatures, etc.).

Just to give you some background on why I put these rules in places: the last pull request I had to deal with was a very small change in a notebook, so accepted it despite the fact it was targetting directly master. This small change made the documentation website inaccessible, and I spent one hour trying to clean up the mess. So strict "push to experimental" policy from now on.

Contents of CONTRIBUTING.md

Thanks a lot for contributing to particles!

Please don't send PR (pull requests) directly to the master branch; send them
instead:

• to the experimental branch if your PR is a bug fix;

• to a new branch if your PR adds functionality.

In fact, when you fork any git repository, it is good practice to switch to
another branch than master before making any change. In this way, your PRs will
be automatically sent to that branch.

In doubt, contact the maintainer: nicolas dot chopin at ensae dot fr

[MercuryBench]

Hi Nicolas, ah, I see. Sorry about that, I have very little practice in working with other people on Github, and I thought I'd give it a go since I have started to use it quite a bit, but it seems I have completely messed that up :). I'll do better next time! Also, a quick update on my questions from last time: I have wrapped my head around most of them (for example, I think I now know how FancyLists and ThetaParticles work, and I can use them), so I will go away and work on that for now. If something useful comes up, I might get back to you. Thanks for your help and sorry again about the Github mess! My plan is to set up a way to automatically build a FK object from a Rao-Blackwellisable state space model. It seems like this might be useful, in particular if combined with a guided PF, which is a bit tricky to set up from scratch. In the end I want to do parameter estimation, so this will add another layer of complexity which I am not yet sure I am capable of doing... Philipp

…

On Sun, Oct 27, 2024 at 11:26 PM Nicolas Chopin ***@***.***> wrote: Please read CONTRIBUTING.md first when you want to do pull requests to any repo. I am going to reject all your PR because they directly target master, and not experimental (or another branch if you propose breaking changes, e.g. different function signatures, etc.). Just to give you some background on why I put these rules in places: the last pull request I had to deal with was a very small change in a notebook, so accepted it despite the fact it was targetting directly master. This small change made the documentation website inaccessible, and I spent one hour trying to clean up the mess. So strict "push to experimental" policy from now on. Contents of CONTRIBUTING.md Thanks a lot for contributing to particles! Please don't send PR (pull requests) directly to the master branch; send them instead: - to the experimental branch if your PR is a bug fix; - to a new branch if your PR adds functionality. In fact, when you fork any git repository, it is good practice to switch to another branch than master before making any change. In this way, your PRs will be automatically sent to that branch. In doubt, contact the maintainer: nicolas dot chopin at ensae dot fr — Reply to this email directly, view it on GitHub <#100 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQMCCCT77I3QNTJPH5BZLTZ5SWVPAVCNFSM6AAAAABQVSRKJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZZHE2TENJZGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>