search

stan-dev / stan

Stan development repository. The master branch contains the current release. The develop branch contains the latest stable development. See the Developer Process Wiki for details.
https://mc-stan.org
BSD 3-Clause "New" or "Revised" License
2.56k stars 365 forks source link

Switch to C++11 #714

Closed bgoodri closed 8 years ago

bgoodri commented 10 years ago

We should consider forcing -std=c++11. This would make g++-4.6.3 the oldest supported compiler and cause at least the following problems:

See https://wiki.apache.org/stdcxx/C++0xCompilerSupport

aadler commented 10 years ago

As long as you support whatever is current in Rtools (4.6.3 as of now). According to Duncan Murdoch, keeper of Rtools, when MinGW-64 finishes its updating to 4.8.x, Rtools will follow shortly.

bgoodri commented 10 years ago

That would enable us to use more features but uses a lot more RAM. Looks like Python on Windows is the biggest concern. The Anaconda website

http://docs.continuum.io/anaconda/

says Python 3.3/4 are "available". Does available mean viable with VS 2012?

On Thu, Jun 26, 2014 at 7:22 PM, Avraham Adler notifications@github.com wrote:

As long as you support whatever is current in Rtools (4.6.3 as of now). According to Duncan Murdoch, keeper of Rtools, when MinGW-64 finishes its updating to 4.8.x, Rtools will follow shortly.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-47292293.

ariddell commented 10 years ago

I don't think Python 2.x on Windows should hold back the switch to C++11. The main concern is that support for Python 3 is only gradually emerging on Windows. The lack of a 64-bit compiler (MinGW-64 would be used for Python as well) is also a concern.

I think it would be nice to give the Python 2.7 Windows users out there fair warning that they need to upgrade to Python 3 and a new compiler. There probably are still a fair number of such users out there and Anaconda has only recently started to have robust support for Python 3.

bgoodri commented 10 years ago

Maybe we should wait for Rtools to upgrade? That would possibly permit @bob-carpenter to do multithreading without Boost

bgoodri commented 10 years ago

@aadler : Do you have a link to a definitive statement by Duncan about Rtools?

aadler commented 10 years ago

@bgoodri I have an e-mail from him on May 29, 2014 which I have transcribed below:

On 30/05/2014, 12:57 AM, Avraham Adler wrote:

Good morning, Dr. Murdoch. Are there plans for Rtools for Windows to be updated to use gcc 4.8.x?

Currently MinGW-64 (the build we use) is in the process of updating; when that is available, we will likely update Rtools.

I can forward the e-mail for verification if you would like.

bgoodri commented 10 years ago

That's fine. It sounds eminent enough for Stan to wait on the switch to C++11.

On Fri, Jun 27, 2014 at 1:51 PM, Avraham Adler notifications@github.com wrote:

@bgoodri https://github.com/bgoodri I have an e-mail from him on May 29, 2014 which I have transcribed below:

On 30/05/2014, 12:57 AM, Avraham Adler wrote:

Good morning, Dr. Murdoch. Are there plans for Rtools for Windows to be updated to use gcc 4.8.x? Currently MinGW-64 (the build we use) is in the process of updating; when that is available, we will likely update Rtools.

I can forward the e-mail for verification if you would like.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-47379933.

bgoodri commented 10 years ago

@ariddell : Would it be feasible to make a pystan binary package (at least for Windows) available via Binstar?

http://continuum.io/blog/binstar

Maybe this would reduce the pain of forcing C++11 whenever Rtools updates mingw?

ariddell commented 10 years ago

Thanks for the link to the blog post.

There is a binary package available for pystan for Windows through continuum's system (just plain conda, not binstar, AFAIK). I don't think it would help with the C++11 issue since they'll still need a C++11 compiler to compile the models, right?

bgoodri commented 10 years ago

I guess I was wondering if we put a pystan binary onto binstar that is compiled with whatever version of Visual Studio has C++11 support, then we could tell Windows pystan users to use that version of Visual Studio to compile their models.

On Thu, Jul 17, 2014 at 4:39 PM, Allen Riddell notifications@github.com wrote:

Thanks for the link to the blog post.

There is a binary package available for pystan for Windows through continuum's system (just plain conda, not binstar, AFAIK). I don't think it would help with the C++11 issue since they'll still need a C++11 compiler to compile the models, right?

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49362409.

ariddell commented 10 years ago

I'm not sure about all the issues here. I gather there's some question of what compiler was used to compile Python itself.

If Python 2.7 on Windows is the only stumbling block, I don't think that should stop the switch.

bgoodri commented 10 years ago

If possible, we would rather not leave PyStan users on Windows stuck on 2.x with no upgrade path. Do we know what are the issues with running PyStan under Python 3.4 via conda?

