var.grad() method? include redundant includes?

[Bob Carpenter]

[off issue and new subject]

Thanks for catching this. I could've swore that I
both ran that example and that there was such a method.

I think #1 makes most sense for a fix --- add a method
grad() to the class math::var.

I also want to hold up releasing the autodiff paper
until there's a tagged release version of Stan C++
in which all the code will run.

And now that I look at it, we want stan::math::pi(),
not the Boost version (our function calls boost's but
is fixed at double). Then, get rid of the Boost include.

Should we get rid of the <cmath> include? It's brought in
by stan/math.hpp. What I tend to do is include libs I
use directly --- this code has std::pow from <cmath>.

- Bob


> On May 14, 2015, at 1:25 PM, Daniel Lee <notifi...@github.com> wrote:
>
> Bob, I'm trying to go through your examples in the paper and the first one fails to compile:
>
> #include <cmath>
> #include <boost/math/constants/constants.hpp>
> #include <stan/math.hpp>
>
> int main() {
> using std::pow;
> double y = 1.3;
> stan::math::var mu = 0.5, sigma = 1.2;
>
> stan::math::var lp = 0;
> lp -= pow(2 * boost::math::constants::pi<double>(), -0.5);
> lp -= log(sigma);
> lp -= 0.5 * pow((y - mu) / sigma, 2);
> std::cout << "f(mu,sigma)= " << lp.val() << std::endl;
>
> lp.grad();
> std::cout << " d.f / d.mu = " << mu.adj()
> << " d.f / d.sigma = " << sigma.adj() << std::endl;
> }
>
> The stan::math::var class does not have a .grad() with no arguments, so it can't compile this part: lp.grad(). Options:
>
> • we create the grad() function that has the right behavior.
> • we replace lp.grad() with stan::math::grad(lp.vi_). I think this is the weakest option
> • we create a new stan::math::grad(var&) function, then replace lp.grad() with stan::math::grad(lp)
> Thoughts?
>
> —
> Reply to this email directly or view it on GitHub.
>

[Daniel Lee]

On Thu, May 14, 2015 at 2:06 PM, Bob Carpenter <ca...@alias-i.com> wrote:

[off issue and new subject]

Thanks.

 

Thanks for catching this.  I could've swore that I
both ran that example and that there was such a method.

Ha. I'm sure you didn't run it -- there's an extra ')' in there that makes the syntax invalid.

I think #1 makes most sense for a fix --- add a method
grad() to the class math::var.

Will do.

 

I also want to hold up releasing the autodiff paper
until there's a tagged release version of Stan C++
in which all the code will run.

Yes. I'll use this pull request to do both the uber-include header, remove other non-essential folder-level includes, and making sure the examples in the paper work (that last bit will be on the papers repo). Once it's in, at the point we tag it, the autodiff paper will match the Stan C++.

 

And now that I look at it, we want stan::math::pi(),
not the Boost version (our function calls boost's but
is fixed at double).  Then, get rid of the Boost include.

Will do.

Should we get rid of the <cmath> include?  It's brought in
by stan/math.hpp.  What I tend to do is include libs I
use directly --- this code has std::pow from <cmath>.

I think we should include it since we use it directly.

 

- Bob


> On May 14, 2015, at 1:25 PM, Daniel Lee <notifi...@github.com> wrote:
>
> Bob, I'm trying to go through your examples in the paper and the first one fails to compile:
>
> #include <cmath>
> #include <boost/math/constants/constants.hpp>
> #include <stan/math.hpp>
>
> int main() {
>   using std::pow;
>   double y = 1.3;
>   stan::math::var mu = 0.5, sigma = 1.2;
>
>   stan::math::var lp = 0;
>   lp -= pow(2 * boost::math::constants::pi<double>(), -0.5);
>   lp -= log(sigma);
>   lp -= 0.5 * pow((y - mu) / sigma, 2);
>   std::cout << "f(mu,sigma)= " << lp.val() << std::endl;
>
>   lp.grad();
>   std::cout << " d.f / d.mu = " << mu.adj()
>             << " d.f / d.sigma = " << sigma.adj() << std::endl;
> }
>
> The stan::math::var class does not have a .grad() with no arguments, so it can't compile this part: lp.grad(). Options:
>
>       • we create the grad() function that has the right behavior.
>       • we replace lp.grad() with stan::math::grad(lp.vi_). I think this is the weakest option
>       • we create a new stan::math::grad(var&) function, then replace lp.grad() with stan::math::grad(lp)
> Thoughts?
>
> —
> Reply to this email directly or view it on GitHub.
>

--
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/d/optout.