version 1.0 release?

[Bob Carpenter]

I've been itching to release an official 1.0 version of Stan.

I fear we're on a treadmill of continually making Stan more
expressive and faster, but never converging on a release date.

Now that Jiqiang's made so much progress on the R interface,
it also brings up the issue of whether to wait for that.

Now that Matt added a slick vectorization pattern for normal,
should we add the other distributions? (This'd take me around
a week or so, though Daniel and I could split the work and do
it faster.)

With vectorized models we can write an ordinary linear
regression model with improper priors as:

data {
matrix(N,K) x;
vector(N) y;
}
parameters {
vector(K) beta;
real(0,) sigma;
}
model {
y ~ normal(x*beta,sigma);
}

We can independent priors for each coefficient by adding
the following to the model:

beta ~ cauchy(0,2.5);

This does bring up the issue of writing a faster matrix-vector
multiplication implementation for (x * beta) along the lines
of what Marcus did for dot products (it'd basically use
the dot products in the output cells).

- Bob

[Marcus Brubaker]

Actually I believe I already did that a while back.  See src/stan/agrad/matrix.hpp line ~1500.  Or am I missing something?  It could most likely be made even faster and more memory efficient (by reusing some of the buffers in the dot_product vari implementation) but the straightforward implementation in terms of the dot_product is already in place.  As I recall it made a pretty big difference in speed.

Cheers,
Marcus

[Ben Goodrich]

On Tuesday, June 26, 2012 7:43:42 PM UTC-4, Bob Carpenter wrote:

I've been itching to release an official 1.0 version of Stan.

I fear we're on a treadmill of continually making Stan more
expressive and faster, but never converging on a release date.

Although I agree with the philosophy of "release early, release often (and listen to your customers)", I think it is less essential for a header-only project with a public git repository. Anyone who knows about and wants to use Stan has been able to do so for a while, so I doubt there are that many people who are waiting for the code to be blessed with a 1.0 before they go ahead with their project.

Now that Jiqiang's made so much progress on the R interface,
it also brings up the issue of whether to wait for that.

If there are a substantial number of people that want to use Stan but aren't currently, they are probably people that feel they need an interface to facilitate things. So, I think rstan is worth waiting for.

Now that Matt added a slick vectorization pattern for normal,
should we add the other distributions?  (This'd take me around
a week or so, though Daniel and I could split the work and do
it faster.)

If we are going to wait for rstan (or for any other reason), then I think harmonizing the pattern for the distributions would be good. Another thing is the question of whether to upgrade / test Eigen 3.1 now that it is released.
 

With vectorized models we can write an ordinary linear
regression model with improper priors as:

...

This does bring up the issue of writing a faster matrix-vector
multiplication implementation for (x * beta) along the lines
of what Marcus did for dot products (it'd basically use
the dot products in the output cells).

Anything that can simplify the syntax of the .stan files is great. The idea that a user has to write the model as a text file is probably the biggest hurdle to overcome for people who don't write a lot of code. I think the stan syntax is already simpler than WinBUGS while simultaneously offering more features, but incorporating the vectorization would constitute even more progress on both fronts.

Ben

[Bob Carpenter]

On 6/26/12 8:32 PM, Ben Goodrich wrote:
> On Tuesday, June 26, 2012 7:43:42 PM UTC-4, Bob Carpenter wrote:

> Although I agree with the philosophy of "release early, release often (and listen to your customers)", I think it is
> less essential for a header-only project with a public git repository. Anyone who knows about and wants to use Stan has
> been able to do so for a while, so I doubt there are that many people who are waiting for the code to be blessed with a
> 1.0 before they go ahead with their project.

I'm afraid we're no longer header only. Compile
times were too slow.

Personally, I tend not to even look at things until
they've had an officially blessed release. Google's
introduction of the perpetual beta has confused matters
in my and other people's minds.

The biggest deal in my mind is advertisement. We haven't
really advertised it as being ready for use anywhere.
Until a week ago, there were giant "unstable" warnings on it.

> If we are going to wait for rstan (or for any other reason), then I think harmonizing the pattern for the distributions
> would be good. Another thing is the question of whether to upgrade / test Eigen 3.1 now that it is released.

Definitely. I'll update to 3.1. I've been noticing
the release candidates go by, but 3.1 was just released
today.

> This does bring up the issue of writing a faster matrix-vector
> multiplication implementation for (x * beta) along the lines
> of what Marcus did for dot products (it'd basically use
> the dot products in the output cells).
>
> Anything that can simplify the syntax of the .stan files is great. The idea that a user has to write the model as a text
> file is probably the biggest hurdle to overcome for people who don't write a lot of code. I think the stan syntax is
> already simpler than WinBUGS while simultaneously offering more features, but incorporating the vectorization would
> constitute even more progress on both fronts.

I'd have thought most people would find BUGS syntax
simpler overall -- our matrix stuff's cleaner, but people
are going to balk at all the variable declarations. Not
to mention the semicolons.

- Bob

[Bob Carpenter]

On 6/26/12 7:58 PM, Marcus Brubaker wrote:

