Re: [R-pkg-devel] Solaris segfaults
I think I got confused by the fact that the second line of
https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
is "Solaris 10 on ix64/x64".
I interpreted that as "64-bit Solaris". On the other hand the rest
of the information in that file says that the default ODS compiler used
is a 32-bit build; it doesn't say anything about the build of the
alternative gcc compiler (which is used for packages with Rcpp etc.)
Other comments farther down in the file (about versions of Java,
protobuf used) do suggest that the system is indeed 32-bit.
If the CRAN Solaris platform is indeed 32-bit, then I really have no
idea why checks are failing on CRAN but succeeding on r-hub (but I also
feel better about not trying to fix it ...)
I do appreciate the provision of the resources for setting up a
virtual Solaris box - I don't recall exactly what hurdle I encountered
last time I tried, it was probably some weird idiosyncratic thing.
For the record I haven't tried valgrind recently, but the CRAN
versions of the valgrind tests weren't throwing any errors ...
https://cran.r-project.org/web/checks/check_issue_kinds.html
thanks
Ben Bolker
On 9/15/21 2:19 AM, Gábor Csárdi wrote:
Hi Ben,
According to https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
CRAN's Solaris is also 32 bit.
But maybe I am missing something?
You can download a Solaris VM (for Virtualbox or VMware) from
https://files.r-hub.io/solaris/
It has both 32 bit and 64 bit R (with gcc) and ODS R as well. You can
update R on it like this:
https://github.com/r-hub/solarischeck/tree/master/packer#updating-r
Best,
Gabor
On Wed, Sep 15, 2021 at 1:51 AM Ben Bolker wrote:
I may have asked something like this before, but ...
The glmmTMB package is currently segfaulting (on the very first example)
on its CRAN Solaris checks
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/glmmTMB-00check.html
> ## Comparing variance-covariance matrix with manual computation
> data("sleepstudy",package="lme4")
> fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)
*** caught segfault ***
address 4539ec45, cause 'memory not mapped'
---
We have to submit a new version to CRAN soon; we will most likely beg
the CRAN maintainers' indulgence for having it fail on Solaris, but it
would be nice to fix it if we can.
The CRAN Solaris platform is 64-bit x86_64, using gcc/g++ because
the package uses Rcpp.
The package builds/checks fine on the r-hub `solaris-x86-patched`
platform, which is identical as far as I can tell **except** 32-bit
rather than 64-bit.
Short of installing 64-bit Solaris in a VM (which I have not done yet
because of random compatibility/command-line bullshittery that put me
off), does anyone have any wisdom to share for diagnosing and/or
guessing what the problem is?
Here are some links to similar errors, none of them seem terribly
useful/relevant.
https://github.com/gagolews/stringi/issues/94
https://mran.microsoft.com/snapshot/2017-07-05/web/checks/check_results_vcfR.html
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/prt-00check.html
glmmTMB is built on a pretty big stack (Eigen, Rcpp, RcppEigen,
CppAD, TMB) - the problem could be somewhere in there (the TMB package
runs no tests and very few examples on CRAN, so there could be problems
there that only get flagged when we try glmmTMB examples).
More discussion at
https://github.com/glmmTMB/glmmTMB/issues/732 (with some red herrings)
if anyone is interested.
cheers
Ben Bolker
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Question about quantile fuzz and GPL license
Martin Maechler wrote: > OTOH, type=7 is the default, and I guess used in 99.9% of > all uses of quantile, *and* does never use any fuzz Indeed. This also implies that this default should be well-thought when creating a new implementation of the quantile() procedure for a new programming language or library. Most of the time, users use the default procedure, and do not report the procedure used in the statistical analysis reports, scientific or non-scientific articles produced. The differences between all quantiles procedures are minor, unless they are used in crazy scenarios such as a sample size of 2, or with probs=0.001 for a sample of size 1000. But, standardization of procedures is desirable for analysis reproducibility, as well as teaching (see https://doi.org/10.1080/10691898.2006.11910589 ). Hyndman and Fan wanted that software package standardize their definition, but to no avail: See https://robjhyndman.com/hyndsight/sample-quantiles-20-years-later/ In the absence of standard, my personal advice would be to use the same default as a popular statistical software, such as R or SAS. R, Julia and NumPy (python) uses type 7 as default. Microsoft Excel and LibreOffice Calc use type 7 as default (although Excel versions >= 2010 have new procedures). SAS uses type 3 as default, unless prob=0.50 Stata uses type 2 or type 6, depending on the procedure (https://data.princeton.edu/stata/markdown/quantiles.htm) -- Sincerely André GILLIBERT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Bioc-devel] New Package Submission Deadline for Bioc Release 3.14
The final day to submit new packages to the Bioconductor contributions tracker to have a shot at being included in the upcoming 3.14 release is Friday October 1st. Please note: submission by this date does not guarantee it will be included - the package must undergo an official review and be accepted by Wednesday October 20th. https://github.com/Bioconductor/Contributions Submissions after Friday October 1st and those that are not accepted by October 22nd will still be able to be in Bioconductor but will be included in the development branch until the 3.15 release next Spring. Please see the release schedule for other important deadlines https://bioconductor.org/developers/release-schedule/ Thank you on behalf of the Core Team This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Question about quantile fuzz and GPL license
> GILLIBERT, Andre
> on Tue, 14 Sep 2021 16:13:05 + writes:
> On 9/14/21 9:22 AM, Abel AOUN wrote:
>> However I don't get why epsilon is multiplied by 4 instead of simply
using epsilon.
>> Is there someone who can explain this 4 ?
> .Machine$double.eps is the "precision" of floating point values for
values close to 1.0 (between 0.5 and 2.0).
> Using fuzz = .Machine$double.eps would have no effect if nppm is greater
than or equal to 2.
> Using fuzz = 4 * .Machine$double.eps can fix rounding errors for nppm <
8; for greater nppm, it has no effect.
> Indeed:
> 2 + .Machine$double.eps == 2
> 8+ 4*.Machine$double.eps == 8
> Since nppm is approximatively equal to the quantile multiplied by the
sample size, it can be much greater than 2 or 8.
hmm: not "quantile":
it is approximatively equal to the *'prob'* multiplied by the sample size
{the quantiles themselves can be on any scale anyway, but they
don't matter yet fortunately in these parts of the calculations}
but you're right in the main point that they are
approx. proportional to n.
> Maybe the rounding errors are only problematic for small nppm; or only
that case is taken in account.
> Moreover, if rounding errors are cumulative, they can be much greater
than the precision of the floating point value. I do not know how this constant
was chosen and what the use-cases were.
I vaguely remember I've been wondering about this also (back at the time).
Experiential wisdom would tell us to take such fuzz values as
*relative* to the magnitude of the values they are added to,
here 'nppm' (which is always >= 0, hence no need for abs(.) as usually).
So, instead of
j <- floor(nppm + fuzz)
h <- nppm - j
if(any(sml <- abs(h) < fuzz, na.rm = TRUE)) h[sml] <- 0
it would be (something like)
j <- floor(nppm*(1 + fuzz))
h <- nppm - j
if(any(sml <- abs(h) < fuzz*nppm, na.rm = TRUE)) h[sml] <- 0
or rather we would define fuzz as
nppm * (k * .Machine$double.eps)
for a small k.
- - -
OTOH, type=7 is the default, and I guess used in 99.9% of
all uses of quantile, *and* does never use any fuzz
Martin
> --
> Sincerely
> Andre GILLIBERT
> [[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[R-pkg-devel] CRAN check error only for r-release-macos-arm64
Hi, My statgenHTP package is failing the CRAN check for r-release-macos-arm64 only, see https://cran.r-project.org/web/checks/check_results_statgenHTP.html The issue should be easy to fix, the tested function is just a few lines of code. However I have no idea how to replicate the problem. I tried the 3 macOS platforms available on rhub, but the tests pass there without a problem. I don't have access to a mac myself. Could anyone point me in the right direction of how I could replicate my problem? Thanks, Bart-Jan van Rossum __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Solaris segfaults
Hi Ben,
According to https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
CRAN's Solaris is also 32 bit.
But maybe I am missing something?
You can download a Solaris VM (for Virtualbox or VMware) from
https://files.r-hub.io/solaris/
It has both 32 bit and 64 bit R (with gcc) and ODS R as well. You can
update R on it like this:
https://github.com/r-hub/solarischeck/tree/master/packer#updating-r
Best,
Gabor
On Wed, Sep 15, 2021 at 1:51 AM Ben Bolker wrote:
>
>I may have asked something like this before, but ...
>
> The glmmTMB package is currently segfaulting (on the very first example)
> on its CRAN Solaris checks
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/glmmTMB-00check.html
>
>
> > ## Comparing variance-covariance matrix with manual computation
> > data("sleepstudy",package="lme4")
> > fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)
>
> *** caught segfault ***
> address 4539ec45, cause 'memory not mapped'
> ---
>
>
>
> We have to submit a new version to CRAN soon; we will most likely beg
> the CRAN maintainers' indulgence for having it fail on Solaris, but it
> would be nice to fix it if we can.
>
> The CRAN Solaris platform is 64-bit x86_64, using gcc/g++ because
> the package uses Rcpp.
>
>The package builds/checks fine on the r-hub `solaris-x86-patched`
> platform, which is identical as far as I can tell **except** 32-bit
> rather than 64-bit.
>
>Short of installing 64-bit Solaris in a VM (which I have not done yet
> because of random compatibility/command-line bullshittery that put me
> off), does anyone have any wisdom to share for diagnosing and/or
> guessing what the problem is?
>
>Here are some links to similar errors, none of them seem terribly
> useful/relevant.
>
> https://github.com/gagolews/stringi/issues/94
> https://mran.microsoft.com/snapshot/2017-07-05/web/checks/check_results_vcfR.html
> https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/prt-00check.html
>
>glmmTMB is built on a pretty big stack (Eigen, Rcpp, RcppEigen,
> CppAD, TMB) - the problem could be somewhere in there (the TMB package
> runs no tests and very few examples on CRAN, so there could be problems
> there that only get flagged when we try glmmTMB examples).
>
> More discussion at
> https://github.com/glmmTMB/glmmTMB/issues/732 (with some red herrings)
> if anyone is interested.
>
>cheers
> Ben Bolker
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
