Cmdstan 2.24 release candidate now available

General
41

Great stuff Ben! Its always nice when someone does the work for you while sleeping :)

Will bisect stanc3, first trying the linked PR first thing today.

42

Is it possible that we should update the CmdStan User Guide instructions in the section “Rtools C++ Development Environment” due to RTools 4.0 requiring some additional quirks as I recall? mingw32-make is not directly available.

there is more…

1 Like
43

Confirmed. Reverting the PR now.

44

Using the current develop from cmdstan (which includes the fixes in Stan-math) together with the stanc3 from the PR which reverts 521, I am now again at

> dev_time
   user  system elapsed 
178.849   1.284 181.343

which should mean that these things fixed it.

So thanks for spotting and fixing all of this so quickly.

Should we do a rc-2 once 521 is reverted / resolved?

45

I dont think its required since we know what it affected and was not something complex.

@wds15 Thank you for spotting this! We really need https://github.com/stan-dev/stanc3/issues/636 and improved perf. tests.

46

Ok… no rc2… yes we need better performance tests for stanc3 and for math apparently.

I am happy to contribute the example above to any performance test suite…

47

We can do an rc2 if you think it would ve useful. I just feel we dont need to prolong the freeze as we came to the bottom of everything.

48

I didn’t say to prolong, so let’s just keep going. No urgent need to tag another rc probably.

49

Updated the CmdStan User’s guide by adding a section on C++ and GNU-Make for all platforms -
for Windows, cribbed off of @Max_Mantei’s excellent blog post - as always, feedback welcome - is the toolchain section too terse?

3 Likes
50

@Max_Mantei I used your tutorial to install cmdstanr on my computer, but the paths:

C:\RTools\RTools40\usr\bin
C:\RTools\RTools40\mingw64\bin

were:

C:\rtools40\usr\bin
C:\rtools40\mingw64\bin

by default for me (I reinstalled rtools to double check this is where it put things). Could there be a difference here somewhere?

Also I don’t think I needed those path modifications in the end (my rtools bash wasn’t picking up my system environment). There were three terminal options in my rtools start menu folder: rtools bash, rtools mingw64, and rtools mingw32. When I clicked rtools mingw64 it gave me a terminal where I could then do the pacman thing and make my way from there (it’s possible these terminals knew how to read my path – I’m not sure).

I was just guessing and checking to do this, which is why I’m asking cause maybe you know the lingo on these things better.

Also what’s the logic to us needing mingw32-make? Does that mean make was built with mingw32? Why not mingw64-make?

1 Like
51

BenBB2 asks good questions. also, install instructions are just for CmdStan, but should they anticipate and mention CmdStanR?

52

I think these are the default paths yes. Max does note that “You might have to change these lines to point to the correct location of your RTools 4.0 installation.”

This is what works with TBB for MinGW. That is why we did the change. Make was enough before that.

RTools 3.5 supplied mingw32-make by default. For RTools 4.0 you need to install it via pacman. pacman is the general way of installing any external lib for R 4.x users on Windows, so I think for cmdstanr users its not something out of the ordinary.

I think most users of cmdstan in cmdline are “power users” anyway so I dont think its a huge problem for them.

Two ways of working around haveing to use mingw32-make would be:

  • prebuild TBB dll for Windows (ship the .dll file like we do the stanc binary)
  • install tbb with Pacman on windows: basically pacman -Syu mingw-w64-x86_64-intel-tbb installs the TBB lib (currently 2020.2 which is newer than what we have)
  • install TBB with cmake (obviously requires us moving to cmake)

We should maybe think about this. One added bonus of any of the above approaches would be that Stan would work with clang++ on Windows (you can get it to work now, if you build TBB beforehand).

2 Likes
53

Hey Ben! I don’t think I have anything to add to what @rok_cesnovar said above. The PATH stuff was the only way to get everything to work on two of my laptops using install_cmdstanr().

I don’t, so there could be a better way of doing things.

@bbbales2, maybe you remember me. I’m the dude you had to babysit through using CmdStan the second part of the ODE class in the Saltmarsh room at Cambridge [thanks again for your help! :) ]. Not really a power user. hahah The intended audience for the blog post was mainly myself and people like me who really what to use cmdstan(r), but are not that familiar with setting everything up on their system. I’m happy it is useful to the people writing the docs. :)

54

To clarify, I meant users that use cmdstan in the command line not via cmdstanR, cmdstanpy interfaces.

With cmdstanr/py cmdstan was exposed to a wider audience, most of which is not familiar with the ins and outs of package managers, makefile flags, PATH environemnt variables and the like, which makes your blog post a very valuable resources! We are linking it everywhere we can :)

2 Likes
55

Yeah the pacman thing worked smoothly.

That it was!

1 Like
56

Are these new ODE functions available for rstan?

57

@nipnipj not currently. rstan is currently at version 2.21. It should be available in the near future.

If you wish to use these ODE functions right now you can use them via cmdstan or the cmdstanr and cmdstanpy wrapper interfaces. I believe its also available in the beta release of pystan.

1 Like
58

Btw, did we announce 2.24.1 on the blog?

1 Like
59

That is happening today.

3 Likes