check_not_nan for Eigen matrix/vector types?

[Bob Carpenter]

I can't get check_not_nan to work for Eigen types,
only for scalars and std::vector.

I see that all the examples in stan/math/prim/mat use
check_not_nan on an element-by-element basis. Does that
mean it won't work for Eigen vectors? Or is there just
something I'm not including that I should be including?

I'd think is_vector_like would pick it up.

- Bob

P.S. Here's the error sequence if that helps:

...
In file included from ./stan/math/prim/scal/err/check_not_nan.hpp:8:
./stan/math/prim/scal/fun/value_of_rec.hpp:24:14: error: cannot convert 'const Eigen::Matrix<double, -1, 1, 0, -1, 1>' to
'double' without a conversion operator
return static_cast<double>(x);
^~~~~~~~~~~~~~~~~~~~~~
./stan/math/prim/scal/err/check_not_nan.hpp:33:38: note: in instantiation of function template specialization
'stan::math::value_of_rec<Eigen::Matrix<double, -1, 1, 0, -1, 1> >' requested here
if ((boost::math::isnan)(value_of_rec(stan::get(y, n))))
^
./stan/math/prim/scal/err/check_not_nan.hpp:64:11: note: in instantiation of member function 'stan::math::(anonymous
namespace)::not_nan<Eigen::Matrix<double, -1, 1, 0, -1, 1>, true>::check' requested here
::check(function, name, y);
^
./stan/math/prim/mat/fun/sort_asc.hpp:21:7: note: in instantiation of function template specialization
'stan::math::check_not_nan<Eigen::Matrix<double, -1, 1, 0, -1, 1> >' requested here
check_not_nan("sort_asc", "array", xs);
^
test/unit/math/prim/mat/fun/sort_test.cpp:14:9: note: in instantiation of function template specialization
'stan::math::sort_asc<double, -1, 1>' requested here
T d = sort_asc(c);
^
test/unit/math/prim/mat/fun/sort_test.cpp:62:3: note: in instantiation of function template specialization
'test_sort_asc<Eigen::Matrix<double, -1, 1, 0, -1, 1> >' requested here
test_sort_asc<Eigen::Matrix<double,Eigen::Dynamic,1> >();

[Robert Trangucci]

Looks like the exact same error I was getting on my PR. No solution yet, but I'll take a look later tonight.

Rob

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

[Ben Goodrich]

On Friday, September 2, 2016 at 7:28:17 PM UTC-4, Bob Carpenter wrote:

Or is there just something I'm not including that I should be including?

Probably stan_math/stan/math/prim/mat/fun/value_of_rec.hpp

Ben

[Bob Carpenter]

I get the same issue if I include that before
the check_not_nan include. It's pulling out the
vector-like trait properly.

Anyway, I don't want to debug this now, so I'm just
going to work around it for the current issue.

- Bob

[Bob Carpenter]

It may be one of those nasty include-order issues.
If I include stan/math/prim/mat/fun/value_of_rec.hpp ahead
of stan/math/prim/arr.hpp, then it compiles, but it doesn't
throw.

Back to looping for now.

- Bob

[Ben Goodrich]

On Friday, September 2, 2016 at 8:09:18 PM UTC-4, Bob Carpenter wrote:

It may be one of those nasty include-order issues.
If I include stan/math/prim/mat/fun/value_of_rec.hpp  ahead
of stan/math/prim/arr.hpp, then it compiles, but it doesn't
throw.  

check_pos_definite.hpp #includes value_of_rec.hpp last even though it should not be calling check_not_nan().

Ben

[Bob Carpenter]

[changed subject to make it easier to find]

Ah--figured it out when I looked at the test header.
Here's the order that works for the header file:

#include <stan/math/prim/mat/fun/Eigen.hpp>
#include <stan/math/prim/scal/err/check_not_nan.hpp>
#include <algorithm>

and the test file:

#include <stan/math/prim/mat.hpp>
#include <stan/math/prim/arr.hpp>
#include <gtest/gtest.h>
#include <limits>
#include <stdexcept>

If you swap mat.hpp and arr.hpp in the test file, the tests
fail. But in this order, they're OK.

I take back everyting I said about external files including
things piecemeal. If we ever get around to documenting the
math lib, we're going to have to make the order of header includes
clear to users.

This is all for the nan sorting issue. That led me down another
rabbit ole because the function was independently defined in
rev, fwd, and mix when it didn't need to be and the matrix and
array versions were both defined in the matrix path. I'm
trying to move things to matching our conventions for path layout
when I hit them. Looks like we may still have a ways to go.

- Bob

[Bob Carpenter]

This was an issue with the nan checks for sorting.
I posted the answer.

But the issue Ben raises should also be addressed.

- Bob

[Daniel Lee]

Thanks, Bob.

The order dependency really happens when we instantiate our traits. If certain files get included, and they typically have to do with Eigen or Boost, it instantiates templates that then screw up the rest of our compiles.

From external to our math library, we should only be bringing in one header and it should be the highest level required. For most of our current Stan code, that should be stan/math/rev/mat.hpp. For RHMC, it should be stan/math/mix/mat.hpp.

The difficulty is within the math library and our tests. We really want to include the minimal set of things.

One thing we could do is create includes for traits. If you're using reverse mode and matrix, it'd be an include for the traits, then include whatever file you want to test. There'd be one that mirrors each of our includes. That would allow our tests to have less includes.

Re: value_of_rec -- I haven't looked too carefully at it, but there might be a better way to implement this. It's caused us trouble in the past and perhaps there's a simpler way to implement it.

Thanks again, Bob.

Daniel

>>> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>>

>
> --
> 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+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>

--
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+unsubscribe@googlegroups.com.

[Bob Carpenter]

Thanks. I simplified the includes. I was just using the ones
that were already there and didn't realize the mat.hpp
included the arr.hpp. There were also redundant lower-order
ones (like fwd and then prim, or mix and then rev and then fwd and then
prim). I cleaned them up for all the tests I touched.

It's nice to be working at 3 AM Friday night and have everyone up in
NY to answer questions. Nothing like pre-release weekend.

- Bob

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

[Joshua N Pritikin]

On Fri, Sep 02, 2016 at 08:32:11PM -0400, Daniel Lee wrote:
> The order dependency really happens when we instantiate our traits. If
> certain files get included, and they typically have to do with Eigen or
> Boost, it instantiates templates that then screw up the rest of our
> compiles.

Is there a way to catch this kind of thing with the C preprocessor? For
example, a trait could #define I_AM_A_TRAIT and then if some other
header got included later in the wrong order then you could #error

?

--
Joshua N. Pritikin, Ph.D.
Virginia Institute for Psychiatric and Behavioral Genetics
Virginia Commonwealth University
PO Box 980126
800 E Leigh St, Biotech One, Suite 1-133
Richmond, VA 23219
http://people.virginia.edu/~jnp3bc

[Bob Carpenter]

I think that's a great idea if we can isolate when things are
out of order. I'm not sure how easy it'll be to predefine these
things. Daniel --- any idea?

We were thinking just having higher-level includes would help
the problem, but then we went and wrote tests that violated our
general principles, so clearly the API exposes the danger as is.

I created the issue and attributed it to @jpritikin

https://github.com/stan-dev/math/issues/383

Thanks for the suggestion.

- Bob

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