From pro|jcn@@h @end|ng |rom gm@||@com  Tue Feb  6 17:37:26 2024
From: pro|jcn@@h @end|ng |rom gm@||@com (J C Nash)
Date: Tue, 6 Feb 2024 08:37:26 -0800
Subject: [Rd] Advice debugging M1Mac check errors
In-Reply-To: <90026864-f81c-4663-8cfe-6ae99d23307b@stats.ox.ac.uk>
References: <CAFDswJu2aDQzCZHJT7RqyBP-J8DLcj6PLzRBHbcStfxBJvw5Mg@mail.gmail.com>
 <90026864-f81c-4663-8cfe-6ae99d23307b@stats.ox.ac.uk>
Message-ID: <f46816fb-12fc-4763-b4e2-08c7d312fccc@gmail.com>

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



[Rd] Advice debugging M1Mac check errors
J C Nash