On Thu, Jul 17, 2014 at 5:04 PM, Allen Riddell notifications@github.com wrote:

I'm not sure about all the issues here. I gather there's some question of what compiler was used to compile Python itself.

If Python 2.7 on Windows is the only stumbling block, I don't think that should stop the switch.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49365421.

ariddell commented 10 years ago

I've read a bit more about this. If we can support Visual Studio 2010 (which has some C++11 features), then Python 3 support for Windows looks like it should not be a problem. Python 2.7 may or may not be a lost cause, but I don't feel too bad about this. Those who want to use Stan on Windows and don't want to use Python 3 can, at minimum, use RStan and do analysis of the .csv file in Python 2.7. They can also use CmdStan.

(It also seems clear that, for Python, MinGW will not be helpful for some time.)

I think the steps to take are:

[ ] Test compilation of Stan on Jenkins using Visual Studio 2008 (for 2.4) [ ] Test compilation of Stan on Jenkins using Visual Studio 2010 (for 2.4) [ ] Test compilation of Stan on Jenkins using Visual Studio 2010 with c++11 on (for 2.4+)

How does that sound? (Is Windows compilation already being tested for any version of Visual Studio?)

I'll email Daniel about this and try to work on it next week. I have a Windows virtual machine so this is easier for me than dealing with Mac OS issues.

On 07/17, bgoodri wrote:

If possible, we would rather not leave PyStan users on Windows stuck on 2.x with no upgrade path. Do we know what are the issues with running PyStan under Python 3.4 via conda?

On Thu, Jul 17, 2014 at 5:04 PM, Allen Riddell notifications@github.com wrote:

I'm not sure about all the issues here. I gather there's some question of what compiler was used to compile Python itself.

If Python 2.7 on Windows is the only stumbling block, I don't think that should stop the switch.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49365421.

Reply to this email directly or view it on GitHub: https://github.com/stan-dev/stan/issues/714#issuecomment-49390727

ariddell commented 10 years ago

Here's a table of the C++11 features that Visual Studio 2010, 2012, and 2013 support:

http://msdn.microsoft.com/en-us/library/hh567368.aspx

On 07/17, bgoodri wrote:

If possible, we would rather not leave PyStan users on Windows stuck on 2.x with no upgrade path. Do we know what are the issues with running PyStan under Python 3.4 via conda?

On Thu, Jul 17, 2014 at 5:04 PM, Allen Riddell notifications@github.com wrote:

I'm not sure about all the issues here. I gather there's some question of what compiler was used to compile Python itself.

If Python 2.7 on Windows is the only stumbling block, I don't think that should stop the switch.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49365421.

Reply to this email directly or view it on GitHub: https://github.com/stan-dev/stan/issues/714#issuecomment-49390727

bgoodri commented 10 years ago

That seems like a good plan. I don't think Visual Studio is tested at all currently, but someone on stan-users got something to work

https://groups.google.com/d/msg/stan-users/A_WcImpwaYA/TlPQGMnrCi4J

On Fri, Jul 18, 2014 at 8:28 AM, Allen Riddell notifications@github.com wrote:

I've read a bit more about this. If we can support Visual Studio 2010 (which has some C++11 features), then Python 3 support for Windows looks like it should not be a problem. Python 2.7 may or may not be a lost cause, but I don't feel too bad about this. Those who want to use Stan on Windows and don't want to use Python 3 can, at minimum, use RStan and do analysis of the .csv file in Python 2.7. They can also use CmdStan.

(It also seems clear that, for Python, MinGW will not be helpful for some time.)

I think the steps to take are:

[ ] Test compilation of Stan on Jenkins using Visual Studio 2008 (for 2.4) [ ] Test compilation of Stan on Jenkins using Visual Studio 2010 (for 2.4) [ ] Test compilation of Stan on Jenkins using Visual Studio 2010 with c++11 on (for 2.4+)

How does that sound? (Is Windows compilation already being tested for any version of Visual Studio?)

I'll email Daniel about this and try to work on it next week. I have a Windows virtual machine so this is easier for me than dealing with Mac OS issues.

On 07/17, bgoodri wrote:

If possible, we would rather not leave PyStan users on Windows stuck on 2.x with no upgrade path. Do we know what are the issues with running PyStan under Python 3.4 via conda?

On Thu, Jul 17, 2014 at 5:04 PM, Allen Riddell <notifications@github.com

wrote:

I'm not sure about all the issues here. I gather there's some question of what compiler was used to compile Python itself.

If Python 2.7 on Windows is the only stumbling block, I don't think that should stop the switch.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49365421.

Reply to this email directly or view it on GitHub: https://github.com/stan-dev/stan/issues/714#issuecomment-49390727

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49425021.

