[R-pkg-devel] [External] Test fails on M1 Mac on CRAN, but not on macOS builder
Simon Urbanek
@|mon@urb@nek @end|ng |rom R-project@org
Mon May 22 22:46:46 CEST 2023
Florian,
ok, understood. It works for me on both M1 build machines, so can't really help. I'd simply submit the new version on CRAN. Of course it would help if the tests were more informative such as actually showing the values involved on failure so you could at least have an idea from the output.
Cheers
Simon
> On May 22, 2023, at 11:07 PM, Pein, Florian <f.pein using lancaster.ac.uk> wrote:
>
> Dear Duncan and Simon,
> thank you both very much for you help.
>
> I can make the test more informative and also break it down into substeps. But I am unsure whether CRAN policies allow to use their system for such testing steps. I rather think not. Though I must say that I still do not know how to otherwise fix the error. Can anyone, ideally a CRAN maintainer, confirm that this is okay?
>
> Regarding the tolerance, the test compares to small integers. In this specific situation both sides are 5L on my local system. The tolerance is there to ensure that
> ncol(compareStat) * testalpha is not something like 4.999999999 due to floating point approximations and we end up with 4L when as.integer() is applied. This is not happening in the concrete example, since ncol(compareStat) * testalpha = 5.67. I am very sure that the error is on the left hand side and compare is larger than 5.
>
> In fact, tol in
> rejected[, i] <- teststat[i, ] > ret[i] + tol
> may need to be larger, since teststat contains quite large values. I think there is a realistic chance that a floating point error occurs at this point. But once again, I do not want to send a random guess to CRAN when I cannot test whether this has fixed the problem or not. I have tested the old code with --disable-long-double and compiler flags such as -ffloat-store and -fexcess-precision=standard and it works. I do not know to what degree this ensures that it works on all systems.
>
> Many thanks and best wishes,
> Florian
>
More information about the R-package-devel
mailing list