From pro|jcn@@h @end|ng |rom gm@||@com  Sun Feb  4 22:47:27 2024
From: pro|jcn@@h @end|ng |rom gm@||@com (J C Nash)
Date: Sun, 4 Feb 2024 13:47:27 -0800
Subject: [Rd] Advice debugging M1Mac check errors
In-Reply-To: <26047.60105.385115.834455@rob.eddelbuettel.com>
References: <CAFDswJu2aDQzCZHJT7RqyBP-J8DLcj6PLzRBHbcStfxBJvw5Mg@mail.gmail.com>
 <26047.60105.385115.834455@rob.eddelbuettel.com>
Message-ID: <e7c3318f-7f31-42af-9bd0-c8df686d5bcb@gmail.com>

Slightly tangential: I had some woes with some vignettes in my
optimx and nlsr packages (actually in examples comparing to OTHER
packages) because the M? processors don't have 80 bit registers of
the old IEEE 754 arithmetic, so some existing "tolerances" are too
small when looking to see if is small enough to "converge", and one
gets "did not converge" type errors. There are workarounds,
but the discussion is beyond this post. However, worth awareness that
the code may be mostly correct except for appropriate tests of
smallness for these processors.

JN




On 2024-02-04 11:51, Dirk Eddelbuettel wrote:
> 
> On 4 February 2024 at 20:41, Holger Hoefling wrote:
> | I wanted to ask if people have good advice on how to debug M1Mac package
> | check errors when you don?t have a Mac? Is a cloud machine the best option
> | or is there something else?
> 
> a) Use the 'mac builder' CRAN offers:
>     https://mac.r-project.org/macbuilder/submit.html
> 
> b) Use the newly added M1 runners at GitHub Actions,
>     https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/
> 
> Option a) is pretty good as the machine is set up for CRAN and builds
> fast. Option b) gives you more control should you need it.
> 
> Dirk
>



[Rd] Advice debugging M1Mac check errors
J C Nash