[mlpack] maximum problem size for PrimalDualSolver?

[Joe Dinius]

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 <ryan at ratml.org> 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
> ryan at ratml.org | would be attacking their brain."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://knife.lugatgt.org/pipermail/mlpack/attachments/20190902/86139615/attachment-0001.html>