ariddell commented 10 years ago

If Stan with C++11 features compiles under Visual Studio 2010 then all is well for Python 3 Windows users. If not, there's a risk that Windows users will not be able to use PyStan.

From talking to Patrick Snape it sounds like the real concern is the library. Python 3 under Windows is compiled with a Visual Studio 2010 C++ standard library, housed in msvcrt##.dll. When compiling a Python extension under Windows it is this library that one needs to ensure compatibility with. So even if one had a Visual Studio 2013 compiler, the Visual Studio 2013 msvcrt##.dll would be a different one than that used to compile Python 3.

bob-carpenter commented 10 years ago

Sorry if this has been answered, but is Python 3 the only way to get C++11 on Windows? That is, no Python 2?

I wouldn't want to lock Windows users out of PyStan altogether.

But then I don't want to wait forever to go to C++11, because there are lots of great efficiency and convenience features in it.

On Jul 22, 2014, at 4:11 PM, Allen Riddell notifications@github.com wrote:

If Stan with C++11 features compiles under Visual Studio 2010 then all is well for Python 3 Windows users. If not, there's a risk that Windows users will not be able to use PyStan.

From talking to Patrick Snape it sounds like the real concern is the library. Python 3 under Windows is compiled with a Visual Studio 2010 C++ standard library, housed in msvcrt##.dll. When compiling a Python extension under Windows it is this library that one needs to ensure compatibility with. So even if one had a Visual Studio 2013 compiler, the Visual Studio 2013 msvcrt##.dll would be a different one than that used to compile Python 3.

— Reply to this email directly or view it on GitHub.

bgoodri commented 10 years ago

Short of users compiling Python themselves, I think it is impossible to have C++11 with Python 2.x because Anacanda compiles Python with VS 2008. But even with Python 3.x, which is compiled with VS 2010, the C++11 support is very incomplete. So, we wouldn't be able to use that much of C++11 in g++, clang++, or mingw (whenever Rtools uses the version based on g++-4.8).

On Wed, Jul 23, 2014 at 12:12 AM, Bob Carpenter notifications@github.com wrote:

Sorry if this has been answered, but is Python 3 the only way to get C++11 on Windows? That is, no Python 2?

I wouldn't want to lock Windows users out of PyStan altogether.

But then I don't want to wait forever to go to C++11, because there are lots of great efficiency and convenience features in it.

  • Bob

On Jul 22, 2014, at 4:11 PM, Allen Riddell notifications@github.com wrote:

If Stan with C++11 features compiles under Visual Studio 2010 then all is well for Python 3 Windows users. If not, there's a risk that Windows users will not be able to use PyStan.

From talking to Patrick Snape it sounds like the real concern is the library. Python 3 under Windows is compiled with a Visual Studio 2010 C++ standard library, housed in msvcrt##.dll. When compiling a Python extension under Windows it is this library that one needs to ensure compatibility with. So even if one had a Visual Studio 2013 compiler, the Visual Studio 2013 msvcrt##.dll would be a different one than that used to compile Python 3.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49831159.

bob-carpenter commented 10 years ago

Can we really plan to drop PyStan 2.x for Windows users?

Or drop PyStan for all Windows users?

Either one seems really drastic. Is there any plan to update 2.x for C++11? Or update 3.x for a more full-featured C++11 compiler?

On Jul 23, 2014, at 12:38 AM, bgoodri notifications@github.com wrote:

Short of users compiling Python themselves, I think it is impossible to have C++11 with Python 2.x because Anacanda compiles Python with VS 2008. But even with Python 3.x, which is compiled with VS 2010, the C++11 support is very incomplete. So, we wouldn't be able to use that much of C++11 in g++, clang++, or mingw (whenever Rtools uses the version based on g++-4.8).

On Wed, Jul 23, 2014 at 12:12 AM, Bob Carpenter notifications@github.com wrote:

Sorry if this has been answered, but is Python 3 the only way to get C++11 on Windows? That is, no Python 2?

I wouldn't want to lock Windows users out of PyStan altogether.

But then I don't want to wait forever to go to C++11, because there are lots of great efficiency and convenience features in it.

  • Bob

On Jul 22, 2014, at 4:11 PM, Allen Riddell notifications@github.com wrote:

If Stan with C++11 features compiles under Visual Studio 2010 then all is well for Python 3 Windows users. If not, there's a risk that Windows users will not be able to use PyStan.

From talking to Patrick Snape it sounds like the real concern is the library. Python 3 under Windows is compiled with a Visual Studio 2010 C++ standard library, housed in msvcrt##.dll. When compiling a Python extension under Windows it is this library that one needs to ensure compatibility with. So even if one had a Visual Studio 2013 compiler, the Visual Studio 2013 msvcrt##.dll would be a different one than that used to compile Python

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49831159.