> On Tue, Jun 26, 2012 at 7:43 PM, Bob Carpenter <ca...@alias-i.com <mailto:ca...@alias-i.com>> wrote:
> This does bring up the issue of writing a faster matrix-vector

> multiplication implementation ...

>
> Actually I believe I already did that a while back. See src/stan/agrad/matrix.hpp line ~1500. Or am I missing
> something? It could most likely be made even faster and more memory efficient (by reusing some of the buffers in the
> dot_product vari implementation) but the straightforward implementation in terms of the dot_product is already in
> place. As I recall it made a pretty big difference in speed.

Fantastic. I thought you'd only done the basic
dot products. I'll scratch this off my to-do list
for the short term.

Longer term, you're right -- we can share the allocated
vari** across the dot products. I'll put that on
the to-do list :-)

- Bob

[Ben Goodrich]

On Tuesday, June 26, 2012 8:45:06 PM UTC-4, Bob Carpenter wrote:

On 6/26/12 8:32 PM, Ben Goodrich wrote:
> On Tuesday, June 26, 2012 7:43:42 PM UTC-4, Bob Carpenter wrote:

> Although I agree with the philosophy of "release early, release often (and listen to your customers)", I think it is
> less essential for a header-only project with a public git repository. Anyone who knows about and wants to use Stan has
> been able to do so for a while, so I doubt there are that many people who are waiting for the code to be blessed with a
> 1.0 before they go ahead with their project.

I'm afraid we're no longer header only.  Compile
times were too slow.

Personally, I tend not to even look at things until
they've had an officially blessed release.  Google's
introduction of the perpetual beta has confused matters
in my and other people's minds.

The biggest deal in my mind is advertisement.  We haven't
really advertised it as being ready for use anywhere.
Until a week ago, there were giant "unstable" warnings on it.

Maybe that has counteracted Andrew's blog posts that said to use stan before it even existed. I guess the website didn't make it clear that for the last few months stan could reasonably be expected to yield valid inferences for simple to moderately complicated models, even though a lot of plumbing was being overhauled.
 

> If we are going to wait for rstan (or for any other reason), then I think harmonizing the pattern for the distributions
> would be good. Another thing is the question of whether to upgrade / test Eigen 3.1 now that it is released.

Definitely.  I'll update to 3.1.  I've been noticing
the release candidates go by, but 3.1 was just released
today.

