[R-pkg-devel] help with BLAS/LAPACK version debugging

Avraham Adler @vr@h@m@@d|er @end|ng |rom gm@||@com
Tue Apr 12 06:29:56 CEST 2022


If it helps, this is on Windows 10 64bit, R 4.2.0alpha, OpenBLAS
0.3.17 (single threaded, custom compiled for i7-8700K Skylake which
functions as a Haswell), but default R LAPACK since I still have not
figured out how to link to a precompiled LAPACK when building natively
on Windows.

Thanks,

Avi

# 1
set.seed(101)
d <- data.frame(z=rnorm(200),
                  f=factor(sample(1:10,200, replace=TRUE)))
library(lme4)
library(testthat)
fm1 <- lmer(z~ as.numeric(f) + 1|f, d)

R throws--> "boundary (singular) fit: see help('isSingular')"

> fm1 using optinfo$derivs$Hessian[2,2] <- NA

> expect_warning(lme4:::checkConv(fm1 using optinfo$derivs,
                                  coefs=c(1,1),
                                  ctrl=lmerControl()$checkConv,lbound=0),
                 "Problem with Hessian check")

(No warning thrown)

# 2
dd <- list(gradient = c(0.00132136676711525, 0.00898197413334856, 0),
   Hessian = structure(c(195.253128051758, 962.483270645142,
                         0, 962.483270645142, NA, 0, 0, 0, 6542.44775390625),
                         dim = c(3L, 3L)))
with(dd, solve(chol(Hessian),gradient))

R throws--> Error in h(simpleError(msg, call)) :
  error in evaluating the argument 'a' in selecting a method for
function 'solve': the leading minor of order 2 is not positive
definite

# 3 (Windows returns empty strings for BLAS and LAPACK)

R version 4.2.0 alpha (2022-04-03 r82074 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19043)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United
States.utf8    LC_MONETARY=English_United States.utf8
[4] LC_NUMERIC=C                           LC_TIME=English_United
States.utf8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] testthat_3.1.3 lme4_1.1-29    Matrix_1.4-1

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.8.3    lattice_0.20-45 rprojroot_2.0.3 withr_2.5.0
brio_1.1.3      MASS_7.3-56     grid_4.2.0
 [8] R6_2.5.1        nlme_3.1-157    magrittr_2.0.3  rlang_1.0.2
cli_3.2.0       minqa_1.2.4     nloptr_2.0.0
[15] boot_1.3-28     desc_1.4.1      splines_4.2.0   tools_4.2.0
pkgload_1.2.4   compiler_4.2.0

On Tue, Apr 12, 2022 at 1:18 AM Dirk Eddelbuettel <edd using debian.org> wrote:
>
>
> Ben,
>
> I fear your post is too short on specifics on versions tested, and results
> seen. We need more drill-down on what-version-where and the results it got.
>
> So to bootstrap, "here" on my personal dev box I where I tend to keep an
> installation of R-devel (using its embedded LAPACK/BLAS sources) as well as
> the standard R package I stand behind for Debian/Ubuntu (which tends to use
> external libraries for BLAS/LAPACK).
>
>
> Now, here I seem to get a different error between reference BLAS/LAPACK and
> external BLAS/LAPACK:
>
>
> 1) R-devel (as SVN r82134)
>    using libRblas.so + libRlapack.so (i.e. "reference BLAS") gets me
>
>    Error in chol.default(Hessian) :
>      the leading minor of order 2 is not positive definite
>
>
> 2) R-devel as I upload to Debian, same SVN r82134
>    using external blas: openblas-pthread/{libblas.so.3 + libopenblasp-r0.3.20.so}
>
>    package version libopenblas0 0.3.20, liblapack 3.10.0
>
>    Error in solve.default(chol(Hessian), gradient) :
>      system is computationally singular: reciprocal condition number = 0
>
>
> 3) For what it is worth every release R version I put into Debian and which
>    is still available (easily, I find) via rocker/r-base or r-base images
>
>    Using 4.0.4 here (again: openblas-pthread/{libblas.so.3 + libopenblasp-r0.3.13.so}
>    (but possibly an older version -- libopenblas 0.3.13, liblapack 3.9.0-3)
>
>    Error in solve.default(chol(Hessian), gradient) :
>      system is computationally singular: reciprocal condition number = 0
>
>
> I don't claim that the above is complete; I am only pointing out that both
> LAPACK 0.3.9 and 0.3.10 _get me the same error_.  Conrad and I recently did
> dig up an issue for (Rcpp)Armadillo where 0.3.10 _was_ different from 0.3.9,
> but that was for complex-value variables.
>
> The bigger difference seems to be between using R's reference blas, and
> external blas.  I have for a decade+ used external BLAS even when the
> official word to prefer reference BLAS. Now, and very recently NEWS in R seem
> to go the same way prefering 0.3.10 where available.
>
> I hope this helps. I can give you pointers (off-list) if you want to dig some
> more via Docker and different combinations.
>
>
> Cheers, Dirk
>
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



More information about the R-package-devel mailing list