Suggest to change y = max(y, x) to y = arma::max(y, x).

C++ is notorious for problems involved with Argument Dependent Lookup (ADL). For example, the compiler may viably think that max(y,x) is supposed to mean std::max(y,x), and then spit out an error, complaining that std::max() doesn't know what to do with the arguments.

Placing the arma:: namespace qualification ensures that only max() from Armadillo is meant here.

The rules for ADL are quite byzantine and easily abused: https://en.cppreference.com/w/cpp/language/adl

I intentionally removed the arma because I do not see another way of using this function with coot.
Do you have a solution for this problem?

The longer-term aim here is to be able to use Armadillo or Bandicoot with the same mlpack code. After all, the linear algebraic operations themselves live at a higher level of abstraction than the details of how the matrices are stored (for the most part). That has been our goal for several years, and ADL is the only reasonable way to accomplish this. Although there are some warts with ADL, and it is complicated and routinely criticized, it is hard to see how it can go wrong for something like this.

If you have max(y, x) where y and x are objects from the arma:: namespace, then arma:: is added to the list of namespaces that are searched for the best match for max(), and everything works fine. If it does not work fine, and the user has not done anything "malicious" like adding other matching overloads that can cause the compiler to hiccup (which they shouldn't be doing anyway!), then the issue is a compiler bug.

I suggest to provide an overloaded function specialised for Bandicoot matrices, possibly within an #ifdef MLPACK_USE_BANDICOOT guard:

static void Fn(const coot::Mat<eT>& x, coot::Mat<eT>& y)

The function would contain a call to coot::max(). It's perfectly fine to have both Armadillo and Bandicoot implementations of Fn() available at the same time.

In my experience it's less painful to not rely on ADL. Here's an example of ADL weirdness from ~5 years ago: https://gitlab.com/conradsnicta/armadillo-code/-/issues/94

Within Armadillo, the max() function is implemented using template restrictors, which may have unintended interactions with ADL voodoo:
https://gitlab.com/conradsnicta/armadillo-code/-/blob/12.6.x/include/armadillo_bits/fn_max.hpp?ref_type=heads#L73-92

Yes, but what I am getting at is that without ADL, every single linear algebra expression inside mlpack will need to have duplicate Bandicoot and Armadillo implementations. That's a massive amount of extra code to maintain and keep up to date---it's not realistic.

If we have to make exceptions explicitly for min() and max() and size() (due to the naming conflicts with std:: functionality), that's fine, but the way to do that would be to have an mlpack-local min() and max() implementation that redirect to the correct Armadillo/Bandicoot implementations instead of using ADL. But for the rest of the functionality in those libraries (e.g., say, repmat() or repelem() or eig_sym() or whatever), ADL should suffice.

Yeah, I also suspect that the main problem is interference from functions defined in the std namespace. Besides the usual suspects (min(), max(), size()) there are also other std functions that have same name as arma functions: clamp(), abs(), arg(), etc.