On 12 February 2018 at 04:52, Dirk Eddelbuettel <e...@debian.org> wrote:
> > On 11 February 2018 at 19:13, Baptiste Auguie wrote: > | Hi, > | > | Sorry I never found the time to put this issue to rest. My cda package > has > | now been removed from CRAN because Armadillo's update on 'banded > | matrices' broke > | it on various platforms, and I've had users enquire about the situation. > As > | far as I can tell RcppArmadillo no longer enables the solution of complex > | linear systems on all platforms (see below). I'm happy to contribute a > new > > I don't think that is a fair statement. > > Armadillo, and RcppArmadillo, offer you an elegant, easy-to-use and rather > performant interface to underlying LAPACK code. In the R universe, we rely > on the LAPACK "brought to us by R". That generally works but ... > > ... you are, and have been, pushing the edge further by requiring complex > data types---and now Conrad chose to rely on another LAPACK routine. Bang. > > As far as I can tell Armadillo added specialised methods for banded matrices; the routines used to solve non-banded matrices probably haven't changed. Coming back to the error itself, what puzzles me is that it seems to be precisely the OSes relying on external Lapack that have a problem. It compiles fine on Windows, https://builder.r-hub.io/status/isolve_1.0.tar.gz-e3da3c1b83 26e62e4e14a913e5bbb5a4 So it seems the problem is distinct from the previous issues with missing Lapack routines. > | test for this to help future-proof this recurring issue, but resolving > the > | underlying issue is beyond me. > > That's the problem. > > You may need to look at other package with, when needed, extend offered > libraries. I.e. I also stand behind BH and hence parts of Boost, but > sometimes packages (e.g. in the stan world) need extra functions and so > they > package them. Upstream MLPACK is another example, and it extends Armadillo > where needed. > > Dirk > > | For the sake of clarity and concreteness I've put a minimal example > package > | here: > | > | https://github.com/baptiste/isolve > | > | which builds on my local mac but fails the online r-hub build > | (interestingly, on a linux machine, which also puzzled me about cda's > logs) > | > | https://builder.r-hub.io/status/isolve_1.0.tar.gz-757573eaf5 > b0cb30d8154d7b8f7e2bc7 > | > | Thanks for any advice, > | > | baptiste > | > | > | > | > | > | > | On 20 December 2017 at 02:24, Dirk Eddelbuettel <e...@debian.org> wrote: > | > | > > | > On 19 December 2017 at 13:41, Ralf Stubner wrote: > | > | On 19.12.2017 09:38, Baptiste Auguie wrote: > | > | > Thanks for the pointer to `arma::solve_opts::no_band`, it sounds > like a > | > | > good solution (assuming the compiler will then skip all the parts > | > | > related to banded inversion routines). I've been unable to test it > so > | > | > far; I haven't managed to reproduce the error reported on CRAN on a > | > mac. > | > | > | > | Reproducing this error is not easy. I was able to do so using docker > | > > | > Just work on Windows, or on any R built so that its internal BLAS are > | > used. You can force that via configure at build time. > | > > | > | with > | > | https://github.com/rocker-org/rocker-versioned/blob/master/ > | > r-ver/3.4.3/Dockerfile > | > | as starting point. If you remove lines 30 and 97 (openblas-dev and > | > | --with-blas), you can build a docker image with R included that uses > the > | > | BLAS and LAPACK supplied by R. > | > | > | > | I have given this a try and installing 'cda' in such a image does > indeed > | > | reproduce the error. Unfortunately adding > 'arma::solve_opts::no_band' to > | > | the two places where arma::solve is used did not help in my tests :-( > | > > | > :-( > | > > | > Maybe Arma needs another patch. > | > > | > | > The 'crippled Lapack' macro was useful as a workaround in the past > but > | > | > I'm not sure of its exact mode of operation so I'm reluctant to set > | > | > something to "cripple" the code (does it target only those routines > | > that > | > | > are found missing, or is it more of a blanket switch with no > | > fine-tuning?). > | > | > | > | I think it is a blanket switch that will affect also those methods > that > | > | where already added in the past. So this would be only a temporary > | > | solution, but I think that's what you need right now. > | > | > | > | BTW, setting ARMA_CRIPPLED_LAPACK is more difficult than I thought > since > | > | it is #undefed in the RcppArmadillo-Config. Short of editing that > file, > | > | you can add this to src/Makevars > | > | > | > | PKG_CXXFLAGS=-DARMA_CRIPPLED_LAPACK > | > | -DRcppArmadillo__RcppArmadilloConfigGenerated__h > | > | > | > | I hope there is a better way ... > | > > | > Set the #define after the #include <RcppArmadillo.h> ? > | > > | > RcppArmadillo is just the man in the middle. This is between Baptiste > | > relying on something that is now always available, and Conrad assuming > it > | > is. > | > > | > I think Baptiste will need to decompose all these pieces and rearrange > | > then. > | > Or just build his own solve() method based on older Armadillo code? > | > > | > Dirk > | > > | > -- > | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > | > > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel