M1mac numerical issues should be rare, but when they do pop up they can be disconcerting.
The following little script reveals what happens with no extended precision. A few months ago I built this into a "package" and used https://mac.r-project.org/macbuilder/submit.html to run it, getting the indicated result of 0 for (sum(vv1) - 1.0e0), with non-zero on my Ryzen 7 laptop. JN # FPExtendedTest.R J C Nash loopsum <- function(vec){ n <- length(vec) vsum<-0.0 for (i in 1:n) { vsum <- vsum + vec[i]} vsum } small<-.Machine$double.eps/4 # 1/4 of the machine precision vsmall <- rep(small, 1e4) # a long vector of small numbers vv1 <- c(1.0, vsmall) # 1 at the front of this vector vv2 <- c(vsmall, 1.0) # 1 at the end (sum(vv1) - 1.0e0) # Should be > 0 for extended precision, 0 otherwise (sum(vv2) - 1.0e0) # Should be > 0 (loopsum(vv1) - 1.0e0) # should be zero (loopsum(vv2) - 1.0e0) # should be greater than zero On 2024-02-06 08:06, Prof Brian Ripley via R-devel wrote:
We were left to guess, but I doubt this has to do with the lack of 'extended precision' nor long doubles longer than doubles on arm64 macOS. And issues with that are rather rare (much rarer than numerical issues for non-reference x86_64 BLAS/LAPACKs). Of the 20,300 CRAN packages just 18 have M1mac-specific errors, none obviously from numerical inaccuracy. A quick look back suggests we get about 20 a year with M1mac numerical issues, about half of which were mirrored on the x86_64 'noLD' checks.
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
