There’s a PyStan 3 alpha available. It’s not ready for general use. It works well enough for me that I’m going to start using it for my day-to-day work. You can install the alpha release on most systems with python3 -m pip -pre install pystan. (No Windows support yet.)
I’d appreciate some help with the following items:
Try out eight schools and confirm things work on your machine.
Try out the new API and propose changes. The “spec” for the new API (which covers RStan and PyStan) is on the stan-dev wiki.
What’s new in PyStan 3
PyStan 3 is a rewrite. There’s a new user-facing API. Models and fits are automatically cached. Python 3.6 and higher is supported. The code has been simplified, making contributing more inviting.
User-facing changes
New interface.
Automatic caching of Stan models and fits.
Uses the same argument names as CmdStan (e.g., num_samples, num_warmup).
-DSTAN_THREADS by default.
Python 3.6+.
Developer-facing changes
Easier to maintain. 60% fewer lines of code.
Split into “front-end” and “back-end” packages, pystan and httpstan.
pystan is pure-Python, enabling faster development. (Running tests is ~80% faster.)
httpstan calls Stan C++ services functions and returns raw output.
I really meant to ask whether it could have a different name only during the current alpha/beta period when we may want to experiment with the new version but still use the old one for production code. Of course it’s possible to just set up virtualenv but (to me) separate names seems more straightforward.
Cool! And thanks for releasing a beta—we haven’t done enough of that in the past for big changes.
I see two alternatives on naming:
change name of the package to PyHttpStan or something so there’s no conflict
leave name the same and change version number—that has to be PyStan 3 to follow semantic versioning if it doesn’t have the same interface as the current PyStan
Option 2 might get confusing as PyStan 3 will come out ahead of Stan 3 (when we remove deprecared language features and make other backward compatibility breaking changes).
Thanks! We’re monitoring a Windows mingw crash issue here: https://github.com/stan-dev/httpstan/pull/142 . Perhaps it’s the same thing. We do have things working with Windows clang, I believe.
We are seeing the performance hit. I hope you’ll manage to fix it. :) I’ve been following the relevant PRs/issues.
I would say that there will be a stable beta release by the end of August. It will only support one mode of sampling (the recommended NUTS one). No support for VI or MAP in the beta release.
A few installation-related queries and issues (I’m on macOS Catalina):
I just tried pip install --pre pystan and it seemed to succeed, but pip created only the pystan-3.0.0.0a10.dist-info directory but not pystan itself!
Are there any hints or ideas for the coexistence of pystan 2 and pystan 3? I would prefer not to use virtual environments…
My idea (from above and also mentioned on GitHub) is to (temporarily) rename the package as (e.g.) pytstan3. This would enable users to have both installed at the same time without having to (e.g.) spawn separate virtual environments.
This is unrelated to version numbering: it is akin to the existence of python3 at the same time as python2==python for exactly this kind of purpose.
If having a distinct package name is important to you, you could create a fork of pystan with a new name. It’s all open source and permissively licensed.
Any update on this?
I’ve just installed the beta version (pystan 3.0.0b4) on Linux using pip install --pre pystan and I have the same “module not found” issue.