It seems as if Allen has confirmed that stanc can now be built with optimization, which reduces the size on disk considerably.
There is some question as to whether Python can specify -std=c++0x when using g+±4.6 and -std=c++11 when using g+±4.9. This can be done with R via an environmental variable since users of R 3.2.x are still on g+±4.6 while users of R 3.3.x are on g+±4.9. So, it seems as if we were to require C++11 for Stan, we would be limited to the C++11 features that were incompletely supported by g+±4.6 until April at least when R 3.4.x will be released, R 3.3.x will be considered stable, and R 3.2.x will be considered old stable. So, there is the question of whether there is enough in g+±4.6 to make it worthwhile
If we were to require C++11, it would cutoff anyone using g+±4.5 or lower, which is only prevalent on older Linux servers. Of course, at the moment g+±4.4 does not work even without C++11 due to things not being defined in the std library
./stan/math/rev/mat/functor/cvodes_utils.hpp:26: error: ‘runtime_error’ is not a member of ‘std’
./stan/math/prim/mat/fun/round.hpp:19: error: ‘std::round’ has not been declared
Not yet, but I think we’re getting close. Yet another
reason to not do an in-memory integration with the interfaces,
as those are what’s holding us back.
The interfaces aren’t holding us back. The rstanarm binaries are compiled with C++11 on Windows to get around a Boost warning about long long or something. Allan keeps saying that it is fine on Python.
Nothing has changed since the last time we talked about it at a Stan meeting. There are a lot of people who still use R 3.2.x on Windows, in which case the least common denominator is the parts of the (future) C++11 standard that g+±4.6.3 implemented with -std=c++0x, which is most everything
except alignas, delegating constructors, extended friend declarations, inheriting constructors, user-defined literals, template aliases, override / final, attributes, ref-qualifiers, non-static data member initializers. Also, I don’t think the random or the regex C++11 libraries were implemented by g++ then. Finally, decltype and thread-local storage were incompletely implemented as of g+±4.6.3.
The people who would be hurt most are those on old Linux servers whose support contract limits them to g+±4.5 or lower.
Is it ok to use C++11 for testing? I think it’d help us out a lot.
Regarding g+±4.6.3, I don’t believe for a second what any website says. We’ve been burned by compiler bugs in the past – I’m not so sure I’m ready to hunt down bugs in a g+±4.6.3 pre release version that’s been fixed. I’d rather spend the time trying to get a more up-to-date version of g++ installed on Windows XP, 7, 10 instead.
Yes, that’s a statement and I know that’s true. It doesn’t answer the
questions I’ve asked. Want to clarify? Here are more questions I have (just
cause I think I understand what you mean by that statement, but it’ll
illuminate what I’m worried about):
do the compilers act differently when compiling C++11 vs C++03 enough
where we might miss a something by testing with C++11?
do we need to reinstall g+±4.6.3-prerelease in order to catch compiler
incompatibilities with C++11?
what percentage of Windows RStan users do you think is on g+±4.6.3?
what number of Windows RStan users do you think is on g+±4.6.3?
do you think it’s possible that we can get most of the g+±4.6.3 users on
g+±4.9?
what do we need to do to educate RStan Windows users for that to happen?
Have them read the wiki. It is not as if people have had more difficulty with R 3.3.x and RTools33, but some people don’t upgrade and some people aren’t allowed to.
=). I don’t think I ever understood your responses to mean exactly that.
And since you’re agreeing to my last set of questions, mind writing out what you actually mean so I don’t accidentally misinterpret what you’re saying?
And here’s the important part: if we’re able to go to part of the C++11 spec:
what do we need to do build?
how to we ensure these things are still compilable under our limitations?
If we call g+±4.6 the least common denominator for C++11, then we would be abandoning Stan on some Linux servers that only have older g++. We would have to test Math and Stan with the least common denominator compiler on the Windows machine in my office, in addition to whatever compilers Travis is using that day. And we would need to test Math and Stan with g+±4.9 on Windows.
The interfaces would need to be tested with various compilers, but probably just before a release rather than every PR. It is very unlikely that anyone using Julia/Matlab/Mathematica/Stata/CmdStan would have the least common denominator compiler. PyStan (I believe) needs the same compiler that was used to build Python, which in the case of C++11 and Windows would by Visual Studio Something that Allen knows. RStan is the same way in that it needs the same compiler that was used to build that version of R, which is different for 3.2.x and 3.3.x.
As far as PyStan is concerned, we can move to C++11. There are some
platforms that use g++ 4.6 but they will very soon not have a supported
version of Python, so not supporting them going forward seems fine.
Windows is only supported in cases where C++11 is supported, so there
are no worries there either.
@bgoodri: I didn’t take this chunk of text to mean “we can move to C+±11 that g+±4.6.3 supports.” If that’s what you meant, sorry – it took another 15 posts for me to understand that’s what you meant. It would help me (and I suspect some of the others) if you were able to summarize what you meant.
In your last post, you said this:
What’s your suggestion? Do you want to abandon users with the older g++? What you wrote was a statement and I don’t know what decision you want or are suggesting based on your statement.
We (Ben, Aki, Rob, Daniel, Mike, Jonah) discussed this at the meeting today.
We concluded that starting in April 2017, we could require a C++ compiler that supports C++14. In particular, the minimum g++ version we could require is 4.9. XCode’s default clang++ version supports more of the C++14 standard than g++ 4.9, so we’re ok with Mac.
The reasoning is:
R will release 3.4 in April. Starting with version 3.3, RTools has been using g++ 4.9. In April, R will no longer support 3.2, the last version that used 4.6.3.
C++11 vs C++14: there is no compiler that defaults to C++11, but g++ 5 and higher defaults to C++14. g++ 4.9 supports most of C++14.
The limiting factor will be PyStan. We may be limited to what portions of the standard MSVC supports.