Optimized numeric libraries are prone to getting slightly different results, which can trip up the checks. Howver, this case seems to be one of not passing NaN values properly:
What should happen is this > a <- matrix(NaN, 3, 3,, list(one=1:3, two=letters[1:3])) > b <- cbind(1:3, NA) > solve(a,b) [,1] [,2] a NaN NA b NaN NA c NaN NA > a two one a b c 1 NaN NaN NaN 2 NaN NaN NaN 3 NaN NaN NaN > but somewhere along the way, the computations are creating a 0 out of the NaN in the coefficient matrix. This look like dangerous behaviour that R cannot support. -pd > On 21 Jan 2025, at 14:42 , Christian Tuma <t...@zib.de> wrote: > > Hello, > > We are running an AMD-Genoa compute cluster. For this system I compiled > R-4.4.2 configured and linked against AMD Optimizing CPU Libraries (AOCL) > downloaded from > > https://www.amd.com/en/developer/aocl.html > > When running the R test suite (make check), I get this error: > > $ cat tests/lapack.Rout.fail > ... > > ## ------- tests of non-finite values ----------------- > > > > a <- matrix(NaN, 3, 3,, list(one=1:3, two=letters[1:3])) > > b <- cbind(1:3, NA) > > dimnames(b) <- list(One=4:6, Two=11:12) > > bb <- 1:3; names(bb) <- 11:12 > > ## gave error with LAPACK 3.11.0 > > ## names(dimnames(.)), ("two", "Two") are lost {FIXME?}: > > ## IGNORE_RDIFF_BEGIN > > stopifnot(is.na(print(solve(a, b )))) # is.na(): NA *or* NaN > Error in solve.default(a, b) : > Lapack routine dgesv: system is exactly singular: U[1,1] = 0 > Calls: stopifnot -> print -> solve -> solve.default > Execution halted > > Now I wonder whether AOCL are supported by R or not. Did somebody already use > this combination successfully? Is this test suite error a serious problem? Is > a workaround available? > > This is my R installation configuration line: > > $ CC=gcc CFLAGS="-O3 -march=znver4" \ > CXX=g++ CXXFLAGS="-O3 -march=znver4" \ > FC=gfortran FCFLAGS="-O3 -march=znver4" \ > LDFLAGS="-Wl,-rpath=$GCC_PATH/lib64" \ > ../configure \ > --with-blas="-L/usr/lib64 -Wl,-rpath=$AOCL_ROOT/lib_LP64 > -L$AOCL_ROOT/lib_LP64 -lblis -lflame" \ > --with-lapack \ > --enable-year2038 > > I am using the GCC (13.3.0). > > > sessionInfo() > R version 4.4.2 (2024-10-31) > Platform: x86_64-pc-linux-gnu > Running under: Rocky Linux 9.4 (Blue Onyx) > > Matrix products: default > BLAS: /sw/numerics/aocl/5.0.0/gcc/lib_LP64/libblis.so.5.0.0 > LAPACK: /sw/numerics/aocl/5.0.0/gcc/lib_LP64/libflame.so; LAPACK version > 3.11.0 > ... > > > With Intel MKL instead of AOCL the test suite passes without errors. But this > is an AMD system, so here I tend to prefer AOCL over MKL. > > Any ideas? Thank you. > > > Best wishes, > Christian > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd....@cbs.dk Priv: pda...@gmail.com ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