— Reply to this email directly or view it on GitHub.

ariddell commented 10 years ago

I imagine the landscape will change in the medium-term because people do want to use C++11 in extensions. MinGW, for example, might change things.

From what I'm told, I think it's likely that C++11 features will break PyStan for Python 2.7 users.

For Python 3, I think it's a matter of testing. We're safe if Stan only uses Visual Studio 2010 supported C++11 features and one might discover some workaround where one uses Visual Studio 2013 to compile extensions. From what I could tell, nobody has tried this.

I think it sends a very good signal to support Windows in some form and I think we might want to try to figure out some solution for Python 3. I'm not worried about Python 2.7 right now because the widely used Python technical computing stack (Anaconda) now supports Python 3 much more fully than it did even six months ago.

bgoodri commented 10 years ago

An alternative (not a great alternative) would be to force Windows PyStan users to use Cygwin.

Or, this website

http://p-nand-q.com/python/building-python-33-with-vs2013.html

seems to have compiled Python with VS 2013 and they have Cython and pip modules at the bottom. I don't know how easy it would be to install PyStan into that.

On Wed, Jul 23, 2014 at 6:22 AM, Allen Riddell notifications@github.com wrote:

I imagine the landscape will change in the medium-term because people do want to use C++11 in extensions. MinGW, for example, might change things.

From what I'm told, I think it's likely that C++11 features will break PyStan for Python 2.7 users.

For Python 3, I think it's a matter of testing. We're safe if Stan only uses Visual Studio 2010 supported C++11 features and one might discover some workaround where one uses Visual Studio 2013 to compile extensions. From what I could tell, nobody has tried this.

I think it sends a very good signal to support Windows in some form and I think we might want to try to figure out some solution for Python 3. I'm not worried about Python 2.7 right now because the widely used Python technical computing stack (Anaconda) now supports Python 3 much more fully than it did even six months ago.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49856560.

ariddell commented 10 years ago

That looks good. This is the kind of thing that I imagine will eventually gain wider acceptance. For example, I suspect Anaconda (the distribution most Windows users use) will switch to something like this before too long and our problems will be solved.

How urgent is the switch to C++11? I think we should at least give fair warning to Windows users about (temporarily, I hope) dropping them.

bgoodri commented 10 years ago

I think at a minimum we should wait until Rtools includes a mingw based on g++-4.8 before we start adding any C++11 code.

On Wed, Jul 23, 2014 at 11:15 AM, Allen Riddell notifications@github.com wrote:

That looks good. This is the kind of thing that I imagine will eventually gain wider acceptance. For example, I suspect Anaconda (the distribution most Windows users use) will switch to something like this before too long and our problems will be solved.

How urgent is the switch to C++11? I think we should at least give fair warning to Windows users about (temporarily, I hope) dropping them.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49888086.

bob-carpenter commented 10 years ago

There's nothing on the planning radar that requires C++11. It'd just be nice to have.

I'll leave Michael to comment on stuff he's working on --- I think he's the most keen to get C++11 features.

On Jul 23, 2014, at 11:19 AM, bgoodri notifications@github.com wrote:

I think at a minimum we should wait until Rtools includes a mingw based on g++-4.8 before we start adding any C++11 code.

On Wed, Jul 23, 2014 at 11:15 AM, Allen Riddell notifications@github.com wrote:

That looks good. This is the kind of thing that I imagine will eventually gain wider acceptance. For example, I suspect Anaconda (the distribution most Windows users use) will switch to something like this before too long and our problems will be solved.

How urgent is the switch to C++11? I think we should at least give fair warning to Windows users about (temporarily, I hope) dropping them.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49888086.

— Reply to this email directly or view it on GitHub.

betanalpha commented 10 years ago

C++11 reduces a huge amount of Boost dependencies. The new autodiff will require it, I don't particularly care about anything else as Boost is already deeply integrated into Stan.

On Wed, Jul 23, 2014 at 4:45 PM, Bob Carpenter notifications@github.com wrote:

There's nothing on the planning radar that requires C++11. It'd just be nice to have.

I'll leave Michael to comment on stuff he's working on --- I think he's the most keen to get C++11 features.

  • Bob

On Jul 23, 2014, at 11:19 AM, bgoodri notifications@github.com wrote:

I think at a minimum we should wait until Rtools includes a mingw based on g++-4.8 before we start adding any C++11 code.

On Wed, Jul 23, 2014 at 11:15 AM, Allen Riddell < notifications@github.com> wrote:

That looks good. This is the kind of thing that I imagine will eventually gain wider acceptance. For example, I suspect Anaconda (the distribution most Windows users use) will switch to something like this before too long and our problems will be solved.

How urgent is the switch to C++11? I think we should at least give fair warning to Windows users about (temporarily, I hope) dropping them.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49888086.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49892613.

bob-carpenter commented 10 years ago

If that's the only reason, then I'd say stick with Boost.

A lot of packages are going to be slow in catching up to C++11, so requiring it will put a damper on its use more than requiring Boost will.

As you saw from RStan, it's possible to trim down the Boost lib so you don't need to distribute it all if we make a standalone autodiff package.

Also, as far as Stan itself goes, we don't care about Boost dependencies because we're already all-in on that front.

Another solution might be to make the new autodiff optional in Stan (no fast higher-order autodiff) without C++11. I don't have a good sense of how hard that would be to finagle on the build side.

On Jul 23, 2014, at 12:41 PM, Michael Betancourt notifications@github.com wrote:

C++11 reduces a huge amount of Boost dependencies. The new autodiff will require it, I don't particularly care about anything else as Boost is already deeply integrated into Stan.

On Wed, Jul 23, 2014 at 4:45 PM, Bob Carpenter notifications@github.com wrote:

There's nothing on the planning radar that requires C++11. It'd just be nice to have.

I'll leave Michael to comment on stuff he's working on --- I think he's the most keen to get C++11 features.

  • Bob

On Jul 23, 2014, at 11:19 AM, bgoodri notifications@github.com wrote:

I think at a minimum we should wait until Rtools includes a mingw based on g++-4.8 before we start adding any C++11 code.

On Wed, Jul 23, 2014 at 11:15 AM, Allen Riddell < notifications@github.com> wrote:

That looks good. This is the kind of thing that I imagine will eventually gain wider acceptance. For example, I suspect Anaconda (the distribution most Windows users use) will switch to something like this before too long and our problems will be solved.

How urgent is the switch to C++11? I think we should at least give fair warning to Windows users about (temporarily, I hope) dropping them.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49888086.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49892613.

— Reply to this email directly or view it on GitHub.

bgoodri commented 10 years ago

Are we envisioning releasing the autodiff thing standalone with the shared library compiled under the C++11 standard? And things that link to it can be compiled without a standard?

I feel like we either have very few PyStan Windows users or they never encounter problems because they never post on stan-users. So, if there is technically some documentable way to do PyStan on Windows with C++11 (cygwin, the p-and-q Python binary, compiling Python yourself, etc.), then maybe we should go ahead. We've pretty much abandoned RHEL servers with g++ < 4.5, which seems to be a similarly sized group.

On Wed, Jul 23, 2014 at 1:00 PM, Bob Carpenter notifications@github.com wrote:

If that's the only reason, then I'd say stick with Boost.

A lot of packages are going to be slow in catching up to C++11, so requiring it will put a damper on its use more than requiring Boost will.

As you saw from RStan, it's possible to trim down the Boost lib so you don't need to distribute it all if we make a standalone autodiff package.

Also, as far as Stan itself goes, we don't care about Boost dependencies because we're already all-in on that front.

Another solution might be to make the new autodiff optional in Stan (no fast higher-order autodiff) without C++11. I don't have a good sense of how hard that would be to finagle on the build side.

  • Bob

On Jul 23, 2014, at 12:41 PM, Michael Betancourt notifications@github.com wrote:

C++11 reduces a huge amount of Boost dependencies. The new autodiff will require it, I don't particularly care about anything else as Boost is already deeply integrated into Stan.

On Wed, Jul 23, 2014 at 4:45 PM, Bob Carpenter notifications@github.com

wrote:

There's nothing on the planning radar that requires C++11. It'd just be nice to have.

I'll leave Michael to comment on stuff he's working on --- I think he's the most keen to get C++11 features.

  • Bob

On Jul 23, 2014, at 11:19 AM, bgoodri notifications@github.com wrote:

I think at a minimum we should wait until Rtools includes a mingw based on g++-4.8 before we start adding any C++11 code.

On Wed, Jul 23, 2014 at 11:15 AM, Allen Riddell < notifications@github.com> wrote:

That looks good. This is the kind of thing that I imagine will eventually gain wider acceptance. For example, I suspect Anaconda (the distribution most Windows users use) will switch to something like this before too long and our problems will be solved.

How urgent is the switch to C++11? I think we should at least give fair warning to Windows users about (temporarily, I hope) dropping them.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49888086.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49892613.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49903191.

bob-carpenter commented 10 years ago

On Jul 23, 2014, at 4:04 PM, bgoodri notifications@github.com wrote:

Are we envisioning releasing the autodiff thing standalone

Yes. Both the existing one and the new one. I think it's a good idea because a lot of people want to use autodiff and our existing one is awesome for gradients and the new one's awesome at higher order (and even more awesome than our existing one for some gradients, while slower for others).

