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 <[email protected]> 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
>>> <[email protected]> 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, [email protected]
> Emeritus Professor of Applied Statistics, University of Oxford
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
