Stan 2.19 release planned for Monday March 18th

Thank you for the documents!

It seems that the description about integrate_1d has been deleted.


Is there any plan to describe it again? I want to try it.

moved, not deleted - a while back it seemed like a good idea to put the Stan docs into a separate repo: https://github.com/stan-dev/docs

integrate_1d is described in the Stan Reference Manual:

Thanks!

@avehtari - Is there any (approximate) timeline for RStan to upgrade? (Apologies if I’m being pushy - I’m just trying to plan when I can re-start a project that’s waiting on this.)

1 Like

agreed - there’s a mountain of technical debt around the csv and the output from the services. I just spent the weekend code-spelunking through the cmdstan utilities for different reasons - in the end I gave up on what I was trying to do and will find workarounds. I think this will run into similar problems.

(earlier typo, now corrected: s/workabounds/workarounds/ - to paraphrase Siggie, there are no typos.)

I don’t have an exact answer. Stan 2.19 adds log_p__ and log_g__ when using advi. These appear in CmdStan 2.19 produced csv. These will appar in RStan 2.19 stanfit object in a slot named diagnostics. That’s all in 2.19. log_p__ and log_g__ can be used to compute Pareto k diagnostic. You can compute that diagnostic yourself both in case of CmdStan 2.19 and RStan 2.19. Maybe in a future release Pareto k diagnostic is added to Stan services in C++, so that summary function for CmdStan can compute that diagnostic. RStan can use Pareto k diagnostic from loo package, as RStan is relying on loo package anyway, but maybe that computation could also somewhere else. I don’t know.

I don’t know. @bgoodri might know, but there is likely to be uncertainty due to the complexity of RStan releases.

1 Like

This week

7 Likes

I suspect this isn’t the correct place to request it (and if not, I would appreciate a pointer to where would be better!), but it would be very useful if the documentation contained information about the changes from previous versions (beyond the “deprecations” sections).

You can find that in the release notes on GitHub: https://github.com/stan-dev/stan/releases

Yes, but I suppose a more user-friendly version would also be useful since to actually understand this required looking back through commits, etc., whereas a list of bullet points with a little more detail in the text would probably satisfy most users in a form that would actually put the list of new possible tools/operations/functions right in front of us where we are already looking. I.e., this is actually important to “average” users who came to Stan at an earlier version, and it shouldn’t require navigating GitHub to get it.

On the other hand, I completely appreciate that this is an actual development burden I am requesting, and so appreciate that it is not high priority (or it would have been requested sooner).

I’ve asked the community to start creating more user-informative pull request titles going forward, which should help with that a bit. Maybe someone wants to volunteer to write up more detailed reports with a specific audience in mind - we’d be happy to add such a thing to the release notes. We only had one such thing so far (GPU intro by Erik).

1 Like

For the Math library, I’d prefer the issues to be clearly described. They should describe what the feature / bug is and the PR should describe how it’s being addressed (implementation details, design of code, etc.). In other words, the issues should be more user-facing, the pull requests should be more developer-facing.

That works too.

I think I don’t know that one. I’ve been looking for something like that. Where can it be found?

There’s no tutorial yet, just the release announcement earlier in this thread.

There was a performance bug with individual matrix element access in 2.19.0 (see this thread for details) On Thursday at 1pm NYC time I’ll do a full release with whatever commit last passed all of the tests up and down the repos, which will either be 2.20.0 or 2.19.1 depending on if we have new features or just bug fixes, respectively.

I guess this didn’t happen? Any new estimate for a release date?

We had 2.19.0 on March 20th and 2.19.1 on April 18th: https://github.com/stan-dev/cmdstan/releases Looks like both RStan and PyStan are behind.

2 Likes

I missed or forgot about 2.19.1.

Can we do a new release soon? There are two things which would be great to get in (for PyStan specifically):

The next release will be something like July 18th - in general, three months after the last release other than when we have major bugs.