[R-SIG-Mac] .Machine differences between Intel and M1

[Matthew Heun]

All:

In fact, I also have

> > capabilities("long.double")
> long.double 
>       FALSE 

on my M1 machine.  I made a mistake earlier (was "on" the Intel machine, accidentally).  I'm sorry for misleading anyone.

I will need to adjust the tolerance on my tests for the M1.  I think that's somewhat unfortunate, but what can we do?

I really appreciate the insights from Simon and Brian.  Thank you so much for the quick answers!

Happy Holidays, everyone.

Cheers,

Matt






> On Dec 21, 2021, at 4:10 PM, Prof Brian Ripley <ripley using stats.ox.ac.uk> wrote:
> 
> On 21/12/2021 20:46, Simon Urbanek wrote:
>> Matt,
>> yes, arm64 does not support long doubles. In C the long double type is 64-bit there so has the same precision as doubles (this is allowed by the standard).
> 
> And documented in ?.Machine.
> 
> However, I see on my M1 Pro
> 
>> capabilities("long.double")
> long.double
>      FALSE
> 
> on all the arm64 builds I have installed, including the current CRAN distribution (of 4.1.2) and that at mac.r-project.org (see below).  So I have no idea why TRUE is reported below (if this really was an arm64 build run on the M1 Pro).
> 
> R version 4.1.2 Patched (2021-12-16 r81394) -- "Bird Hippie"
> ...
> > capabilities('long.double')
> long.double
>      FALSE
> 
> 
>> Cheers,
>> Simon
>>> On Dec 22, 2021, at 9:21 AM, Matthew Heun via R-SIG-Mac <r-sig-mac using r-project.org> wrote:
>>> 
>>> All:
>>> 
>>> I'm seeing some test failures on a new M1 Pro machine that I do not see on my Intel machine.  I'm investigating whether the test failures are caused by machine precision differences.  On my M1 Pro machine, differences of large numbers are greater than a specified tolerance.  (On my Intel machine, differences between the supposed same numbers are within tolerance.)
> 
> A small number of packages (and R itself) have needed tolerances increased for checks on arm64.
> 
>>> 
>>> The output of .Machine shows some differences.  I have 2 questions below, each identified by "****".
>>> 
>>> (1) For sizeof.longdouble, I see the following:
>>> 
>>> Intel machine:
>>> 
>>>> $sizeof.longdouble
>>>> [1] 16
>>> 
>>> M1 Pro machine:
>>> 
>>>> $sizeof.longdouble
>>>> [1] 8
>>> 
>>> 
>>> 
>>> ?.Machine says:
>>> 
>>> sizeof.longdouble	
>>> the number of bytes in a C long double type. Will be zero if there is no such type (or its use was disabled when R was built), otherwise possibly12 (most 32-bit builds) or 16 (most 64-bit builds).
>>> 
>>> The M1 Pro uses a 64-bit architecture.  So this result is surprising to me.
>>> 
>>> Furthermore,
>>> 
>>>>> capabilities("long.double")
>>>> long.double
>>>>       TRUE
>>> 
>>> So somebody thinks that long doubles are supported.
>>> 
>>> **** Is the difference in sizeof.longdouble between the Intel and M1 architectures expected?
>>> 
>>> 
>>> (2) Also, my M1 Pro machine is missing additional fields (that the Intel machine reports):
>>> 
>>>> $longdouble.eps
>>>> [1] 1.084202e-19
>>>> 
>>>> $longdouble.neg.eps
>>>> [1] 5.421011e-20
>>>> 
>>>> $longdouble.digits
>>>> [1] 64
>>>> 
>>>> $longdouble.rounding
>>>> [1] 5
>>>> 
>>>> $longdouble.guard
>>>> [1] 0
>>>> 
>>>> $longdouble.ulp.digits
>>>> [1] -63
>>>> 
>>>> $longdouble.neg.ulp.digits
>>>> [1] -64
>>>> 
>>>> $longdouble.exponent
>>>> [1] 15
>>>> 
>>>> $longdouble.min.exp
>>>> [1] -16382
>>>> 
>>>> $longdouble.max.exp
>>>> [1] 16384
>>> 
>>> **** Is there a reason why the above entries are missing from the output of .Machine on the M1 Pro machine?
>>> 
>>> 
>>> 
>>> My R installation is:  4.1.2 Patched (2021/12/16, r81394)
>>> 
>>> 
>>> 
>>> Any help will be appreciated.
>>> 
>>> 
>>> 
>>> Cheers,
>>> 
>>> Matt
> 
> 
> -- 
> Brian D. Ripley,                  ripley using stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford