hessian & 2.6.2

[Joshua N Pritikin]

I spent some time porting multi_normal_sufficient to 2.6.2. Is it
necessary to include stan headers in a particular order? Even though I
include,

#include <stan/math/rev/scal/fun/value_of.hpp>
#include <stan/math/fwd/scal/fun/value_of.hpp>

I still get this error,

/home/joshua/R/x86_64-pc-linux-gnu-library/3.1/StanHeaders/include/stan/math/prim/mat/err/check_symmetric.hpp:54:59: error: no matching function for call to ‘fabs(stan::agrad::var)’
if (!(fabs(value_of(y(m, n)) - value_of(y(n, m)))

Why doesn't the compiler pick the right version of value_of?

Thanks.

--
Joshua N. Pritikin
Department of Psychology
University of Virginia
485 McCormick Rd, Gilmer Hall Room 102
Charlottesville, VA 22904
http://people.virginia.edu/~jnp3bc

[Ben Goodrich]

Not sure, but I have a StanHeaders 2.6.2 ready to upload to CRAN, so let me know if it needs to patch anything to get this to work.

Ben

[Daniel Lee]

This looks like it's missing fabs, not value_of?

--
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.

[Joshua N Pritikin]

On Sat, Mar 14, 2015 at 10:42:35PM -0400, Daniel Lee wrote:
> This looks like it's missing fabs, not value_of?

Yeah, that was it. Thanks.

[Joshua N Pritikin]

I see that stan/version.hpp uses `const std::string` instead of
#defines.

How do I write #if macros that depend on the Stan version so my code
works for both 2.6.0 and 2.6.2?

[Bob Carpenter]

That's a good point.

Is there any reason not make these #define-ed properties?

We tried to stay away from macros/properties, but I see
where it'd make sense in this context.

Out of curiosty, what do you need that depends on the version?

- Bob

[Joshua N Pritikin]

On Sun, Mar 15, 2015 at 10:18:37PM +1100, Bob Carpenter wrote:
> That's a good point.
>
> Is there any reason not make these #define-ed properties?
>
> We tried to stay away from macros/properties, but I see
> where it'd make sense in this context.

Conditional defines would allow people to upgrade OpenMx without
upgrading StanHeaders and vice versa. It's not a big deal. It just makes
things a little bit easier for people who don't eagerly track new
releases.

> Out of curiosty, what do you need that depends on the version?

The code works in either version but the required #includes are
different because of the reoganization.

[Daniel Lee]

On Mar 15, 2015 8:06 AM, "Joshua N Pritikin"SittinG <jpri...@pobox.com> wrote:
>
> On Sun, Mar 15, 2015 at 10:18:37PM +1100, Bob Carpenter wrote:
> > That's a good point.
> >
> > Is there any reason not make these #define-ed properties?
> >
> > We tried to stay away from macros/properties, but I see
> > where it'd make sense in this context.

Same. I don't see a problem in introducing a version number macro for the next release.

> > Out of curiosty, what do you need that depends on the version?
>
> The code works in either version but the required #includes are
> different because of the reoganization.
>
> > > On Mar 15, 2015, at 9:47 PM, Joshua N Pritikin <jpri...@pobox.com> wrote:
> > > I see that stan/version.hpp uses `const std::string` instead of
> > > #defines.
> > >
> > > How do I write #if macros that depend on the Stan version so my code
> > > works for both 2.6.0 and 2.6.2?

Unfortunately, there won't be a way to do this with macros because they never existed in the tagged versions of Stan 2.6.0 and 2.6.2.

> Conditional defines would allow people to upgrade OpenMx without
> upgrading StanHeaders and vice versa. It's not a big deal. It just makes
> things a little bit easier for people who don't eagerly track new
> releases.

Do you have a sense of the size of the user base that wouldn't be up for tracking new releases? This would have to be an intersection of Stan and OpenMX users. Although in principle this sounds ok, it may be over engineering the solution. That said, I'm ok with adding a version number macro.

Joshua, mind opening up an issue with a proposed macro or macros? We can have a focused discussion on the implementation on the issue thread.

[Joshua N Pritikin]

On Sun, Mar 15, 2015 at 10:01:36AM -0400, Daniel Lee wrote:
> On Mar 15, 2015 8:06 AM, "Joshua N Pritikin"SittinG

> > > > How do I write #if macros that depend on the Stan version so my
> code
> > > > works for both 2.6.0 and 2.6.2?
>
> Unfortunately, there won't be a way to do this with macros because they
> never existed in the tagged versions of Stan 2.6.0 and 2.6.2.

Sure, no problem.

> > Conditional defines would allow people to upgrade OpenMx without
> > upgrading StanHeaders and vice versa. It's not a big deal. It just
> makes
> > things a little bit easier for people who don't eagerly track new
> > releases.
>
> Do you have a sense of the size of the user base that wouldn't be up
> for tracking new releases? This would have to be an intersection of
> Stan and OpenMX users. Although in principle this sounds ok, it may be
> over engineering the solution.

Well, maybe the bigger problem is that there is a potential CRAN race
condition. Suppose StanHeaders is upgraded first. Then OpenMx will fail
to install until it is updated. Same problem is OpenMx is upgraded
first. So both packages would need simultaneous upgrades on CRAN to
avoid the situation where OpenMx was uninstallable for a short time.

> That said, I'm ok with adding a version number macro.
>
> Joshua, mind opening up an issue with a proposed macro or macros? We
> can have a focused discussion on the implementation on the issue
> thread.

https://github.com/stan-dev/stan/issues/1383

[Daniel Lee]

On Sun, Mar 15, 2015 at 10:24 AM, Joshua N Pritikin <jpri...@pobox.com> wrote:
> On Sun, Mar 15, 2015 at 10:01:36AM -0400, Daniel Lee wrote:
>> On Mar 15, 2015 8:06 AM, "Joshua N Pritikin"SittinG

>> > Conditional defines would allow people to upgrade OpenMx without
>> > upgrading StanHeaders and vice versa. It's not a big deal. It just
>> makes
>> > things a little bit easier for people who don't eagerly track new
>> > releases.
>>
>> Do you have a sense of the size of the user base that wouldn't be up
>> for tracking new releases? This would have to be an intersection of
>> Stan and OpenMX users. Although in principle this sounds ok, it may be
>> over engineering the solution.
>
> Well, maybe the bigger problem is that there is a potential CRAN race
> condition. Suppose StanHeaders is upgraded first. Then OpenMx will fail
> to install until it is updated. Same problem is OpenMx is upgraded
> first. So both packages would need simultaneous upgrades on CRAN to
> avoid the situation where OpenMx was uninstallable for a short time.

Understood. Thanks.

[Ben Goodrich]

On Sunday, March 15, 2015 at 10:24:16 AM UTC-4, Joshua Pritikin wrote:

Well, maybe the bigger problem is that there is a potential CRAN race
condition. Suppose StanHeaders is upgraded first. Then OpenMx will fail
to install until it is updated. Same problem is OpenMx is upgraded
first. So both packages would need simultaneous upgrades on CRAN to
avoid the situation where OpenMx was uninstallable for a short time.

I could put the macro into StanHeaders before I upload it. There were already a couple of other tiny bugs with 2.6.2 that I'm going to have to patch around. I guess OpenMx could detect the absense of a macro to imply 2.6.0? The rstan package has a stan_version function that you could grab.

Ben

[Joshua N Pritikin]

On Sun, Mar 15, 2015 at 07:39:54AM -0700, Ben Goodrich wrote:
> I could put the macro into StanHeaders before I upload it. There were
> already a couple of other tiny bugs with 2.6.2 that I'm going to have
> to patch around. I guess OpenMx could detect the absense of a macro to
> imply 2.6.0? The rstan package has a stan_version function that you
> could grab.

Given that no released version of OpenMx depends on StanHeaders and
OpenMx is also not at CRAN yet, I think it is not worth the effort this
time.

Thanks.