[mlpack] maximum problem size for PrimalDualSolver?

[Ryan Curtin]

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