[Rd] Advice debugging M1Mac check errors

[J C Nash]

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.
>