Switch to C++11

[bgoodri]

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:

• llvm-g++-4.2 would not work on OS X prior to Mavericks
• g++-4.5 and lower would not work on RHEL
• VS 2008 and lower would not work on Windows

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

[aadler]

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]

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
#714 (comment).

[ariddell]

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]

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

[bgoodri]

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

[aadler]

@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]

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
#714 (comment).

[bgoodri]

@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]

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]

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
#714 (comment).

[ariddell]

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]

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
#714 (comment).

[ariddell]

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
#714 (comment).

---

Reply to this email directly or view it on GitHub:
#714 (comment)

[ariddell]

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
#714 (comment).

---

Reply to this email directly or view it on GitHub:
#714 (comment)

[bgoodri]

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
#714 (comment).

---

Reply to this email directly or view it on GitHub:
#714 (comment)

—
Reply to this email directly or view it on GitHub
#714 (comment).

[ariddell]

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]

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.

[bgoodri]

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
#714 (comment).

[bob-carpenter]

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?

• Bob

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
3.

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

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

[ariddell]

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]

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
#714 (comment).

[ariddell]

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]

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
#714 (comment).

[bob-carpenter]

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
#714 (comment).

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

[betanalpha]

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
#714 (comment).

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

[bob-carpenter]

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
#714 (comment).

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

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

[bgoodri]

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
#714 (comment).

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

[bob-carpenter]

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

[bgoodri]

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
#714 (comment).

[betanalpha]

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
#714 (comment).

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

[bgoodri]

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
#714 (comment).

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

[betanalpha]

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
#714 (comment).

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

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

[bgoodri]

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
#714 (comment).

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

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

—
Reply to this email directly or view it on GitHub
#714 (comment).

[bob-carpenter]

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.

• Bob

[ariddell]

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]

@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]

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:
#714 (comment)

[sakrejda]

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:
#714 (comment)

—
Reply to this email directly or view it on GitHub
#714 (comment).

[bgoodri]

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:
#714 (comment)

—
Reply to this email directly or view it on GitHub
#714 (comment).

[ariddell]

For PyStan on Windows it's MSVC 14.0.

[syclik]

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

[bgoodri]

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
#714 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADOrquDmEydYA3wbu2qTRId8GlwV0UeNks5qX5IFgaJpZM4CICYn
.