with the shared library compiled under the C++11 standard?

I'm not sure I understand what a shared library is.

When the new library is integrated into Stan, Stan will get a C++11 dependency, so we'll only do it when that is feasible.

And things that link to it can be compiled without a standard?

I'm not sure what you mean by without a standard.

I feel like we either have very few PyStan Windows users or they never encounter problems because they never post on stan-users. So, if there is technically some documentable way to do PyStan on Windows with C++11 (cygwin, the p-and-q Python binary, compiling Python yourself, etc.), then maybe we should go ahead. We've pretty much abandoned RHEL servers with g++ < 4.5, which seems to be a similarly sized group.

Most of the code we get is from R, so I'm not sure how many PyStan users there are on any platform. But it may just mean that R is harder to code in for the people who use R and/or that it's harder to install.

bgoodri commented 10 years ago

If the most awesome autodiff library would be held back due to lack of C++11 support, then I think we should move to C++11 for Stan 3.0. But it might be the case that libnomad.so (or whatever it ends up being called) can be compiled with --std=c++11 and the user's model can be compiled with -Lnomad but without --std=c++11.

But, which aspect(s) of the C++11 standard is/are being used by nomad? Because VS 2010 has pretty incomplete support for it, VS 2012 is decent, and VS 2013 is pretty good but still not complete.

On Wed, Jul 23, 2014 at 4:53 PM, Bob Carpenter notifications@github.com wrote:

On Jul 23, 2014, at 4:04 PM, bgoodri notifications@github.com wrote:

Are we envisioning releasing the autodiff thing standalone

Yes. Both the existing one and the new one. I think it's a good idea because a lot of people want to use autodiff and our existing one is awesome for gradients and the new one's awesome at higher order (and even more awesome than our existing one for some gradients, while slower for others).

with the shared library compiled under the C++11 standard?

I'm not sure I understand what a shared library is.

When the new library is integrated into Stan, Stan will get a C++11 dependency, so we'll only do it when that is feasible.

And things that link to it can be compiled without a standard?

I'm not sure what you mean by without a standard.

I feel like we either have very few PyStan Windows users or they never encounter problems because they never post on stan-users. So, if there is technically some documentable way to do PyStan on Windows with C++11 (cygwin, the p-and-q Python binary, compiling Python yourself, etc.), then maybe we should go ahead. We've pretty much abandoned RHEL servers with g++ < 4.5, which seems to be a similarly sized group.

Most of the code we get is from R, so I'm not sure how many PyStan users there are on any platform. But it may just mean that R is harder to code in for the people who use R and/or that it's harder to install.

  • Bob

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49933702.

betanalpha commented 10 years ago

Nomad is header only — no shared library.

On Jul 23, 2014, at 10:02 PM, bgoodri notifications@github.com wrote:

If the most awesome autodiff library would be held back due to lack of C++11 support, then I think we should move to C++11 for Stan 3.0. But it might be the case that libnomad.so (or whatever it ends up being called) can be compiled with --std=c++11 and the user's model can be compiled with -Lnomad but without --std=c++11.

But, which aspect(s) of the C++11 standard is/are being used by nomad? Because VS 2010 has pretty incomplete support for it, VS 2012 is decent, and VS 2013 is pretty good but still not complete.

On Wed, Jul 23, 2014 at 4:53 PM, Bob Carpenter notifications@github.com wrote:

On Jul 23, 2014, at 4:04 PM, bgoodri notifications@github.com wrote:

Are we envisioning releasing the autodiff thing standalone

Yes. Both the existing one and the new one. I think it's a good idea because a lot of people want to use autodiff and our existing one is awesome for gradients and the new one's awesome at higher order (and even more awesome than our existing one for some gradients, while slower for others).

with the shared library compiled under the C++11 standard?

I'm not sure I understand what a shared library is.

When the new library is integrated into Stan, Stan will get a C++11 dependency, so we'll only do it when that is feasible.

And things that link to it can be compiled without a standard?

I'm not sure what you mean by without a standard.

I feel like we either have very few PyStan Windows users or they never encounter problems because they never post on stan-users. So, if there is technically some documentable way to do PyStan on Windows with C++11 (cygwin, the p-and-q Python binary, compiling Python yourself, etc.), then maybe we should go ahead. We've pretty much abandoned RHEL servers with g++ < 4.5, which seems to be a similarly sized group.

Most of the code we get is from R, so I'm not sure how many PyStan users there are on any platform. But it may just mean that R is harder to code in for the people who use R and/or that it's harder to install.

  • Bob

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49933702.

— Reply to this email directly or view it on GitHub.

bgoodri commented 10 years ago

Good, but what features of C++11 would be utilized when compiling it?

