I’m having trouble with even responding to this. It’s cause the fundamental tenants are just baked in at this point. #1 and #2 are true for everything (just remove “auto-diff” from #1).
The only reason Stan hasn’t collapsed under its own weight is because we’ve made it maintainable. If you want to see a project die, just don’t care about maintainability and it’ll die. There have been times in the past where we’ve introduced things that nearly killed the project. Maybe how I’m describing it is a little bit of a hyperbole, but maybe not. There were times when things were introduced where I was close to just calling it and starting over.
Just look at this “refactor.” It’s been on the table for years. The reason is that the less well behaved versions of ourselves allowed for something unmaintainable to get into Stan a long time ago. It’s blocked A LOT of progress.
I’ll second Krzysztof’s comment: here or the Stan users list. The Stan users list requires signup (and one of us approving the user – the reason is it’s kept out spam). But otherwise, it’s open posting.
Like Bob said, we really don’t want a stream of synchronous communication. Forums and emails are better cause they can be treated as on-demand, asynchronous communication by the receiver.
Regarding it being on a long lived forum: if you’re contributing to Stan, please get used to it. Or find a pseudoname. We are committed to being open. And trust me, I’ve said / done enough dumb things in public. There’s almost no chance you’ll put up something that’s more ridiculous than what I’ve already put up on our lists. And even if you did, someone would have to care enough to dig it up.
Absolutely. Tests pass. If it’s ever not in that state, we’ll get it back to that state ASAP. But I can’t remember the last time we couldn’t trust the state of develop.
That’s for CmdStan, Stan, and Math. RStan (+ the whole suite) and PyStan are on a different process.
I put together a draft of a very basic landing page for new developers that answers some of the questions I had (which I think are a bit more basic than Lu’s). It’s here: https://github.com/stan-dev/stan/wiki/New-Dev-Resources
I really just wanted to get something in place with some basics that we can add to over time. Hopefully nothing on it is wrong yet! But please fix or let me know if it is. Thanks!
syclik Developer
December 16
sakrejda:
I don’t really have one… every once in a while Daniel tells me I need to remove whitespace at the end of lines of C++ and I have to break out sed but … I think you just need to wait for one of people who’s more into IDE’s to answer.
By the way, it’s not me complaining. We adopted a standard and now we’re adhering to it.
What’s cooler is that it gets run as part of
continuous integration. It’d be great to have
that stan-lint program that’d do the same thing
for Stan programs. Too many projects! Back to
trying to make the parser and code generator more
maintainable :-)
And in case people come here looking for emacs settings, this works well to add the necessary includes for the math library to emacs’s autocomplete (company mode) and syntax checking (flycheck). This belongs in a file called .dir-locals.el somewhere in your project or just above it.
You beat me to it – although some technical issues that deleted an intermediate draft on my end didn’t help. Anyways, I put together as similar intro landing page at https://github.com/stan-dev/stan/wiki/Introduction-to-Stan-for-New-Developers, which is a bit more thorough and conversational. As always, feel free to comment or edit directly.
Just to clarify. The initial purpose of writing this is for sharing my experience in learning Stan, and trying to give some questions for the screening test for the interview. I think I’ve already known the answers to all the listed questions except the “VectorViewMvt” and “VectorView” one.
I think consolidate into Michael’s. Michael, do you mind if I add a few sections to yours? Mostly want a section on project layout and to collect the resources in a list at the end for easy reference.
Sorry for the naive questions. I just want to compile and make some incremental updates to some of the files. I’m using $ g++ file.hpp other_file.hpp, and I’m getting errors even when I include the files in the #include statements. What’s the quickest way to compile locally, preferably just what I need?
What are you trying to do? There wasn’t enough info in your post to help. It could be the math library, Stan itself, any of the interfaces, or perhaps some custom code. It’s straightforward to build locally, just need to know what you’re actually trying to build.
I would like add to this discussion from my own experience. Information on Stan is too scattered, often not clear, and sometimes even conflicting. In the post Multivariate Function with Known Gradients - RStan I was asking for help to implement the a simple function that is callable from a Stan program and uses pre-calculated gradients. I have tried to follow the approach in https://github.com/stan-dev/math/wiki/Adding-a-new-function-with-known-gradients to add my function, but without success. Additionally, I have tried to write my function in the same way as the log_determinant in the Stan Math Library Reference:
namespace stan {
namespace math {
inline var vecToDoubleTwo(const Eigen::Matrix<var, Eigen::Dynamic, 1>& m) {
using Eigen::Matrix;
Matrix<double, Eigen::Dynamic, 1> m_d(m.rows());
for (int i = 0; i < m.size(); ++i)
m_d(i) = m(i).val();
double val = 0;
for (int i=0; i<m.size(); ++i) val += m_d(i) * m_d(i);
vari** varis
= ChainableStack::memalloc_.alloc_array<vari*>(m.size());
for (int i = 0; i < m.size(); ++i)
varis[i] = m(i).vi_;
double* gradients
= ChainableStack::memalloc_.alloc_array<double>(m.size());
for (int i = 0; i < m.size(); ++i)
gradients[i] = 2 * m_d(i);
return var(new precomputed_gradients_vari(val, m.size(),
varis, gradients));
}
}
}
This was also without success.
In both occasions I could use the function from a C++ program with the intended interface of the Stan Math Library. However, as soon as the function should be called from a Stan program, there are issues with variable types. The function works and Stan can find it. There is no problem to print output with it, e.g.
print(vecToDoubleTwo(x));
but
target += vecToDoubleTwo(x);
results in an error message saying that a var can’t be assign to a double (according to the Stan Math Library Reference, a var should never be assigned to double). It works nevertheless for the log_determinant and I can’t find the correct information to fill in the missing links on how to implement the function correctly.
I haven’t taken the time to go thoroughly through it, but you need to always define double and var versions of a given function. This is due to the fact that Stan first calls the log_prob function using double only in order to calculate the log_prob value itself. Since you haven’t defined that function, it will not work but just crash (I would guess at the compilation phase).
In short: write the same function, but with a double input and double output value.
In the other attempt, that I refer to in my post, I actually defined both functions for var and double, but it didn’t work in that case. I will see if I can find out why.