Ryan, Thanks so much for your awesome explanation and for looking into it! It's really amusing (to me anyways) that, just before reading this, I was going through the armadillo docs and read the following:
- *Can I use the C++11 auto keyword with Armadillo objects and/or expressions?* Use of C++11 *auto* is *not recommended* with Armadillo objects and expressions. Armadillo has a template meta-programming framework which creates lots of short lived temporaries that are not handled by *auto*. and *immediately* thought "maybe this is what's happening with my SDP code". HAHAHA. I will try it out and let you know how it goes. On Mon, Sep 2, 2019 at 10:57 AM Ryan Curtin <[email protected]> wrote: > On Mon, Sep 02, 2019 at 09:21:32AM -0700, Joe Dinius wrote: > > Sure, no problem. Attached is a compressed minimal example that only has > > armadillo (9.599) and ensmallen (1.15.1) as dependencies; openmp is > > optional. > > Hey Joe, > > Thanks for the code---I was able to unpack and build it really easily. > I found the issue and it is actually caused by a somehow-invalid use of > 'auto'. Here was my debugging route: > > First I compiled the program and ran to verify that it gave the same > output as you saw. Indeed it did... so I then used gdb to see how large > of a matrix it tried to allocate. I discovered that size_Y at line 115 > of ensmallen-sdp.cpp had a value of 93824992850192. That seemed... > invalid. > > Then, I also found that constr_map.A_[0] had reasonable size (less than > 300 rows and columns). > > I noticed that 'size_Y' was being set like this: > > auto const & size_Y = constr_map.getConstraintMapA()[0].n_rows; > > In the past, I've learned to avoid using 'auto' because sometimes it can > infer the wrong types. Generally I will see this happen with longer > Armadillo expressions. For instance, the following code scares me: > > using namespace arma; > mat x, y; > auto z = x.t() * y + (x.t() * x - 3); > > The reason that scares me is because we are hoping that the compiler > will infer 'mat' as the type of z, but we don't have a guarantee. In > fact, more often than not, it will infer some internal Armadillo type > that represents the expression (due to Armadillo's delayed evaluation > framework), and this will result in code that doesn't behave as > expected. > > I'm quite surprised, though, that 'auto' failed to infer the correct > type of n_rows, which is arma::uword. When I changed it to the > following (I prefer size_t to uword), the test ran without error: > > size_t const & size_Y = constr_map.getConstraintMapA()[0].n_rows; > > I'm unsure of why the compiler had an issue with this, since there's no > delayed expression. Perhaps it has to do with dereferencing the > std::vector getConstraintMapA()---I am not sure. > > In any case, I hope this is helpful! If you dig in further and figure > out why the type is being inferred wrong, I'd be interested to find out. > But for now I will just continue to avoid 'auto' unless there is no > possibility the compiler can get it wrong. :) (And even then I might > avoid it too, just for paranoia's sake!) > > -- > Ryan Curtin | "Because for the people who knew what it was, it > [email protected] | would be attacking their brain." >
_______________________________________________ mlpack mailing list [email protected] http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