On Wed, Jul 23, 2014 at 5:06 PM, Michael Betancourt < notifications@github.com> wrote:

Nomad is header only — no shared library.

On Jul 23, 2014, at 10:02 PM, bgoodri notifications@github.com wrote:

If the most awesome autodiff library would be held back due to lack of C++11 support, then I think we should move to C++11 for Stan 3.0. But it might be the case that libnomad.so (or whatever it ends up being called) can be compiled with --std=c++11 and the user's model can be compiled with -Lnomad but without --std=c++11.

But, which aspect(s) of the C++11 standard is/are being used by nomad? Because VS 2010 has pretty incomplete support for it, VS 2012 is decent, and VS 2013 is pretty good but still not complete.

On Wed, Jul 23, 2014 at 4:53 PM, Bob Carpenter notifications@github.com

wrote:

On Jul 23, 2014, at 4:04 PM, bgoodri notifications@github.com wrote:

Are we envisioning releasing the autodiff thing standalone

Yes. Both the existing one and the new one. I think it's a good idea because a lot of people want to use autodiff and our existing one is awesome for gradients and the new one's awesome at higher order (and even more awesome than our existing one for some gradients, while slower for others).

with the shared library compiled under the C++11 standard?

I'm not sure I understand what a shared library is.

When the new library is integrated into Stan, Stan will get a C++11 dependency, so we'll only do it when that is feasible.

And things that link to it can be compiled without a standard?

I'm not sure what you mean by without a standard.

I feel like we either have very few PyStan Windows users or they never encounter problems because they never post on stan-users. So, if there is technically some documentable way to do PyStan on Windows with C++11 (cygwin, the p-and-q Python binary, compiling Python yourself, etc.), then maybe we should go ahead. We've pretty much abandoned RHEL servers with g++ < 4.5, which seems to be a similarly sized group.

Most of the code we get is from R, so I'm not sure how many PyStan users there are on any platform. But it may just mean that R is harder to code in for the people who use R and/or that it's harder to install.

  • Bob

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49933702.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49935615.

betanalpha commented 10 years ago

Of the top of my head, the expanded math libraries, the type trait libraries, auto.

On Jul 23, 2014, at 10:09 PM, bgoodri notifications@github.com wrote:

Good, but what features of C++11 would be utilized when compiling it?

On Wed, Jul 23, 2014 at 5:06 PM, Michael Betancourt < notifications@github.com> wrote:

Nomad is header only — no shared library.

On Jul 23, 2014, at 10:02 PM, bgoodri notifications@github.com wrote:

If the most awesome autodiff library would be held back due to lack of C++11 support, then I think we should move to C++11 for Stan 3.0. But it might be the case that libnomad.so (or whatever it ends up being called) can be compiled with --std=c++11 and the user's model can be compiled with -Lnomad but without --std=c++11.

But, which aspect(s) of the C++11 standard is/are being used by nomad? Because VS 2010 has pretty incomplete support for it, VS 2012 is decent, and VS 2013 is pretty good but still not complete.

On Wed, Jul 23, 2014 at 4:53 PM, Bob Carpenter notifications@github.com

wrote:

On Jul 23, 2014, at 4:04 PM, bgoodri notifications@github.com wrote:

Are we envisioning releasing the autodiff thing standalone

Yes. Both the existing one and the new one. I think it's a good idea because a lot of people want to use autodiff and our existing one is awesome for gradients and the new one's awesome at higher order (and even more awesome than our existing one for some gradients, while slower for others).

with the shared library compiled under the C++11 standard?

I'm not sure I understand what a shared library is.

When the new library is integrated into Stan, Stan will get a C++11 dependency, so we'll only do it when that is feasible.

And things that link to it can be compiled without a standard?

I'm not sure what you mean by without a standard.

I feel like we either have very few PyStan Windows users or they never encounter problems because they never post on stan-users. So, if there is technically some documentable way to do PyStan on Windows with C++11 (cygwin, the p-and-q Python binary, compiling Python yourself, etc.), then maybe we should go ahead. We've pretty much abandoned RHEL servers with g++ < 4.5, which seems to be a similarly sized group.

Most of the code we get is from R, so I'm not sure how many PyStan users there are on any platform. But it may just mean that R is harder to code in for the people who use R and/or that it's harder to install.

  • Bob

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49933702.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49935615.

— Reply to this email directly or view it on GitHub.

bgoodri commented 10 years ago

If it is just those three, then VS 2010 might work.

On Wed, Jul 23, 2014 at 5:31 PM, Michael Betancourt < notifications@github.com> wrote:

Of the top of my head, the expanded math libraries, the type trait libraries, auto.

On Jul 23, 2014, at 10:09 PM, bgoodri notifications@github.com wrote:

