Merged HMC Refactor

[Michael Betancourt]

I merged the hmc_refactor branch into master -- there weren't any conflicts outside of stan/src/mcmc. Once I have a second (maybe on the plane, if I don't fall asleep?) I'll add the epsilon jitter to both NUTS and static HMC. Until then, please let me know if the merge broke anyone's models! Or if there are any particular performances changes.

Next step -- a unified mcmc_writer class to handle both sample and diagnostic output (Dan, if you have any downtime between that dissonant young-persons music let me know what changes you made in the visual_diagnostic branch to admit unconstrained variable names) and revamped command-line options (I think we agreed upon sub arguments -- is this possible with the current argument parser, or do we need to rewrite that first?).

-Mike

P.S. Peter, you should be able to add all kinds of Metropolis fun in stan/src/mcmc/metro and use the base adaptation classes for adaptive Metropolis algorithms, too. As I noted above, we'll have to revamp the command line arguments anyways, so go ahead and add whatever arguments you'd like to get Metropolis running.

[Ben Goodrich]

I committed a fix that changed the capitalization of the phi.hpp header, but then ran into another test failure

[ RUN      ] AgradFvar.numeric_limits
src/test/agrad/fwd/numeric_limits_test.cpp:135: Failure
Value of: std::numeric_limits<stan::agrad::fvar<int> >::is_modulo
  Actual: 0
Expected: 1
[  FAILED  ] AgradFvar.numeric_limits (0 ms)
[----------] 73 tests from AgradFvar (3 ms total)

This is with Peter's fix in 0b8d5a9afb1fb64dc24c0c79f4d4ae88c04caf16.

Ben

[Peter Li]

I'm not sure why that's failing. The value of std::numeric_limits<stan::grad::fvar<int> >::is_modulo should be 1 (I think?). Regardless, it passes on my machine (and just passed on Jenkins). 

Peter

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ben Goodrich]

On Tuesday, April 16, 2013 10:19:57 PM UTC-4, Peter Li wrote:

I'm not sure why that's failing. The value of std::numeric_limits<stan::grad::fvar<int> >::is_modulo should be 1 (I think?). Regardless, it passes on my machine (and just passed on Jenkins). 

I'm getting it with both clang++ and g++, albeit using the 4.8 libraries in both cases.

Ben

[Bob Carpenter]

Did you run tests of some models in your new
implementation and in the old implementation?

If not, I can do that. Or maybe we could fire
off all of Ben's tests?

- Bob

[Michael Betancourt]

I ran the model tests and the expected number of models converged as well as spot checks on a various models, but nothing systematic on before/after performance.

[Bob Carpenter]

fvar<int> doesn't make sense. The template parameter
T in fvar<T> should filled with a floating-point
value or similar scalar, such as agrad::var.

- Bob

[Ben Goodrich]

On Wednesday, April 17, 2013 12:22:59 AM UTC-4, Bob Carpenter wrote:

Did you run tests of some models in your new
implementation and in the old implementation?

If not, I can do that.  Or maybe we could fire
off all of Ben's tests?

There was only one new issue that I saw, which was just a missing #include that I fixed.

Ben

[Peter Li]

So for numeric_limits, do we only need it for fvar<double>? or are we setting all numeric_limits as being the same as those for double?


Peter

[Bob Carpenter]

You want to do it for all types T,
but you still want to return what
numeric_limits<double> returns.

All the types T you'll implement it for
will have implicit constructors T(double)
that will build the appropriate type out
of doubles.

At the very least, we'll need the following
for RM-HMC in Stan:

fvar<double>
fvar<var>
fvar<fvar<double>>
fvar<fvar<var>>

But they can all be implemented with one template.
And templating will also let client code plug in
float instead of double or some other base scalar
type.

- Bob

[Peter Li]

Ah I see. I'll push the changes once unit tests pass.



Peter

[Bob Carpenter]

Thanks for waiting on the tests!

We really need to work on making them faster.

- Bob