pints
pints copied to clipboard
Published
20 hours ago •
pints-team
pints-team
Probabilistic Inference on Noisy Time Series
Results
200
pints issues
Sort by
recently updated
recently updated
newest added
Log-normal log-likelihood
[{"_id":"63806df44b97542c9a306bad","body":"# [Codecov](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1378?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team) Report\n> Merging [#1378](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1378?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team) (c69a748) into [master](https:\/\/codecov.io\/gh\/pints-team\/pints\/commit\/2afaee9fc8525bac67ceb84432b7e7357d03a2c4?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team) (2afaee9) will **not change** coverage.\n> The diff coverage is `100.00%`.\n\n```diff\n@@ Coverage Diff @@\n## master #1378 +\/- ##\n=========================================\n Coverage 100.00% 100.00% \n=========================================\n Files 95 95 \n Lines 9282 9321 +39 \n=========================================\n+ Hits 9282 9321 +39 \n```\n\n\n| [Impacted Files](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1378?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team) | Coverage \u0394 | |\n|---|---|---|\n| [pints\/\\_\\_init\\_\\_.py](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1378\/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team#diff-cGludHMvX19pbml0X18ucHk=) | `100.00% <\u00f8> (\u00f8)` | |\n| [pints\/\\_log\\_likelihoods.py](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1378\/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team#diff-cGludHMvX2xvZ19saWtlbGlob29kcy5weQ==) | `100.00% <100.00%> (\u00f8)` | |\n\nHelp us with your feedback. Take ten seconds to tell us [how you rate us](https:\/\/about.codecov.io\/nps?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team). Have a feature suggestion? [Share it here.](https:\/\/app.codecov.io\/gh\/feedback\/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team)\n","issue_id":1660245932209,"origin_id":894531340,"user_origin_id":22429695,"create_time":1628285786,"update_time":1660246121,"id":1669361140167,"updated_at":"2022-11-25T07:25:40.166000Z","created_at":"2022-11-25T07:25:40.166000Z"},{"_id":"63806df44b97542c9a306bae","body":"@ben18785 @DavAug this is approved. Want to merge it in now?","issue_id":1660245932209,"origin_id":1212199800,"user_origin_id":517644,"create_time":1660234431,"update_time":1660234431,"id":1669361140170,"updated_at":"2022-11-25T07:25:40.170000Z","created_at":"2022-11-25T07:25:40.170000Z"}]
Adds a log-normal distribution both without (default) and with mean-adjustment as described in #1376
Dram simplification (and addressing bug)
[{"_id":"63806e924b97542c9a306c52","body":"# [Codecov](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1339?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team) Report\n> Merging [#1339](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1339?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team) (113869c) into [master](https:\/\/codecov.io\/gh\/pints-team\/pints\/commit\/2afaee9fc8525bac67ceb84432b7e7357d03a2c4?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team) (2afaee9) will **not change** coverage.\n> The diff coverage is `100.00%`.\n\n```diff\n@@ Coverage Diff @@\n## master #1339 +\/- ##\n=========================================\n Coverage 100.00% 100.00% \n=========================================\n Files 95 95 \n Lines 9282 9263 -19 \n=========================================\n- Hits 9282 9263 -19 \n```\n\n\n| [Impacted Files](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1339?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team) | Coverage \u0394 | |\n|---|---|---|\n| [pints\/\\_mcmc\/\\_dram\\_ac.py](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/1339\/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team#diff-cGludHMvX21jbWMvX2RyYW1fYWMucHk=) | `100.00% <100.00%> (\u00f8)` | |\n\nHelp us with your feedback. Take ten seconds to tell us [how you rate us](https:\/\/about.codecov.io\/nps?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team). Have a feature suggestion? [Share it here.](https:\/\/app.codecov.io\/gh\/feedback\/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=pints-team)\n","issue_id":1660245932211,"origin_id":823617245,"user_origin_id":22429695,"create_time":1618954752,"update_time":1660245962,"id":1669361298260,"updated_at":"2022-11-25T07:28:18.260000Z","created_at":"2022-11-25T07:28:18.260000Z"}]
- Simplifies DRAM so it only takes 2 proposal kernels (I think it was overkill to allow more before) - In doing so, sorts bug highlighted in #1337 - Notebook...
See #1402 - [x] TransformedBoundaries. Added `sample()`, removed `range()` - [ ] TransformedErrorMeasure - [ ] TransformedLogPDF - [ ] TransformedLogPrior
TransformedBoundaries and TransformedLogPrior don't override full interface
[{"_id":"6380699d5ae95c7a222fbf87","body":"The `Boundaries` class doesn't define a range, upper, or lower, so the `TransformedBoundaries` shouldn't either\r\n\r\n","issue_id":1660245932216,"origin_id":1212183790,"user_origin_id":517644,"create_time":1660233574,"update_time":1660233574,"id":1669360029615,"updated_at":"2022-11-25T07:07:09.615000Z","created_at":"2022-11-25T07:07:09.615000Z"},{"_id":"6380699d5ae95c7a222fbf88","body":"TransformedBoundaries is missing a `sample` method","issue_id":1660245932216,"origin_id":1212185444,"user_origin_id":517644,"create_time":1660233656,"update_time":1660233656,"id":1669360029618,"updated_at":"2022-11-25T07:07:09.618000Z","created_at":"2022-11-25T07:07:09.618000Z"},{"_id":"6380699d5ae95c7a222fbf89","body":"Closed in #1450 ","issue_id":1660245932216,"origin_id":1212431972,"user_origin_id":517644,"create_time":1660248118,"update_time":1660248118,"id":1669360029621,"updated_at":"2022-11-25T07:07:09.620000Z","created_at":"2022-11-25T07:07:09.620000Z"}]
~In https://github.com/pints-team/pints/blob/master/pints/_transformation.py we have [`TransformedBoundaries`](https://github.com/pints-team/pints/blob/master/pints/_transformation.py#L884) and a [`TransformedLogPrior`](https://github.com/pints-team/pints/blob/master/pints/_transformation.py#L1105) that implement some, but not all, of the methods in Boundaries and LogPrior. This means the remaining methods will return results using...
bug
Example showing interface with Julia
[{"_id":"63806c194b97542c9a306984","body":"Solving ODEs is outside the scope of PINTS. So if anyone wants to code up those examples that's fine and can go in separate repos (similar to https:\/\/github.com\/pints-team\/myokit-pints-examples ).\r\n\r\n","issue_id":1660245932219,"origin_id":544930626,"user_origin_id":517644,"create_time":1571746075,"update_time":1571746075,"id":1669360665660,"updated_at":"2022-11-25T07:17:45.660000Z","created_at":"2022-11-25T07:17:45.660000Z"},{"_id":"63806c194b97542c9a306985","body":"Ok but can we point to an example of this within PINTS? I agree solving ODEs is outside of scope but given that increasing numbers of people solve ODEs within Julia, I think it\u2019d be good to show them that PINTS can be used in this way.\n\nOn that note, it\u2019d be good to perhaps have a repo for miscellaneous stuff related to fitting ODE\/PDE\/DAEs with PINTS. In these, we could show how to, fit example, calculate sensitivities using Sundials\/CVODE and use these in PINTS. In this, we could show how to interface Julia\/other software with PINTS too.\n\n> On 22 Oct 2019, at 13:07, Michael Clerx <[email protected]> wrote:\n> \n> Solving ODEs is outside the scope of PINTS. So if anyone wants to code up those examples that's fine and can go in separate repos (similar to https:\/\/github.com\/pints-team\/myokit-pints-examples ).\n> \n> \u2014\n> You are receiving this because you authored the thread.\n> Reply to this email directly, view it on GitHub, or unsubscribe.\n","issue_id":1660245932219,"origin_id":545091873,"user_origin_id":4490664,"create_time":1571768662,"update_time":1571768662,"id":1669360665664,"updated_at":"2022-11-25T07:17:45.663000Z","created_at":"2022-11-25T07:17:45.663000Z"},{"_id":"63806c194b97542c9a306986","body":"Just do a repo for each! So feel free to set up a pints\/team-julia-ode or something :-)","issue_id":1660245932219,"origin_id":545100637,"user_origin_id":517644,"create_time":1571770017,"update_time":1571770017,"id":1669360665666,"updated_at":"2022-11-25T07:17:45.666000Z","created_at":"2022-11-25T07:17:45.666000Z"},{"_id":"63806c194b97542c9a306988","body":"Hey, did you get any further with this? I tried using [DiffEqPy](https:\/\/github.com\/SciML\/diffeqpy) to solve a system with Julia's ODE solver, because the ODE solvers do indeed perform much better than SciPy's for the problem I'm currently solving. However, the problem I ran into is that Python and Julia don't play nice in a multiprocessing context and it runs excruciatingly slowly. I suspect that Julia is just-in-time compiling every iteration, not even merely once per core. In my example, what would take up to 20 seconds in pure python instead took up to 10 minutes with the Julia integration, sadly.\r\n\r\nThis problem is a [known issue](https:\/\/pyjulia.readthedocs.io\/en\/latest\/limitations.html) but I was interested to see if you'd made any progress regardless.\r\n\r\nIt was an unfortunate first foray into Julia, to find that it'd be a choice between good data fitting in python or good ODE solving in Julia!","issue_id":1660245932219,"origin_id":1207888097,"user_origin_id":5658454,"create_time":1659951104,"update_time":1659951191,"id":1669360665669,"updated_at":"2022-11-25T07:17:45.669000Z","created_at":"2022-11-25T07:17:45.669000Z"}]
Julia has really fast ODE solvers. I'd like to have an example notebook where we show how Julia solvers can be used from within Python, so that they can be...
documentation
Diagnostics module design
[{"_id":"638067194b97542c9a3062f0","body":"Sounds like a plan. I'd keep the diagnostics outside of pints.mcmc as can\nimagine having diagnostics for other methods later on (and it's annoying-er\nto do import pints.mcmc.diagnostics).\n\nOn Tue, Feb 9, 2021 at 2:55 PM Michael Clerx <[email protected]>\nwrote:\n\n> We have a *private* module pints._diagnostics that declares public and\n> private methods, some of the public methods are exposed to the user as part\n> of the public API.\n>\n> However, the test for diagnostics imports the hidden module directly and\n> tests methods not visible to the user.\n>\n> Maybe this is fine, but usually it's a sign that we need to redesign a bit?\n>\n> I'd propose making the diagnostics module public, so that\n> pints.effective_sample_size becomes e.g.\n> pints.diagnostics.effective_sample_size. Then we can make other methods,\n> e.g. autocorrelation public too, without cluttering the pints namespace.\n>\n> We could also imagine having them under pints.mcmc, but at the moment\n> that only contains MCMCSamplers (even the MCMCController is in pints)\n>\n> Thoughts @ben18785 <https:\/\/github.com\/ben18785> @DavAug\n> <https:\/\/github.com\/DavAug> ?\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https:\/\/github.com\/pints-team\/pints\/issues\/1283>, or unsubscribe\n> <https:\/\/github.com\/notifications\/unsubscribe-auth\/ABCILKABDCDRRHHPL2JU2JDS6FEGDANCNFSM4XLERGWA>\n> .\n>\n","issue_id":1660245932220,"origin_id":776001299,"user_origin_id":4490664,"create_time":1612882674,"update_time":1612882674,"id":1669359385242,"updated_at":"2022-11-25T06:56:25.241000Z","created_at":"2022-11-25T06:56:25.241000Z"},{"_id":"638067194b97542c9a3062f1","body":"@DavAug are you happy to pick this up? You seem to be into diagnostics at the moment \ud83d\ude04 ","issue_id":1660245932220,"origin_id":776024919,"user_origin_id":517644,"create_time":1612884621,"update_time":1612884621,"id":1669359385244,"updated_at":"2022-11-25T06:56:25.244000Z","created_at":"2022-11-25T06:56:25.244000Z"},{"_id":"638067194b97542c9a3062f2","body":"Yep no problem. But before I do this @ben18785 are we still planning on outsourcing all of this to arviz? Because then it may not be necessary to implement a diagnostics module?\r\n\r\nGet Outlook for iOS<https:\/\/aka.ms\/o0ukef>\r\n________________________________\r\nFrom: Michael Clerx <[email protected]>\r\nSent: Tuesday, February 9, 2021 4:30:38 PM\r\nTo: pints-team\/pints <[email protected]>\r\nCc: David Augustin <[email protected]>; Mention <[email protected]>\r\nSubject: Re: [pints-team\/pints] Diagnostics module design (#1283)\r\n\r\n\r\n@DavAug<https:\/\/github.com\/DavAug> are you happy to pick this up? You seem to be into diagnostics at the moment \ud83d\ude04\r\n\r\n\u2014\r\nYou are receiving this because you were mentioned.\r\nReply to this email directly, view it on GitHub<https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-776024919>, or unsubscribe<https:\/\/github.com\/notifications\/unsubscribe-auth\/AEY2T3XVRGUPKKROPSG6SLTS6FIJ5ANCNFSM4XLERGWA>.\r\n","issue_id":1660245932220,"origin_id":776037278,"user_origin_id":20031982,"create_time":1612885637,"update_time":1612885637,"id":1669359385246,"updated_at":"2022-11-25T06:56:25.246000Z","created_at":"2022-11-25T06:56:25.246000Z"},{"_id":"638067194b97542c9a3062f3","body":"So, I think we still want our existing diagnostics methods but that any new\nones come from Arviz...\n\nOn Tue, Feb 9, 2021 at 3:47 PM David Augustin <[email protected]>\nwrote:\n\n> Yep no problem. But before I do this @ben18785 are we still planning on\n> outsourcing all of this to arviz? Because then it may not be necessary to\n> implement a diagnostics module?\n>\n> Get Outlook for iOS<https:\/\/aka.ms\/o0ukef>\n> ________________________________\n> From: Michael Clerx <[email protected]>\n> Sent: Tuesday, February 9, 2021 4:30:38 PM\n> To: pints-team\/pints <[email protected]>\n> Cc: David Augustin <[email protected]>; Mention <\n> [email protected]>\n> Subject: Re: [pints-team\/pints] Diagnostics module design (#1283)\n>\n>\n> @DavAug<https:\/\/github.com\/DavAug> are you happy to pick this up? You\n> seem to be into diagnostics at the moment \ud83d\ude04\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub<\n> https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-776024919>,\n> or unsubscribe<\n> https:\/\/github.com\/notifications\/unsubscribe-auth\/AEY2T3XVRGUPKKROPSG6SLTS6FIJ5ANCNFSM4XLERGWA>.\n>\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-776037278>,\n> or unsubscribe\n> <https:\/\/github.com\/notifications\/unsubscribe-auth\/ABCILKHHT5HJ726RJFQFRWDS6FKJNANCNFSM4XLERGWA>\n> .\n>\n","issue_id":1660245932220,"origin_id":776039146,"user_origin_id":4490664,"create_time":1612885751,"update_time":1612885751,"id":1669359385249,"updated_at":"2022-11-25T06:56:25.248000Z","created_at":"2022-11-25T06:56:25.248000Z"},{"_id":"638067194b97542c9a3062f4","body":"I am modifying the docstrings a little bit to let the users know in more detail which assumptions are made for the ESS and autocorrelation computation. Following the stan discussion we are currently actually using a somewhat less motivated truncation criterion for the ESS computation, see https:\/\/discourse.mc-stan.org\/t\/n-eff-bda3-vs-stan\/2608\/20.\r\n\r\nIn brief, currently we only keep the correlations up to the first negative correlation. Apparently there is no theoretic justification for this, instead one should consider pairs of correlations, i.e. (sum of correlation at lag 0 and 1, at lag 2 and 3, at lag 4 and 5 etc.). The first negative pair should be used as truncation criterion. \r\n\r\nI would like to make changes according to stan and just wanted to check with you whether there was a theoretical justification for the current implementation, @ben18785 @MichaelClerx @chonlei @rcw5890 ?","issue_id":1660245932220,"origin_id":778762964,"user_origin_id":20031982,"create_time":1613301254,"update_time":1613301272,"id":1669359385252,"updated_at":"2022-11-25T06:56:25.251000Z","created_at":"2022-11-25T06:56:25.251000Z"},{"_id":"638067194b97542c9a3062f5","body":"@MichaelClerx , I have started to move diagnostics functions into a separate diagnostics module. How does the deprecation work for those functions? Or is it ok to just delete them from the pints namespace?","issue_id":1660245932220,"origin_id":778770664,"user_origin_id":20031982,"create_time":1613305519,"update_time":1613305519,"id":1669359385255,"updated_at":"2022-11-25T06:56:25.254000Z","created_at":"2022-11-25T06:56:25.254000Z"},{"_id":"638067194b97542c9a3062f6","body":"@DavAug I usually do something like this:\r\n\r\n```\r\nimport warnings\r\n\r\ndef method_that_I_want_to_remove_now(self):\r\n # Deprecated on 2021-02-14\r\n warnings.warn('pints.method_that_I_want_to_remove_now is deprecated and will be removed in future versions of Pints')\r\n <original code here>\r\n \r\ndef method_with_new_name(self):\r\n <method code here>\r\n\r\ndef method_with_old_name(self, x):\r\n # Deprecated on ...\r\n warnings.warn('pints.method_with_old name is deprecated and will be removed in future versions of Pints, please use method_with_new_name() instead.')\r\n return method_with_new_name(x)\r\n```","issue_id":1660245932220,"origin_id":778780692,"user_origin_id":517644,"create_time":1613310571,"update_time":1613310571,"id":1669359385257,"updated_at":"2022-11-25T06:56:25.257000Z","created_at":"2022-11-25T06:56:25.257000Z"},{"_id":"638067194b97542c9a3062f7","body":"Hi David, happy for you to make those changes if you like. Perhaps it'd\njust be better though to move wholesale to Arviz? There are a host of\nchanges to ESS that are possible (your proposed is one of them), so rather\nthan reinvent the wheel, I think just moving to Arviz makes sense.\n\nOn Sun, Feb 14, 2021 at 11:14 AM David Augustin <[email protected]>\nwrote:\n\n> I am modifying the docstrings a little bit to let the users know in more\n> detail which assumptions are made for the ESS and autocorrelation\n> assumptions. Following the stan discussion we are currently actually using\n> a somewhat less motivated truncation criterion for the ESS computation, see\n> https:\/\/discourse.mc-stan.org\/t\/n-eff-bda3-vs-stan\/2608\/20.\n>\n> In brief, currently we only keep the correlations up to the first negative\n> correlation. Apparently there is no theoretic justification for this,\n> instead one should consider pairs of correlations, i.e. (sum of correlation\n> at lag 0 and 1, at lag 2 and 3, at lag 4 and 5 etc.). The first negative\n> pair should be used as truncation criterion.\n>\n> I would like to make changes according to stan and just wanted to check\n> with you whether there was a theoretical justification for the current\n> implementation, @ben18785 <https:\/\/github.com\/ben18785> @MichaelClerx\n> <https:\/\/github.com\/MichaelClerx> @chonlei <https:\/\/github.com\/chonlei>\n> @rcw5890 <https:\/\/github.com\/rcw5890> ?\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-778762964>,\n> or unsubscribe\n> <https:\/\/github.com\/notifications\/unsubscribe-auth\/ABCILKGNAOUKZNFYM3SMHS3S66WBRANCNFSM4XLERGWA>\n> .\n>\n","issue_id":1660245932220,"origin_id":778811288,"user_origin_id":4490664,"create_time":1613324200,"update_time":1613324200,"id":1669359385259,"updated_at":"2022-11-25T06:56:25.259000Z","created_at":"2022-11-25T06:56:25.259000Z"},{"_id":"638067194b97542c9a3062f8","body":"I agree hundred percent that arviz does everything we want (except maybe the multivariate rhat). I thought however that the current metrics were supposed to be moved? If that\u2019s the case we might want to fix the bug in ESS because the current truncation seems to be wrong \/ arbitrary.\n\nGet Outlook for iOS<https:\/\/aka.ms\/o0ukef>\n________________________________\nFrom: ben18785 <[email protected]>\nSent: Sunday, February 14, 2021 6:36:58 PM\nTo: pints-team\/pints <[email protected]>\nCc: David Augustin <[email protected]>; Mention <[email protected]>\nSubject: Re: [pints-team\/pints] Diagnostics module design (#1283)\n\n\nHi David, happy for you to make those changes if you like. Perhaps it'd\njust be better though to move wholesale to Arviz? There are a host of\nchanges to ESS that are possible (your proposed is one of them), so rather\nthan reinvent the wheel, I think just moving to Arviz makes sense.\n\nOn Sun, Feb 14, 2021 at 11:14 AM David Augustin <[email protected]>\nwrote:\n\n> I am modifying the docstrings a little bit to let the users know in more\n> detail which assumptions are made for the ESS and autocorrelation\n> assumptions. Following the stan discussion we are currently actually using\n> a somewhat less motivated truncation criterion for the ESS computation, see\n> https:\/\/discourse.mc-stan.org\/t\/n-eff-bda3-vs-stan\/2608\/20.\n>\n> In brief, currently we only keep the correlations up to the first negative\n> correlation. Apparently there is no theoretic justification for this,\n> instead one should consider pairs of correlations, i.e. (sum of correlation\n> at lag 0 and 1, at lag 2 and 3, at lag 4 and 5 etc.). The first negative\n> pair should be used as truncation criterion.\n>\n> I would like to make changes according to stan and just wanted to check\n> with you whether there was a theoretical justification for the current\n> implementation, @ben18785 <https:\/\/github.com\/ben18785> @MichaelClerx\n> <https:\/\/github.com\/MichaelClerx> @chonlei <https:\/\/github.com\/chonlei>\n> @rcw5890 <https:\/\/github.com\/rcw5890> ?\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-778762964>,\n> or unsubscribe\n> <https:\/\/github.com\/notifications\/unsubscribe-auth\/ABCILKGNAOUKZNFYM3SMHS3S66WBRANCNFSM4XLERGWA>\n> .\n>\n\n\u2014\nYou are receiving this because you were mentioned.\nReply to this email directly, view it on GitHub<https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-778811288>, or unsubscribe<https:\/\/github.com\/notifications\/unsubscribe-auth\/AEY2T3UVNWICCI2T5XLJHJLS7AC3VANCNFSM4XLERGWA>.\n","issue_id":1660245932220,"origin_id":778812055,"user_origin_id":20031982,"create_time":1613324493,"update_time":1613324493,"id":1669359385262,"updated_at":"2022-11-25T06:56:25.261000Z","created_at":"2022-11-25T06:56:25.261000Z"},{"_id":"638067194b97542c9a3062f9","body":"Hi David: it's not actually a bug, just the old definition of how this was\nhandled for ESS. So, think it's ok to leave as is rather than update to a\nnewer method for calculating it.\n\nOn Sun, Feb 14, 2021 at 5:41 PM David Augustin <[email protected]>\nwrote:\n\n> I agree hundred percent that arviz does everything we want (except maybe\n> the multivariate rhat). I thought however that the current metrics were\n> supposed to be moved? If that\u2019s the case we might want to fix the bug in\n> ESS because the current truncation seems to be wrong \/ arbitrary.\n>\n> Get Outlook for iOS<https:\/\/aka.ms\/o0ukef>\n> ________________________________\n> From: ben18785 <[email protected]>\n> Sent: Sunday, February 14, 2021 6:36:58 PM\n> To: pints-team\/pints <[email protected]>\n> Cc: David Augustin <[email protected]>; Mention <\n> [email protected]>\n> Subject: Re: [pints-team\/pints] Diagnostics module design (#1283)\n>\n>\n> Hi David, happy for you to make those changes if you like. Perhaps it'd\n> just be better though to move wholesale to Arviz? There are a host of\n> changes to ESS that are possible (your proposed is one of them), so rather\n> than reinvent the wheel, I think just moving to Arviz makes sense.\n>\n> On Sun, Feb 14, 2021 at 11:14 AM David Augustin <[email protected]>\n> wrote:\n>\n> > I am modifying the docstrings a little bit to let the users know in more\n> > detail which assumptions are made for the ESS and autocorrelation\n> > assumptions. Following the stan discussion we are currently actually\n> using\n> > a somewhat less motivated truncation criterion for the ESS computation,\n> see\n> > https:\/\/discourse.mc-stan.org\/t\/n-eff-bda3-vs-stan\/2608\/20.\n> >\n> > In brief, currently we only keep the correlations up to the first\n> negative\n> > correlation. Apparently there is no theoretic justification for this,\n> > instead one should consider pairs of correlations, i.e. (sum of\n> correlation\n> > at lag 0 and 1, at lag 2 and 3, at lag 4 and 5 etc.). The first negative\n> > pair should be used as truncation criterion.\n> >\n> > I would like to make changes according to stan and just wanted to check\n> > with you whether there was a theoretical justification for the current\n> > implementation, @ben18785 <https:\/\/github.com\/ben18785> @MichaelClerx\n> > <https:\/\/github.com\/MichaelClerx> @chonlei <https:\/\/github.com\/chonlei>\n> > @rcw5890 <https:\/\/github.com\/rcw5890> ?\n> >\n> > \u2014\n> > You are receiving this because you were mentioned.\n> > Reply to this email directly, view it on GitHub\n> > <https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-778762964\n> >,\n> > or unsubscribe\n> > <\n> https:\/\/github.com\/notifications\/unsubscribe-auth\/ABCILKGNAOUKZNFYM3SMHS3S66WBRANCNFSM4XLERGWA\n> >\n> > .\n> >\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub<\n> https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-778811288>,\n> or unsubscribe<\n> https:\/\/github.com\/notifications\/unsubscribe-auth\/AEY2T3UVNWICCI2T5XLJHJLS7AC3VANCNFSM4XLERGWA\n> >.\n>\n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https:\/\/github.com\/pints-team\/pints\/issues\/1283#issuecomment-778812055>,\n> or unsubscribe\n> <https:\/\/github.com\/notifications\/unsubscribe-auth\/ABCILKAUIAHZ4GOQAXOD7ZDS7ADN7ANCNFSM4XLERGWA>\n> .\n>\n","issue_id":1660245932220,"origin_id":778813962,"user_origin_id":4490664,"create_time":1613325214,"update_time":1613325214,"id":1669359385264,"updated_at":"2022-11-25T06:56:25.263000Z","created_at":"2022-11-25T06:56:25.263000Z"},{"_id":"638067194b97542c9a3062fa","body":"> Hi David: it's not actually a bug, just the old definition of how this was handled for ESS. So, think it's ok to leave as is rather than update to a newer method for calculating it.\r\n\r\nAh ok. Would you mind if I changed it already? \r\n\r\nAccording to the discussion in the Stan forum above, it seems that Stan's \"old\" version was not very well justified. They argue specifically for the NUTS sampler. \r\n\r\n\"Exact autocorrelations can happen only on odd lags (Geyer, 2011). By summing over\r\npairs, the paired autocorrelation is guaranteed to be positive modulo estimator noise.\r\nThis is the motivation behind the many termination criterion of Geyer (2011).\r\nStan does not (yet) do the paired expectations because NUTS almost by construction avoids\r\nthe negative autocorrelation regime. Thus terminating at the first negative autocorre-\r\nlation is a reasonable approximation for stopping when the noise in the autocorrela-\r\ntion estimator dominates.\"\r\n\r\nAccording to Vehtari that doesn't seem to have a sound theoretical justification, but Geyer's original truncation criterion does.\r\n\r\n\"I\u2019m trying to compare n_eff computation described in BDA3 and the implemented code, and I think there is a small difference. The comment in the beginning says the implementation matches BDA3. BDA3 (at least version 20150505) describes truncation of the autocorrelation series using Geyer\u2019s initial positive sequence (Geyer, 1992) where truncation \u201cT is the first odd positive integer for which $\\widehat{\\rho}{T+1}+\\widehat{\\rho}{T+2}$ is negative.\u201d. If I understand the code (stan\/src\/stan\/mcmc\/chains.hpp) it\u2019s using \u201cT is the last positive integer for which \\widehat{\\rho}_{T} is positive.\u201d, that is, it\u2019s not using the sum of odd and even lags for which Geyer had a theoretical argument.\"\r\n\r\nSo I would argue to adapt to Stan (also given that I've implemented it already) :D","issue_id":1660245932220,"origin_id":778821894,"user_origin_id":20031982,"create_time":1613328136,"update_time":1613328136,"id":1669359385267,"updated_at":"2022-11-25T06:56:25.266000Z","created_at":"2022-11-25T06:56:25.266000Z"},{"_id":"638067194b97542c9a3062fb","body":"The soon to be deprecated `pints.effective_sample_size` will still be computing the effective sample size as we had it before, so it wouldn't change anything for other scripts that have used this estimate.","issue_id":1660245932220,"origin_id":778822467,"user_origin_id":20031982,"create_time":1613328370,"update_time":1613328382,"id":1669359385269,"updated_at":"2022-11-25T06:56:25.268000Z","created_at":"2022-11-25T06:56:25.268000Z"},{"_id":"638067194b97542c9a3062fc","body":"Yep, fine if you\u2019ve already done it \u2014 thanks!\n\n> On 14 Feb 2021, at 18:46, David Augustin <[email protected]> wrote:\n> \n> The soon to be deprecated pints.effective_sample_size will still be computing the effective sample size as we had it before, so it wouldn't change anything for other scripts that have used this estimate.\n> \n> \u2014\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub, or unsubscribe.\n","issue_id":1660245932220,"origin_id":778825895,"user_origin_id":4490664,"create_time":1613329830,"update_time":1613329830,"id":1669359385271,"updated_at":"2022-11-25T06:56:25.271000Z","created_at":"2022-11-25T06:56:25.271000Z"},{"_id":"638067194b97542c9a3062fd","body":"I have created a diagnostics module with the following functions\r\n\r\n- [x] `pints.diagnostics.autocorrelation`\r\n- [x] `pints.diagnostics.effective_sample_size`\r\n- [x] `pints.diagnostics.multivariate_rhat`\r\n- [x] `pints.diagnostics.rhat`\r\n\r\nAll functions can handle multiple chains with multiple parameters.\r\n\r\n- [x] The effective sample size now uses the Geyer criterion as discussed above.\r\n- [x] The effective sample size can now also deal with multiple chains and approximate ESS according to Vehtari et al (goes beyond \"simple\" addition of ESS from chains) \r\n","issue_id":1660245932220,"origin_id":778833691,"user_origin_id":20031982,"create_time":1613333017,"update_time":1613333017,"id":1669359385273,"updated_at":"2022-11-25T06:56:25.273000Z","created_at":"2022-11-25T06:56:25.273000Z"},{"_id":"638067194b97542c9a3062fe","body":"Open questions:\r\n\r\n1. Do we want to move the MCMCSummary as well into the diagnostics? I.e. deprecate it in the pints namespace and make it available in pints.diagnostics\r\n2. Do we want to change the MCMCSummary's ESS estimation to the now implemented ESS estimation across multiple chains following Vehtari et al (both is possible with the new ESS implementation)\r\n3. Does it make sense to also move plots that are specifically for diagnosting into the diagnostics namespace?","issue_id":1660245932220,"origin_id":778834060,"user_origin_id":20031982,"create_time":1613333188,"update_time":1613333228,"id":1669359385276,"updated_at":"2022-11-25T06:56:25.275000Z","created_at":"2022-11-25T06:56:25.275000Z"},{"_id":"638067194b97542c9a3062ff","body":"Thanks @DavAug \r\n\r\nIn response to your questions:\r\n\r\n1. I don't mind. It probably makes most sense for it to go in the diagnostics module.\r\n2. Yes, if it's already implemented then let's switch.\r\n3. I'd keep plots where they are for now because I can see arguments either way (and it's less work to keep them where they are).","issue_id":1660245932220,"origin_id":779186103,"user_origin_id":4490664,"create_time":1613391502,"update_time":1613391502,"id":1669359385279,"updated_at":"2022-11-25T06:56:25.278000Z","created_at":"2022-11-25T06:56:25.278000Z"},{"_id":"638067194b97542c9a306300","body":"@DavAug this one looks quite finished to me?","issue_id":1660245932220,"origin_id":1173904792,"user_origin_id":517644,"create_time":1656946142,"update_time":1656946142,"id":1669359385281,"updated_at":"2022-11-25T06:56:25.281000Z","created_at":"2022-11-25T06:56:25.281000Z"},{"_id":"638067194b97542c9a306301","body":"> @DavAug this one looks quite finished to me?\n\nOh boy, I haven't looked at this for a long time. If I remember correctly, I didn't quite finish the testing, because it wasn't quite obvious to me at the time how to do it in a principled way. The diagnostics module itself should be ready though. ","issue_id":1660245932220,"origin_id":1174029077,"user_origin_id":20031982,"create_time":1656956214,"update_time":1656956214,"id":1669359385284,"updated_at":"2022-11-25T06:56:25.283000Z","created_at":"2022-11-25T06:56:25.283000Z"},{"_id":"638067194b97542c9a306302","body":"Probably best to skip the principled bit, and just compare the output to a hardcoded result?","issue_id":1660245932220,"origin_id":1174032655,"user_origin_id":517644,"create_time":1656956610,"update_time":1656956610,"id":1669359385286,"updated_at":"2022-11-25T06:56:25.286000Z","created_at":"2022-11-25T06:56:25.286000Z"}]
We have a _private_ module `pints._diagnostics` that declares public and private methods, some of the public methods are exposed to the user as part of the public API. However, the...
code and design
To dos: redux
[{"_id":"63806e45bc25e83db00a4f5a","body":"I would keep point 1 and ditch the rest :D ","issue_id":1660245932222,"origin_id":793868710,"user_origin_id":517644,"create_time":1615294904,"update_time":1615294904,"id":1669361221105,"updated_at":"2022-11-25T07:27:01.105000Z","created_at":"2022-11-25T07:27:01.105000Z"},{"_id":"63806e45bc25e83db00a4f5b","body":"Haha. Not point 4?","issue_id":1660245932222,"origin_id":793870079,"user_origin_id":4490664,"create_time":1615294978,"update_time":1615294978,"id":1669361221109,"updated_at":"2022-11-25T07:27:01.108000Z","created_at":"2022-11-25T07:27:01.108000Z"},{"_id":"63806e45bc25e83db00a4f5c","body":"As much as possible, but no method or bug is a deal breaker for me :-)\r\nThanks again for the overview earlier! Really made me think that we have enough to get started.","issue_id":1660245932222,"origin_id":793873768,"user_origin_id":517644,"create_time":1615295184,"update_time":1615295184,"id":1669361221111,"updated_at":"2022-11-25T07:27:01.111000Z","created_at":"2022-11-25T07:27:01.111000Z"},{"_id":"63806e45bc25e83db00a4f5d","body":"Then again, we can do a list of things we really want fixed\/added so that we can present PINTS in public without shame \ud83d\ude04 \ud83d\ude04 \ud83d\ude04\r\nSo let's do a short list but agree once that's done it's set in stone, so nothing more can be added?","issue_id":1660245932222,"origin_id":793880755,"user_origin_id":517644,"create_time":1615295572,"update_time":1615295572,"id":1669361221114,"updated_at":"2022-11-25T07:27:01.113000Z","created_at":"2022-11-25T07:27:01.113000Z"},{"_id":"63806e45bc25e83db00a4f5e","body":"Yep, that's fine with me. Shall we amend the current PINTS project then?","issue_id":1660245932222,"origin_id":793917483,"user_origin_id":4490664,"create_time":1615297484,"update_time":1615297484,"id":1669361221116,"updated_at":"2022-11-25T07:27:01.116000Z","created_at":"2022-11-25T07:27:01.116000Z"},{"_id":"63806e45bc25e83db00a4f5f","body":"Yes please\r\n","issue_id":1660245932222,"origin_id":793920764,"user_origin_id":517644,"create_time":1615297654,"update_time":1615297654,"id":1669361221119,"updated_at":"2022-11-25T07:27:01.118000Z","created_at":"2022-11-25T07:27:01.118000Z"},{"_id":"63806e45bc25e83db00a4f60","body":"@Rebecca-Rumney @alisterde @DavAug @rcw5890 anything you really want in before we write the big paper?","issue_id":1660245932222,"origin_id":793943794,"user_origin_id":517644,"create_time":1615298820,"update_time":1615298820,"id":1669361221121,"updated_at":"2022-11-25T07:27:01.121000Z","created_at":"2022-11-25T07:27:01.121000Z"},{"_id":"63806e45bc25e83db00a4f61","body":"Thanks @MichaelClerx and @ben18785 I'd really like to get #1083 and #1160 done so that we have some 1st order sensitivity optimisers, but as you know I'm working on those at the moment!","issue_id":1660245932222,"origin_id":793977427,"user_origin_id":56870042,"create_time":1615300477,"update_time":1615300477,"id":1669361221124,"updated_at":"2022-11-25T07:27:01.124000Z","created_at":"2022-11-25T07:27:01.124000Z"},{"_id":"63806e45bc25e83db00a4f62","body":"@ben18785 can this one be closed? I don't think we've done all of these, but priorities have shifted perhaps?","issue_id":1660245932222,"origin_id":1173903565,"user_origin_id":517644,"create_time":1656946059,"update_time":1656946059,"id":1669361221128,"updated_at":"2022-11-25T07:27:01.127000Z","created_at":"2022-11-25T07:27:01.127000Z"}]
1. Functional testing! Fergus and David? 2. Automatic MCMC initialisation: Ben 3. MultiNest: Ben 4. Sort bug in populationMCMC: Michael 5. Provide some way for model comparison: Rebecca, David and...
Add SMC sampler
[{"_id":"638077c370db72139b110d5e","body":"# [Codecov](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749?src=pr&el=h1) Report\n> Merging [#749](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749?src=pr&el=desc) into [master](https:\/\/codecov.io\/gh\/pints-team\/pints\/commit\/9dd19c6d0c9dcd529146e7896e785fc76be21806?src=pr&el=desc) will **not change** coverage.\n> The diff coverage is `100%`.\n\n[](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749?src=pr&el=tree)\n\n```diff\n@@ Coverage Diff @@\n## master #749 +\/- ##\n======================================\n Coverage 100% 100% \n======================================\n Files 52 54 +2 \n Lines 5022 5365 +343 \n======================================\n+ Hits 5022 5365 +343\n```\n\n\n| [Impacted Files](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749?src=pr&el=tree) | Coverage \u0394 | |\n|---|---|---|\n| [pints\/\\_sequential\/\\_\\_init\\_\\_.py](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749\/diff?src=pr&el=tree#diff-cGludHMvX3NlcXVlbnRpYWwvX19pbml0X18ucHk=) | `100% <100%> (\u00f8)` | |\n| [pints\/\\_sequential\/\\_SMC.py](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749\/diff?src=pr&el=tree#diff-cGludHMvX3NlcXVlbnRpYWwvX1NNQy5weQ==) | `100% <100%> (\u00f8)` | |\n| [pints\/\\_nested\/\\_rejection.py](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749\/diff?src=pr&el=tree#diff-cGludHMvX25lc3RlZC9fcmVqZWN0aW9uLnB5) | `100% <100%> (\u00f8)` | :arrow_up: |\n| [pints\/\\_mcmc\/\\_adaptive\\_covariance.py](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749\/diff?src=pr&el=tree#diff-cGludHMvX21jbWMvX2FkYXB0aXZlX2NvdmFyaWFuY2UucHk=) | `100% <100%> (\u00f8)` | :arrow_up: |\n| [pints\/\\_nested\/\\_ellipsoid.py](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749\/diff?src=pr&el=tree#diff-cGludHMvX25lc3RlZC9fZWxsaXBzb2lkLnB5) | `100% <100%> (\u00f8)` | :arrow_up: |\n\n------\n\n[Continue to review full report at Codecov](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749?src=pr&el=continue).\n> **Legend** - [Click here to learn more](https:\/\/docs.codecov.io\/docs\/codecov-delta)\n> `\u0394 = absolute <relative> (impact)`, `\u00f8 = not affected`, `? = missing data`\n> Powered by [Codecov](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749?src=pr&el=footer). Last update [9dd19c6...b6e9361](https:\/\/codecov.io\/gh\/pints-team\/pints\/pull\/749?src=pr&el=lastupdated). Read the [comment docs](https:\/\/docs.codecov.io\/docs\/pull-request-comments).\n","issue_id":1660245932224,"origin_id":485786943,"user_origin_id":22429695,"create_time":1556023470,"update_time":1560265647,"id":1669363651138,"updated_at":"2022-11-25T08:07:31.138000Z","created_at":"2022-11-25T08:07:31.138000Z"},{"_id":"638077c370db72139b110d5f","body":"Had a chat with @ben18785 , decided to do it in chunks, i.e. evaluate `n_particles` in blocks of `n_processes`, then adapting in between\r\n","issue_id":1660245932224,"origin_id":487930138,"user_origin_id":517644,"create_time":1556626851,"update_time":1556626851,"id":1669363651141,"updated_at":"2022-11-25T08:07:31.141000Z","created_at":"2022-11-25T08:07:31.141000Z"},{"_id":"638077c370db72139b110d60","body":"@ben18785 The first example works the same as the old now, but the second will need some tuning I think. Can you have a play around with it?\r\n\r\nIf all went well - the main difference between your code and my *non-parallelised* code is that your code assumed a very wide uniform log prior if the user didn't specify one, but didn't use this prior for initialisation (for which it used a multivariate gaussian instead, for some reason).\r\n\r\nIf you have time, please play around with the 2nd example and have a look at the code.\r\n\r\nHave also implemented parallelisation by doing batches of samples, as discussed. This reduces the performance somewhat. (On toy problems, it also slows everything down, because the overhead is much larger than the evaluation time of a single loglikelihood)\r\n\r\nLooking forward to merging this!","issue_id":1660245932224,"origin_id":495324328,"user_origin_id":517644,"create_time":1558634688,"update_time":1558634688,"id":1669363651144,"updated_at":"2022-11-25T08:07:31.144000Z","created_at":"2022-11-25T08:07:31.144000Z"},{"_id":"638077c370db72139b110d61","body":"There were some conflicts between this branch and master, so merged master _into this branch_, which is apparently the done thing in these situations!\r\nPart of merging master into this branch was resolving merge conflicts. After that, it should be easy to merge this branch into master, because they're the same!","issue_id":1660245932224,"origin_id":495372047,"user_origin_id":517644,"create_time":1558643150,"update_time":1558643150,"id":1669363651147,"updated_at":"2022-11-25T08:07:31.146000Z","created_at":"2022-11-25T08:07:31.146000Z"},{"_id":"638077c370db72139b110d62","body":"Tests & docs etc. in too now, have a look if you think the results are right @ben18785 :D :D ","issue_id":1660245932224,"origin_id":495791516,"user_origin_id":517644,"create_time":1558732904,"update_time":1558732904,"id":1669363651150,"updated_at":"2022-11-25T08:07:31.149000Z","created_at":"2022-11-25T08:07:31.149000Z"},{"_id":"638077c370db72139b110d63","body":"@ben18785 is this still something we need?","issue_id":1660245932224,"origin_id":1173901577,"user_origin_id":517644,"create_time":1656945930,"update_time":1656945930,"id":1669363651153,"updated_at":"2022-11-25T08:07:31.152000Z","created_at":"2022-11-25T08:07:31.152000Z"},{"_id":"638077c370db72139b110d64","body":"@ben18785 can this one go now that SMC is in via another PR?","issue_id":1660245932224,"origin_id":1308310030,"user_origin_id":517644,"create_time":1667977860,"update_time":1667977860,"id":1669363651156,"updated_at":"2022-11-25T08:07:31.155000Z","created_at":"2022-11-25T08:07:31.155000Z"},{"_id":"662bbf5c2186caae78094712","body":"Closing as this never ended up working!","issue_id":1660245932224,"origin_id":1810143479,"user_origin_id":4490664,"create_time":1699966128,"update_time":1699966128,"id":1714143068745,"updated_at":"2024-04-26T14:51:08.745000Z","created_at":"2024-04-26T14:51:08.745000Z"}]
~Still a work in progress, just need to update it to re-use a single chain and then it should be fine~ ~Looks to be working now~ Fixes #120
Sampler roadmap / overview
[{"_id":"638074f14b97542c9a3071fa","body":"@ben could you check if the bottom 6 are e.g. different names for ones above? Found them on github but not in the pyramid","issue_id":1660245932226,"origin_id":527487958,"user_origin_id":517644,"create_time":1567521466,"update_time":1567521466,"id":1669362929758,"updated_at":"2022-11-25T07:55:29.758000Z","created_at":"2022-11-25T07:55:29.758000Z"},{"_id":"638074f14b97542c9a3071fb","body":"Aha, here it is: https:\/\/github.com\/orgs\/pints-team\/projects\/1#card-15881685","issue_id":1660245932226,"origin_id":527488612,"user_origin_id":517644,"create_time":1567521559,"update_time":1569446727,"id":1669362929778,"updated_at":"2022-11-25T07:55:29.778000Z","created_at":"2022-11-25T07:55:29.778000Z"},{"_id":"638074f14b97542c9a3071fc","body":"Hi Michael, \r\n\r\nThanks! I've edited the comment to remove those methods I think are duplicates. Not sure what to call SIS MCMC -- it's an approach that can be applied to all samplers (and likelihood-based optimisers) essentially. Just involves heating the distribution, sampling from it, then reweighting based on importance weights. Can leave it as it stands for now though!","issue_id":1660245932226,"origin_id":528615923,"user_origin_id":4490664,"create_time":1567722558,"update_time":1567722558,"id":1669362929781,"updated_at":"2022-11-25T07:55:29.781000Z","created_at":"2022-11-25T07:55:29.781000Z"},{"_id":"638074f14b97542c9a3071fd","body":"Thanks!","issue_id":1660245932226,"origin_id":528617814,"user_origin_id":517644,"create_time":1567722919,"update_time":1567722919,"id":1669362929787,"updated_at":"2022-11-25T07:55:29.786000Z","created_at":"2022-11-25T07:55:29.786000Z"}]
Can't find an existing ticket for this, though sure we had one at some point. Classed as black, _blue_, and **red** in Ben's diagram Likelihood-free - [ ] _Hamiltonian ABC_...
priority
Add more optimisers
[{"_id":"6380673770db72139b10fc43","body":"This one sounds a bit different: https:\/\/link.springer.com\/article\/10.1007%2Fs10957-013-0354-0\r\nBut even the authors themselves didn't implement it...","issue_id":1660245932228,"origin_id":529093992,"user_origin_id":517644,"create_time":1567851286,"update_time":1567851286,"id":1669359415016,"updated_at":"2022-11-25T06:56:55.015000Z","created_at":"2022-11-25T06:56:55.015000Z"},{"_id":"6380673770db72139b10fc44","body":"Here's a book by those authors. Seems mostly classical again, although chapter 2 is on GAs which is encouraging https:\/\/www.amazon.com\/Derivative-Free-Optimization-Operations-Financial-Engineering\/dp\/3319689126\/ref=sr_1_1?keywords=derivative-free+and+black+box+optimization&qid=1567851546&s=gateway&sr=8-1","issue_id":1660245932228,"origin_id":529094386,"user_origin_id":517644,"create_time":1567851658,"update_time":1567851658,"id":1669359415018,"updated_at":"2022-11-25T06:56:55.018000Z","created_at":"2022-11-25T06:56:55.018000Z"},{"_id":"6380673770db72139b10fc45","body":"@martinjrobins says one of the [global optimisers](https:\/\/docs.scipy.org\/doc\/scipy\/reference\/optimize.html#global-optimization) in scipy is quite good:\r\n\r\n[\"Simplicial homology global optimization\", or SHGO](https:\/\/docs.scipy.org\/doc\/scipy\/reference\/generated\/scipy.optimize.shgo.html#scipy.optimize.shgo)","issue_id":1660245932228,"origin_id":552868135,"user_origin_id":517644,"create_time":1573560788,"update_time":1573560788,"id":1669359415021,"updated_at":"2022-11-25T06:56:55.020000Z","created_at":"2022-11-25T06:56:55.020000Z"},{"_id":"6380673770db72139b10fc46","body":"SHGO explanation and pseudocode here:\r\n\r\nhttps:\/\/stefan-endres.github.io\/shgo\/files\/shgo_defense.pdf\r\n\r\nsays convergence to the global minima is guaranteed for Lipschitz smooth\r\nfunctions, looks very mathsy!","issue_id":1660245932228,"origin_id":553495180,"user_origin_id":1148404,"create_time":1573664512,"update_time":1573664512,"id":1669359415023,"updated_at":"2022-11-25T06:56:55.023000Z","created_at":"2022-11-25T06:56:55.023000Z"},{"_id":"6380673770db72139b10fc47","body":"Looks interesting though!","issue_id":1660245932228,"origin_id":553498178,"user_origin_id":517644,"create_time":1573664928,"update_time":1573664928,"id":1669359415026,"updated_at":"2022-11-25T06:56:55.026000Z","created_at":"2022-11-25T06:56:55.026000Z"},{"_id":"6380673770db72139b10fc48","body":"DIRECT sounds worth a look: https:\/\/link.springer.com\/article\/10.1007\/s10898-020-00952-6","issue_id":1660245932228,"origin_id":847923126,"user_origin_id":517644,"create_time":1621953300,"update_time":1621953300,"id":1669359415029,"updated_at":"2022-11-25T06:56:55.029000Z","created_at":"2022-11-25T06:56:55.029000Z"},{"_id":"6380673770db72139b10fc49","body":"Some papers about global ones: https:\/\/link.springer.com\/search?query=&search-within=Journal&facet-journal-id=10898\r\n\r\nNot many entries in 2021 on our type of problem","issue_id":1660245932228,"origin_id":847944755,"user_origin_id":517644,"create_time":1621954910,"update_time":1621954910,"id":1669359415031,"updated_at":"2022-11-25T06:56:55.031000Z","created_at":"2022-11-25T06:56:55.031000Z"},{"_id":"6380673770db72139b10fc4a","body":"Good place to look: https:\/\/numbbo.github.io\/data-archive\/\r\n\r\nIn particular,\r\n- https:\/\/numbbo.github.io\/data-archive\/bbob-noisy\/\r\n- https:\/\/numbbo.github.io\/ppdata-archive\/","issue_id":1660245932228,"origin_id":1149766582,"user_origin_id":517644,"create_time":1654685787,"update_time":1654685907,"id":1669359415034,"updated_at":"2022-11-25T06:56:55.033000Z","created_at":"2022-11-25T06:56:55.033000Z"},{"_id":"6380673770db72139b10fc4b","body":"PSO with proofs: https:\/\/arxiv.org\/abs\/2205.04880\r\n\r\nhttps:\/\/github.com\/akashspace\/Consensus-based-opmization","issue_id":1660245932228,"origin_id":1154939304,"user_origin_id":517644,"create_time":1655198746,"update_time":1655199629,"id":1669359415036,"updated_at":"2022-11-25T06:56:55.036000Z","created_at":"2022-11-25T06:56:55.036000Z"}]
Creating a big ticket using the list from/for the paper, closing smaller issues. Ultimately, this should be closed in favour of much more specific tickets ("implement method x") # Optimisers...
new method