Good, but what features of C++11 would be utilized when compiling it?

On Wed, Jul 23, 2014 at 5:06 PM, Michael Betancourt < notifications@github.com> wrote:

Nomad is header only — no shared library.

On Jul 23, 2014, at 10:02 PM, bgoodri notifications@github.com wrote:

If the most awesome autodiff library would be held back due to lack of C++11 support, then I think we should move to C++11 for Stan 3.0. But it might be the case that libnomad.so (or whatever it ends up being called) can be compiled with --std=c++11 and the user's model can be compiled with -Lnomad but without --std=c++11.

But, which aspect(s) of the C++11 standard is/are being used by nomad? Because VS 2010 has pretty incomplete support for it, VS 2012 is decent, and VS 2013 is pretty good but still not complete.

On Wed, Jul 23, 2014 at 4:53 PM, Bob Carpenter < notifications@github.com>

wrote:

On Jul 23, 2014, at 4:04 PM, bgoodri notifications@github.com wrote:

Are we envisioning releasing the autodiff thing standalone

Yes. Both the existing one and the new one. I think it's a good idea because a lot of people want to use autodiff and our existing one is awesome for gradients and the new one's awesome at higher order (and even more awesome than our existing one for some gradients, while slower for others).

with the shared library compiled under the C++11 standard?

I'm not sure I understand what a shared library is.

When the new library is integrated into Stan, Stan will get a C++11 dependency, so we'll only do it when that is feasible.

And things that link to it can be compiled without a standard?

I'm not sure what you mean by without a standard.

I feel like we either have very few PyStan Windows users or they never encounter problems because they never post on stan-users. So, if there is technically some documentable way to do PyStan on Windows with C++11 (cygwin, the p-and-q Python binary, compiling Python yourself, etc.), then maybe we should go ahead. We've pretty much abandoned RHEL servers with g++ < 4.5, which seems to be a similarly sized group.

Most of the code we get is from R, so I'm not sure how many PyStan users there are on any platform. But it may just mean that R is harder to code in for the people who use R and/or that it's harder to install.

  • Bob

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49933702.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49935615.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-49939062.

bob-carpenter commented 10 years ago

I'm going to dive into code review tonight. I'll try to get through all the unreviewed pull requests. It's taken me forever to catch up to my e-mail after being out for a couple days.

ariddell commented 9 years ago

It looks like Python 3.5 on Windows will use Visual Studio 14. This would mean every C++11 feature would be supported, I think.

bgoodri commented 8 years ago

@ariddell Where do we stand on C++11 with Python / Windows? RTools is going to support g++-4.9 on Windows in about a month. See https://github.com/rwinlib/r-base#readme

ariddell commented 8 years ago

C++11 is go in Python.

On 03/04, bgoodri wrote:

@ariddell Where do we stand on C++11 with Python / Windows? RTools is going to support g++-4.9 on Windows in about a month. See https://github.com/rwinlib/r-base#readme

Reply to this email directly or view it on GitHub: https://github.com/stan-dev/stan/issues/714#issuecomment-192523711

sakrejda commented 8 years ago

This is magical.

On Sat, Mar 5, 2016 at 3:40 PM, Allen Riddell notifications@github.com wrote:

C++11 is go in Python.

On 03/04, bgoodri wrote:

@ariddell Where do we stand on C++11 with Python / Windows? RTools is going to support g++-4.9 on Windows in about a month. See https://github.com/rwinlib/r-base#readme

Reply to this email directly or view it on GitHub: https://github.com/stan-dev/stan/issues/714#issuecomment-192523711

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-192730776.

bgoodri commented 8 years ago

With MSVC only on Windows? If so, we should try to unit-test with MSVC also.

On Sat, Mar 5, 2016 at 3:40 PM, Allen Riddell notifications@github.com wrote:

C++11 is go in Python.

On 03/04, bgoodri wrote:

@ariddell Where do we stand on C++11 with Python / Windows? RTools is going to support g++-4.9 on Windows in about a month. See https://github.com/rwinlib/r-base#readme

Reply to this email directly or view it on GitHub: https://github.com/stan-dev/stan/issues/714#issuecomment-192523711

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-192730776.

ariddell commented 8 years ago

For PyStan on Windows it's MSVC 14.0.

syclik commented 8 years ago

We have a wiki page for this. We can open this again when we are ready.

bgoodri commented 8 years ago

We have been ready for a couple of months.

On Thu, Jul 21, 2016 at 11:36 AM, Daniel Lee notifications@github.com wrote:

We have a wiki page for this. We can open this again when we are ready.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/714#issuecomment-234292429, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrquDmEydYA3wbu2qTRId8GlwV0UeNks5qX5IFgaJpZM4CICYn .