If you are going to do that, then I would resuggest organizing it like upstream with eigen/Eigen/* and eigen/unsupported/Eigen/FFT/; see

https://groups.google.com/d/topic/stan-dev/Fi0M3Y6i2_A/discussion

I'd have thought most people would find BUGS syntax
simpler overall -- our matrix stuff's cleaner, but people
are going to balk at all the variable declarations.  Not
to mention the semicolons.

A lot of people are going to find variable declarations and semicolons annoying, but it's an easy thing for them to fix, particularly with good error messages. I think stan will have a lower rate of users getting completely stuck on some syntax thing.

Ben

[Bob Carpenter]

> The biggest deal in my mind is advertisement. We haven't
> really advertised it as being ready for use anywhere.
> Until a week ago, there were giant "unstable" warnings on it.
>
>
> Maybe that has counteracted Andrew's blog posts that said to use stan before it even existed.

:-)

> I guess the website didn't
> make it clear that for the last few months stan could reasonably be expected to yield valid inferences for simple to
> moderately complicated models, even though a lot of plumbing was being overhauled.

No -- I, for one, didn't want to advertise it before
the language used in the model stabilized and we got
it documented and building on all platforms.

Now might be a good time to announce a beta and let
people kick the tires before 1.0.

> > If we are going to wait for rstan (or for any other reason), then I think harmonizing the pattern for the
> distributions
> > would be good.

You mean synchronizing releases of RStan and Stan?

> > Another thing is the question of whether to upgrade / test Eigen 3.1 now that it is released.
>
> Definitely. I'll update to 3.1. I've been noticing
> the release candidates go by, but 3.1 was just released
> today.
>
>
> If you are going to do that, then I would resuggest organizing it like upstream with eigen/Eigen/* and
> eigen/unsupported/Eigen/FFT/; see
>
> https://groups.google.com/d/topic/stan-dev/Fi0M3Y6i2_A/discussion

Thanks for reminding me. It makes sense to follow
their layout now that we have FFT.

Your argument (on the link) to allow different versions of
the libs is also a good motivation.

And speaking of libs, Boost already has a 1.50 beta.

- Bob

[Ben Goodrich]

On Wednesday, June 27, 2012 12:09:22 AM UTC-4, Bob Carpenter wrote:

You mean synchronizing releases of RStan and Stan?

For 1.0, I would think so. After that, I can't see why it is absolutely necessary. But if RStan is going to include all of Stan/src, then I guess a release of Stan would tend to precipitate a new release of RStan (even if the R code didn't change), in which case they might as well get the same version numbers to reduce confusion.

Ben

[Bob Carpenter]

On 6/27/12 1:45 AM, Ben Goodrich wrote:
> ...if RStan is going to include all

> of Stan/src, then I guess a release of Stan would tend to precipitate a new release of RStan (even if the R code didn't
> change), in which case they might as well get the same version numbers to reduce confusion.

I agree that we don't want to be in the situation
where the latest RStan doesn't run with the latest Stan.

I think you're right about version numbering. It'll
make the instructions that much easier.
Installed users may upgrade needlessly, but that shouldn't
be too big a deal compared to getting someone installed
in the first place.

RStan might even want to check the version of Stan to
make sure it's the right version.

- Bob

[Marcus Brubaker]

Actually, don't worry about putting it on the to-do list.  I was inspired today and implemented it.  Just pushed it a few moments ago along with a fix for scalar-matrix addition which somehow broke in the last month or two.  (Something similar probably needs to be done for subtraction, which probably should go on the to-do list.)

Cheers,
Marcus


 

- Bob

[Ben Goodrich]

On Wednesday, June 27, 2012 12:09:22 AM UTC-4, Bob Carpenter wrote:

>     Another thing is the question of whether to upgrade / test Eigen 3.1 now that it is released.
>
>     Definitely. I'll update to 3.1. I've been noticing
>     the release candidates go by, but 3.1 was just released
>     today.
>
>
> If you are going to do that, then I would resuggest organizing it like upstream with eigen/Eigen/* and
> eigen/unsupported/Eigen/FFT/; see
>
> https://groups.google.com/d/topic/stan-dev/Fi0M3Y6i2_A/discussion

Thanks for reminding me.  It makes sense to follow
their layout now that we have FFT.

Your argument (on the link) to allow different versions of
the libs is also a good motivation.

And speaking of libs, Boost already has a 1.50 beta.

What is the status of this?

git show 6e6d658c71737293d812aaa44c61ef8bb0f1c90f

claims to have "updated eigen and boost versions in dependencies and doc"

but it appears as if the Eigen/ and boost/ directories are the same as before.

Ben

[Bob Carpenter]

On 6/28/12 3:02 PM, Ben Goodrich wrote:
> On Wednesday, June 27, 2012 12:09:22 AM UTC-4, Bob Carpenter wrote:
>
> What is the status of this?
>
> git show 6e6d658c71737293d812aaa44c61ef8bb0f1c90f

I'm about to head out for another meeting, so I checked
in the updates to the doc before Daniel checked in
the new code. He's about to update to the new Boost
(1.50 is official now) and the new Eigen (3.1), and move
everything around so it's organized roughly as follows:

$stan/lib/eigen_3.1.0/Eigen/*
/unsupported/Eigen
/boost_1.50.0/boost/*
/googletest_1.6.0/gtest/*

with called out parameters in the make to allow swapping
these libraries.

These don't necessarily mirror the top-level distributions
of these packages, but they'll be setup so you can
just unpack a new version and point to somewhere in it
to run.

Speaking of this org, should "lib/" here be called
"include/" instead?

- Bob

[Jiqiang Guo]

I agree with this.

Jiqiang

[Daniel Lee]

All the libs have been rearranged.

Boost has been upgraded to 1.50.0.
Eigen is still at 3.0. (Can't get the current code to compile using 3.1.0.)
Google Test is at 1.6.0.

To change the include directory of the libraries, set BOOST, EIGEN, or
GTEST on the command line to an alternate path.



Regarding upgrading to Eigen 3.1, we are currently having issues with
the call to cov_matrix_constrain() in stan/prob/transform.hpp. I'll
try to get it fixed, but if someone has an idea on how to fix it, feel
free to tackle it. Run these commands to see the errors:
make runtest/test/prob/transform
make runtest/test/io/writer



Daniel

[Daniel Lee]

I just added the Eigen 3.1.0 libraries to our lib. Eigen 3.0 is still there.

To run the tests that fail:
make runtest/test/prob/transform EIGEN=lib/eigen_3.1.0
make runtest/test/io/writer EIGEN=lib/eigen_3.1.0

[Ben Goodrich]

On Friday, June 29, 2012 12:12:31 AM UTC-4, Daniel Lee wrote:

I just added the Eigen 3.1.0 libraries to our lib. Eigen 3.0 is still there.

To run the tests that fail:
make runtest/test/prob/transform EIGEN=lib/eigen_3.1.0
make runtest/test/io/writer EIGEN=lib/eigen_3.1.0

Somebody commit this change to line 75 of src/stan/prob/transform.hpp for me

diff --git a/src/stan/prob/transform.hpp b/src/stan/prob/transform.hpp
index 11bb784..e9d2f5e 100644
--- a/src/stan/prob/transform.hpp
+++ b/src/stan/prob/transform.hpp
@@ -72,7 +72,7 @@ namespace stan {
       for(size_t i = 1; i < (K - 1); i++) {
         position += pull;
         pull--;
-        temp = U.row(i).tail(pull).array();
+        temp = U.row(i).tail(pull);
         temp /= sqrt(acc.tail(pull) / acc(i));
         CPCs.segment(position, pull) = temp;
         acc.tail(pull) *= 1.0 - temp.square();

It seems to work with both versions of eigen now.

Ben

[Daniel Lee]

Ben, I got the change in. Thanks for the patch!