[R-pkg-devel] Discovering M1mac cowpads

[Simon Urbanek]

John,

you provide no details to go on, but generally the main difference is that arm64 uses 64-bit precision for long double (which is permitted by the C standard), while Intel uses 80-bits of precision (on systems that enable it). That leads to differences in results, e.g. when computing long sums:

set.seed(1); x=rnorm(1e6)

## Intel with extended precision
> sprintf("%a", sum(x))
[1] "0x1.7743176e2372bp+5"

## arm64
> sprintf("%a", sum(x))
[1] "0x1.7743176e23a33p+5"


For R you can get the same results on all platforms by using --disable-long-double which prevents the use of extended precision doubles in R - this is Intel with --disable-long-double:

> sprintf("%a", sum(x))
[1] "0x1.7743176e23a33p+5"

Cheers,
Simon



> On Mar 25, 2023, at 8:03 AM, J C Nash <profjcnash using gmail.com> wrote:
> 
> Recently I updated my package nlsr and it passed all the usual checks and was
> uploaded to CRAN. A few days later I got a message that I should "fix" my
> package as it had failed in "M1max" tests.
> 
> The "error" was actually a failure in a DIFFERENT package that was used as
> an example in a vignette. I fixed it in my vignette with try(). However, I
> am interested in just where the M1 causes trouble.
> 
> As far as I can determine so far, for numerical computations, differences will
> show up only when a package is able to take advantage of extended precision
> registers in the IEEE arithmetic. I think this means that in pure R, it won't
> be seen. Packages that call C or Fortran could do so. However, I've not yet
> got a good handle on this.
> 
> Does anyone have some small, reproducible examples? (For me, reproducing so
> far means making a small package and submitting to macbuilder, as I don't
> have an M1 Mac.)
> 
> Cheers,
> 
> John Nash
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>