Re: [Rd] [External] Re: zapsmall(x) for scalar x
Le 18/12/2023 à 11:24, Martin Maechler a écrit :
Serguei Sokol via R-devel
on Mon, 18 Dec 2023 10:29:02 +0100 writes:
> Le 17/12/2023 à 18:26, Barry Rowlingson a écrit :
>> I think what's been missed is that zapsmall works relative to the
absolute
>> largest value in the vector. Hence if there's only one
>> item in the vector, it is the largest, so its not zapped. The function's
>> raison d'etre isn't to replace absolutely small values,
>> but small values relative to the largest. Hence a vector of similar tiny
>> values doesn't get zapped.
>>
>> Maybe the line in the docs:
>>
>> " (compared with the maximal absolute value)"
>>
>> needs to read:
>>
>> " (compared with the maximal absolute value in the vector)"
> I agree that this change in the doc would clarify the situation but
> would not resolve proposed corner cases.
> I think that an additional argument 'mx' (absolute max value of
> reference) would do. Consider:
> zapsmall2 <-
> function (x, digits = getOption("digits"), mx=max(abs(x), na.rm=TRUE))
> {
> if (length(digits) == 0L)
> stop("invalid 'digits'")
> if (all(ina <- is.na(x)))
> return(x)
> round(x, digits = if (mx > 0) max(0L, digits -
> as.numeric(log10(mx))) else digits)
> }
> then zapsmall2() without explicit 'mx' behaves identically to actual
> zapsmall() and for a scalar or a vector of identical value, user can
> manually fix the scale of what should be considered as small:
>> zapsmall2(y)
> [1] 2.220446e-16
>> zapsmall2(y, mx=1)
> [1] 0
>> zapsmall2(c(y, y), mx=1)
> [1] 0 0
>> zapsmall2(c(y, NA))
> [1] 2.220446e-16 NA
>> zapsmall2(c(y, NA), mx=1)
> [1] 0 NA
> Obviously, the name 'zapsmall2' was chosen just for this explanation.
> The original name 'zapsmall' could be reused as a full backward
> compatibility is preserved.
> Best,
> Serguei.
Thank you, Serguei, Duncan, Barry et al.
Generally :
Yes, zapsmall was meant and is used for zapping *relatively*
small numbers. In the other cases, directly round()ing is
what you should use.
Specifically to Serguei's proposal of allowing the "max" value
to be user specified (in which case it is not really a true
max() anymore):
I've spent quite a a few hours on this problem in May 2022, to
make it even more flexible, e.g. allowing to use a 99%
percentile instead of the max(), or allowing to exclude +Inf
from the "mx"; but -- compared to your zapsmall2() --
to allow reproducible automatic choice :
zapsmall <- function(x, digits = getOption("digits"),
mFUN = function(x, ina) max(abs(x[!ina])),
min.d = 0L)
{
if (length(digits) == 0L)
stop("invalid 'digits'")
if (all(ina <- is.na(x)))
return(x)
mx <- mFUN(x, ina)
round(x, digits = if(mx > 0) max(min.d, digits - as.numeric(log10(mx)))
else digits)
}
with optional 'min.d' as I had (vaguely remember to have) found
at the time that the '0' is also not always "the only correct" choice.
Do you have a case or two where min.d could be useful?
Serguei.
Somehow I never got to propose/discuss the above,
but it seems a good time to do so now.
Martin
>> barry
>>
>>
>> On Sun, Dec 17, 2023 at 2:17 PM Duncan Murdoch
>> wrote:
>>
>>> This email originated outside the University. Check before clicking
links
>>> or attachments.
>>>
>>> I'm really confused. Steve's example wasn't a scalar x, it was a
>>> vector. Your zapsmall() proposal wouldn't zap it to zero, and I don't
>>> see why summary() would if it was using your proposal.
>>>
>>> Duncan Murdoch
>>>
>>> On 17/12/2023 8:43 a.m., Gregory R. Warnes wrote:
>>>> Isn’t that the correct outcome? The user can change the number of
>>> digits if they want to see small values…
>>>>
>>>> --
>>>> Change your thoughts and you change the world.
>>>> --Dr. Norman Vincent Peale
>>>>
>>>>> On Dec 17, 2023, at 12:11 AM, Steve Martin
>>> wrote:
>>>>> Zapping a vector of small numbers to zero would cause problems when
>>>>> printing the results of summary(). For example, if
>&g
Re: [Rd] [External] Re: zapsmall(x) for scalar x
Le 17/12/2023 à 18:26, Barry Rowlingson a écrit :
I think what's been missed is that zapsmall works relative to the absolute
largest value in the vector. Hence if there's only one
item in the vector, it is the largest, so its not zapped. The function's
raison d'etre isn't to replace absolutely small values,
but small values relative to the largest. Hence a vector of similar tiny
values doesn't get zapped.
Maybe the line in the docs:
" (compared with the maximal absolute value)"
needs to read:
" (compared with the maximal absolute value in the vector)"
I agree that this change in the doc would clarify the situation but
would not resolve proposed corner cases.
I think that an additional argument 'mx' (absolute max value of
reference) would do. Consider:
zapsmall2 <-
function (x, digits = getOption("digits"), mx=max(abs(x), na.rm=TRUE))
{
if (length(digits) == 0L)
stop("invalid 'digits'")
if (all(ina <- is.na(x)))
return(x)
round(x, digits = if (mx > 0) max(0L, digits -
as.numeric(log10(mx))) else digits)
}
then zapsmall2() without explicit 'mx' behaves identically to actual
zapsmall() and for a scalar or a vector of identical value, user can
manually fix the scale of what should be considered as small:
> zapsmall2(y)
[1] 2.220446e-16
> zapsmall2(y, mx=1)
[1] 0
> zapsmall2(c(y, y), mx=1)
[1] 0 0
> zapsmall2(c(y, NA))
[1] 2.220446e-16 NA
> zapsmall2(c(y, NA), mx=1)
[1] 0 NA
Obviously, the name 'zapsmall2' was chosen just for this explanation.
The original name 'zapsmall' could be reused as a full backward
compatibility is preserved.
Best,
Serguei.
Barry
On Sun, Dec 17, 2023 at 2:17 PM Duncan Murdoch
wrote:
This email originated outside the University. Check before clicking links
or attachments.
I'm really confused. Steve's example wasn't a scalar x, it was a
vector. Your zapsmall() proposal wouldn't zap it to zero, and I don't
see why summary() would if it was using your proposal.
Duncan Murdoch
On 17/12/2023 8:43 a.m., Gregory R. Warnes wrote:
Isn’t that the correct outcome? The user can change the number of
digits if they want to see small values…
--
Change your thoughts and you change the world.
--Dr. Norman Vincent Peale
On Dec 17, 2023, at 12:11 AM, Steve Martin
wrote:
Zapping a vector of small numbers to zero would cause problems when
printing the results of summary(). For example, if
zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then
print(summary(2.220446e-16), digits = 7) would print
Min. 1st Qu. MedianMean 3rd Qu.Max.
0 00 0 0 0
The same problem can also appear when printing the results of
summary.glm() with show.residuals = TRUE if there's little dispersion
in the residuals.
Steve
On Sat, 16 Dec 2023 at 17:34, Gregory Warnes wrote:
I was quite suprised to discover that applying `zapsmall` to a scalar
value has no apparent effect. For example:
y <- 2.220446e-16
zapsmall(y,)
[1] 2.2204e-16
I was expecting zapsmall(x)` to act like
round(y, digits=getOption('digits'))
[1] 0
Looking at the current source code, indicates that `zapsmall` is
expecting a vector:
zapsmall <-
function (x, digits = getOption("digits"))
{
if (length(digits) == 0L)
stop("invalid 'digits'")
if (all(ina <- is.na(x)))
return(x)
mx <- max(abs(x[!ina]))
round(x, digits = if (mx > 0) max(0L, digits -
as.numeric(log10(mx))) else digits)
}
If `x` is a non-zero scalar, zapsmall will never perform rounding.
The man page simply states:
zapsmall determines a digits argument dr for calling round(x, digits =
dr) such that values close to zero (compared with the maximal absolute
value) are ‘zapped’, i.e., replaced by 0.
and doesn’t provide any details about how ‘close to zero’ is defined.
Perhaps handling the special when `x` is a scalar (or only contains a
single non-NA value) would make sense:
zapsmall <-
function (x, digits = getOption("digits"))
{
if (length(digits) == 0L)
stop("invalid 'digits'")
if (all(ina <- is.na(x)))
return(x)
mx <- max(abs(x[!ina]))
round(x, digits = if (mx > 0 && (length(x)-sum(ina))>1 ) max(0L,
digits - as.numeric(log10(mx))) else digits)
}
Yielding:
y <- 2.220446e-16
zapsmall(y)
[1] 0
Another edge case would be when all of the non-na values are the same:
y <- 2.220446e-16
zapsmall(c(y,y))
[1] 2.220446e-16 2.220446e-16
Thoughts?
Gregory R. Warnes, Ph.D.
g...@warnes.net
Eternity is a long time, take a friend!
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org
Re: [Rd] Strange behaviour of do.call()
Le 19/09/2023 à 16:44, Duncan Murdoch a écrit :
The knitr::kable() function does some internal setup, including
determining the target format, and then calls an internal function using
do.call(paste("kable", format, sep = "_"), list(x = x,
caption = caption, escape = escape, ...))
I was interested in setting the `vlign` argument to
knitr:::kable_latex, using this code:
knitr::kable(head(mtcars), format="latex", align = "c", vlign="")
If I debug knitr::kable, I can see that `vlign = ""` is part of
list(...). However, if I debug knitr:::kable_latex, I get weird results:
> debug(knitr:::kable_latex)
> knitr::kable(head(mtcars), format="latex", align = "c", vlign="")
If I do this in my R v4.3.1 on linux, I get:
> debug(knitr:::kable_latex)
> knitr::kable(head(mtcars), format="latex", align = "c", vlign="")
Error in kable_latex(x = c("Mazda RX4", "Mazda RX4 Wag", "Datsun 710", :
unused argument (vlign = "")
By looking at args(knitr:::kable_latex), I see 2 similar arguments
'valign' and 'vline' but no 'vlign'.
Can it be just a typo in your code?
debugging in: kable_latex(x = c("Mazda RX4", "Mazda RX4 Wag", "Datsun
710",
"Hornet 4 Drive", "Hornet Sportabout", "Valiant", "21.0", "21.0",
"22.8", "21.4", "18.7", "18.1", "6", "6", "4", "6", "8", "6",
"160", "160", "108", "258", "360", "225", "110", "110", "93",
"110", "175", "105", "3.90", "3.90", "3.85", "3.08", "3.15",
"2.76", "2.620", "2.875", "2.320", "3.215", "3.440", "3.460",
"16.46", "17.02", "18.61", "19.44", "17.02", "20.22", "0", "0",
"1", "1", "0", "1", "1", "1", "1", "0", "0", "0", "4", "4", "4",
"3", "3", "3", "4", "4", "1", "1", "2", "1"), caption = NULL,
escape = TRUE, vlign = "")
debug: {
[rest of function display omitted]
I see here that vlign = "" is being shown as an argument. However,
when I print vlign, sometimes I get "object not found", and somethings
I get
Browse[2]> vline
debug: [1] "|"
Here again, 'vline' is used on purpose instead of 'vlign'?
Best,
Serguei.
(which is what the default value would be). In the latter case, I
also see
Browse[2]> list(...)
$vlign
[1] ""
i.e. vlign remains part of the ... list, it wasn't bound to the
argument named vlign.
I can't spot anything particularly strange in the way knitr is
handling this; can anyone else? My sessionInfo() is below.
Duncan Murdoch
> sessionInfo()
R version 4.3.1 (2023-06-16)
Platform: x86_64-apple-darwin20 (64-bit)
Running under: macOS Monterey 12.6.9
Matrix products: default
BLAS:
/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRblas.0.dylib
LAPACK:
/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib;
LAPACK version 3.11.0
locale:
[1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
time zone: America/Toronto
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.3.1 tools_4.3.1 knitr_1.44 xfun_0.40
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Serguei Sokol
Ingenieur de recherche INRAE
Cellule Mathématiques
TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504
135 Avenue de Rangueil
31077 Toulouse Cedex 04
tel: +33 5 61 55 98 49
email: so...@insa-toulouse.fr
https://www.toulouse-biotechnology-institute.fr/en/plateformes-plateaux/cellule-mathematiques/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dir.exists returns FALSE on Symlink directory
Le 26/06/2023 à 17:17, Serguei Sokol a écrit :
Le 26/06/2023 à 16:26, Dipterix Wang a écrit :
I hope I'm not asking a stupid question...
Many think that there is no such thing as "stupid question". However,
this one looks more appropriate for r-help list, does not it?
If I symlink a directory, is symlink considered as directory in R?
If so, why `dir.exists` returns FALSE on directory?
I understand symlink is essentially a file, but functionally a
symlink to directory is no different to the directory itself, but a
directory is also essentially a file.
Is there any way that allow me to check if a symlink is linked to
directory in base R, like `dir.exists(..., symlink_ok = TRUE)`?
What about :
dir.exists(Sys.readlink("your_link"))
Or even better:
file_test("-d", "your_real_dir_or_simlink_to_dir")
which returns TRUE for both a real dir and a simlink to a dir.
Best,
Serguei.
?
Best,
Serguei.
Thanks,
Dipterix
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Serguei Sokol
Ingenieur de recherche INRAE
Cellule Mathématiques
TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504
135 Avenue de Rangueil
31077 Toulouse Cedex 04
tel: +33 5 61 55 98 49
email: so...@insa-toulouse.fr
https://www.toulouse-biotechnology-institute.fr/en/plateformes-plateaux/cellule-mathematiques/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dir.exists returns FALSE on Symlink directory
Le 26/06/2023 à 16:26, Dipterix Wang a écrit :
I hope I'm not asking a stupid question...
Many think that there is no such thing as "stupid question". However,
this one looks more appropriate for r-help list, does not it?
If I symlink a directory, is symlink considered as directory in R? If so, why
`dir.exists` returns FALSE on directory?
I understand symlink is essentially a file, but functionally a symlink to
directory is no different to the directory itself, but a directory is also
essentially a file.
Is there any way that allow me to check if a symlink is linked to directory in
base R, like `dir.exists(..., symlink_ok = TRUE)`?
What about :
dir.exists(Sys.readlink("your_link"))
?
Best,
Serguei.
Thanks,
Dipterix
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Serguei Sokol
Ingenieur de recherche INRAE
Cellule Mathématiques
TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504
135 Avenue de Rangueil
31077 Toulouse Cedex 04
tel: +33 5 61 55 98 49
email: so...@insa-toulouse.fr
https://www.toulouse-biotechnology-institute.fr/en/plateformes-plateaux/cellule-mathematiques/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] codetools wrongly complains about lazy evaluation in S4 methods
Le 03/06/2023 à 17:50, Mikael Jagan a écrit :
In a package, I define a method for not-yet-generic function 'qr.X'
like so:
> setOldClass("qr")
> setMethod("qr.X", signature(qr = "qr"), function(qr, complete,
ncol) NULL)
The formals of the newly generic 'qr.X' are inherited from the
non-generic
function in the base namespace. Notably, the inherited default value of
formal argument 'ncol' relies on lazy evaluation:
> formals(qr.X)[["ncol"]]
if (complete) nrow(R) else min(dim(R))
where 'R' must be defined in the body of any method that might
evaluate 'ncol'.
To my surprise, tools:::.check_code_usage_in_package() complains about
the
undefined symbol:
qr.X: no visible binding for global variable 'R'
qr.X,qr: no visible binding for global variable 'R'
Undefined global functions or variables:
R
I think this issue is similar to the complaints about non defined
variables in expressions involving non standard evaluation, e.g. column
names in a data frame which are used as unquoted symbols. One of
workarounds is simply to declare them somewhere in your code. In your
case, it could be something as simple as:
R=NULL
Best,
Serguei.
I claim that it should _not_ complain, given that lazy evaluation is a
really
a feature of the language _and_ given that it already does not
complain about
the formals of functions that are not S4 methods.
Having said that, it is not obvious to me what in codetools would need
to change
here. Any ideas?
I've attached a script that creates and installs a test package and
reproduces
the check output by calling tools:::.check_code_usage_in_package().
Hope it
gets through.
Mikael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] save.image Non-responsive to Interrupt
Le 03/05/2023 à 01:25, Henrik Bengtsson a écrit :
Along the lines of calling R_CheckUserInterrupt() only onces in a while:
OTOH, in the past we have had to *disable* R_CheckUserInterrupt()
in parts of R's code because it was too expensive,
{see current src/main/{seq.c,unique.c} for a series of commented-out
R_CheckUserInterrupt() for such speed-loss reasons}
First, here are links to these two files viewable online:
* https://github.com/wch/r-source/blob/trunk/src/main/seq.c
* https://github.com/wch/r-source/blob/trunk/src/main/unique.c
When not commented out, R_CheckUserInterrupt() would have been called
every 1,000,000 times per:
/* interval at which to check interrupts */
#define NINTERRUPT 100
and
if ((i+1) % NINTERRUPT == 0) R_CheckUserInterrupt()
in each iteration. That '(i+1) % NINTERRUPT == 0' expression can be
quite expensive too.
I vaguely remember a hack that was mentioned on this list as close to
0-cost. It looked something like:
iint = NINTERRUPT;
for (...) {
if (--iint == 0) {
R_CheckUserInterrupt();
iint = NINTERRUPT;
}
}
Best,
Serguei.
However, if we change the code to use NINTERRUPT
= 2^k where k = {1, 2, ...}, say
#define NINTERRUPT 1048576
the compiler would optimize the condition to use "the modulo of powers
of 2 can alternatively be expressed as a bitwise AND operation"
(Thomas Lumley, 2015-06-15). The speedup is quite impressive, cf.
Re: [Rd] xyTable(x,y) versus table(x,y) with NAs
Le 25/04/2023 à 17:39, Bill Dunlap a écrit : x <- c(1, 1, 2, 2, 2, 3) y <- c(1, 2, 1, 3, NA, 3) str(xyTable(x,y)) List of 3 $ x : num [1:6] 1 1 2 2 NA 3 $ y : num [1:6] 1 2 1 3 NA 3 $ number: int [1:6] 1 1 1 NA NA 1 How many (2,3)s do we have? At least one, the third entry, but the fourth entry, (2,NA), is possibly a (2,3) so we don't know and make the count NA. I suspect this is not the intended logic, but a byproduct of finding value changes in a sorted vector with the idiom x[-1]!=x[-length(x). Also the following does follow that logic: x <- c(1, 1, 2, 2, 5, 6) y <- c(2, 2, 2, 4, NA, 3) str(xyTable(x,y)) List of 3 $ x : num [1:5] 1 2 2 5 6 $ y : num [1:5] 2 2 4 NA 3 $ number: int [1:5] 2 1 1 1 1 Not really. If we take x <- c(1, 1, 2, 2, 5, 6, 5, 5) y <- c(2, 2, 2, 4, NA, 3, 3, 4) we get str(xyTable(x,y)) List of 3 $ x : num [1:7] 1 2 2 5 5 NA 6 $ y : num [1:7] 2 2 4 3 4 NA 3 $ number: int [1:7] 2 1 1 1 NA NA 1 How many (5, 3) we have? At least 1 but (5, NA) is possibly (5,3) so we should have NA but we have 1. How many (5, 4) we have? At least 1 but (5, NA) is possibly (5,4) and we do get NA. So restored logic is not consistent. Without talking about a pair (NA, NA) appeared and not producing (5, NA) pair. Best, Serguei. table() does not use this logic, as one NA in a vector would make all the counts NA. Should xyTable have a way to handle NAs the way table() does? -Bill On Tue, Apr 25, 2023 at 1:26 AM Viechtbauer, Wolfgang (NP) < wolfgang.viechtba...@maastrichtuniversity.nl> wrote: Hi all, Posted this many years ago ( https://stat.ethz.ch/pipermail/r-devel/2017-December/075224.html), but either this slipped under the radar or my feeble mind is unable to understand what xyTable() is doing here and nobody bothered to correct me. I now stumbled again across this issue. x <- c(1, 1, 2, 2, 2, 3) y <- c(1, 2, 1, 3, NA, 3) table(x, y, useNA="always") xyTable(x, y) Why does xyTable() report that there are NA instances of (2,3)? I could understand the logic that the NA could be anything, including a 3, so the $number value for (2,3) is therefore unknown, but then the same should apply so (2,1), but here $number is 1, so the logic is then inconsistent. I stared at the xyTable code for a while and I suspect this is coming from order() using na.last=TRUE by default, but in any case, to me the behavior above is surprising. Best, Wolfgang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xyTable(x,y) versus table(x,y) with NAs
I correct myself. Obviously, the line
first[is.na(first) | isFALSE(first)] <- FALSE
should read
first[is.na(first)] <- FALSE
Serguei.
Le 25/04/2023 à 11:30, Serguei Sokol a écrit :
Le 25/04/2023 à 10:24, Viechtbauer, Wolfgang (NP) a écrit :
Hi all,
Posted this many years ago
(https://stat.ethz.ch/pipermail/r-devel/2017-December/075224.html),
but either this slipped under the radar or my feeble mind is unable
to understand what xyTable() is doing here and nobody bothered to
correct me. I now stumbled again across this issue.
x <- c(1, 1, 2, 2, 2, 3)
y <- c(1, 2, 1, 3, NA, 3)
table(x, y, useNA="always")
xyTable(x, y)
Why does xyTable() report that there are NA instances of (2,3)? I
could understand the logic that the NA could be anything, including a
3, so the $number value for (2,3) is therefore unknown, but then the
same should apply so (2,1), but here $number is 1, so the logic is
then inconsistent.
I stared at the xyTable code for a while and I suspect this is coming
from order() using na.last=TRUE by default, but in any case, to me
the behavior above is surprising.
Not really. The variable 'first' in xyTable() is supposed to detect
positions of first values in repeated pair sequences. Then it is used
to retained only their indexes in a vector of type 1:n. Finally, by
taking diff(), a number of repeated pairs is obtained. However, as
'first' will contain one NA for your example, the diff() call will
produce two NAs by taking the difference with precedent and following
number. Hence, the result.
Here is a slightly modified code ox xyTable to handle NA too.
xyTableNA <- function (x, y = NULL, digits)
{
x <- xy.coords(x, y, setLab = FALSE)
y <- signif(x$y, digits = digits)
x <- signif(x$x, digits = digits)
n <- length(x)
number <- if (n > 0) {
orderxy <- order(x, y)
x <- x[orderxy]
y <- y[orderxy]
first <- c(TRUE, (x[-1L] != x[-n]) | (y[-1L] != y[-n]))
firstNA <- c(TRUE, xor(is.na(x[-1L]), is.na(x[-n])) |
xor(is.na(y[-1L]), is.na(y[-n])))
first[firstNA] <- TRUE
first[is.na(first) | isFALSE(first)] <- FALSE
x <- x[first]
y <- y[first]
diff(c((1L:n)[first], n + 1L))
}
else integer()
list(x = x, y = y, number = number)
}
Best,
Serguei.
Best,
Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Serguei Sokol
Ingenieur de recherche INRAE
Cellule Mathématiques
TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504
135 Avenue de Rangueil
31077 Toulouse Cedex 04
tel: +33 5 61 55 98 49
email: so...@insa-toulouse.fr
http://www.toulouse-biotechnology-institute.fr/en/technology_platforms/mathematics-cell.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xyTable(x,y) versus table(x,y) with NAs
Le 25/04/2023 à 10:24, Viechtbauer, Wolfgang (NP) a écrit :
Hi all,
Posted this many years ago
(https://stat.ethz.ch/pipermail/r-devel/2017-December/075224.html), but either
this slipped under the radar or my feeble mind is unable to understand what
xyTable() is doing here and nobody bothered to correct me. I now stumbled again
across this issue.
x <- c(1, 1, 2, 2, 2, 3)
y <- c(1, 2, 1, 3, NA, 3)
table(x, y, useNA="always")
xyTable(x, y)
Why does xyTable() report that there are NA instances of (2,3)? I could
understand the logic that the NA could be anything, including a 3, so the
$number value for (2,3) is therefore unknown, but then the same should apply so
(2,1), but here $number is 1, so the logic is then inconsistent.
I stared at the xyTable code for a while and I suspect this is coming from
order() using na.last=TRUE by default, but in any case, to me the behavior
above is surprising.
Not really. The variable 'first' in xyTable() is supposed to detect
positions of first values in repeated pair sequences. Then it is used to
retained only their indexes in a vector of type 1:n. Finally, by taking
diff(), a number of repeated pairs is obtained. However, as 'first' will
contain one NA for your example, the diff() call will produce two NAs
by taking the difference with precedent and following number. Hence, the
result.
Here is a slightly modified code ox xyTable to handle NA too.
xyTableNA <- function (x, y = NULL, digits)
{
x <- xy.coords(x, y, setLab = FALSE)
y <- signif(x$y, digits = digits)
x <- signif(x$x, digits = digits)
n <- length(x)
number <- if (n > 0) {
orderxy <- order(x, y)
x <- x[orderxy]
y <- y[orderxy]
first <- c(TRUE, (x[-1L] != x[-n]) | (y[-1L] != y[-n]))
firstNA <- c(TRUE, xor(is.na(x[-1L]), is.na(x[-n])) |
xor(is.na(y[-1L]), is.na(y[-n])))
first[firstNA] <- TRUE
first[is.na(first) | isFALSE(first)] <- FALSE
x <- x[first]
y <- y[first]
diff(c((1L:n)[first], n + 1L))
}
else integer()
list(x = x, y = y, number = number)
}
Best,
Serguei.
Best,
Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Augment base::replace(x, list, value) to allow list= to be a predicate?
Le 04/03/2023 à 01:21, Pavel Krivitsky a écrit :
Dear All,
Currently, list= in base::replace(x, list, value) has to be an index
vector. For me, at least, the most common use case is for list= to be
some simple property of elements of x, e.g.,
x <- c(1,2,NA,3)
replace(x, is.na(x), 0)
Particularly when using R pipes, which don't allow multiple
substitutions,
Right, but anonymous function syntax can palliate to this:
x |> (\(x) replace(x, is.na(x), 0))()
it would simplify many of such cases if list= could be a
function that returns an index, e.g.,
replace <- function (x, list, values, ...) {
# Here, list() refers to the argument, not the built-in.
if(is.function(list)) list <- list(x, ...)
x[list] <- values
x
}
Before modifying the base of R, we should examine existing possibilities
to achieve the same goal.
In this particular case and if the previous solution (anonymous
function) is not satisfactory a thin one-line wrapper can make the job:
freplace <- function (x, list, values, ...) replace(x,
if(is.function(list)) list <- list(x, ...) else list, values)
Then, the following is possible:
c(1,2,NA,3) |> replace(is.na, 0)
this becomes
c(1,2,NA,3) |> freplace(is.na, 0)
and looks quite acceptable for me.
Best,
Serguei.
Any thoughts?
Pavel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Serguei Sokol
Ingenieur de recherche INRAE
Cellule Mathématiques
TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504
135 Avenue de Rangueil
31077 Toulouse Cedex 04
tel: +33 5 61 55 98 49
email: so...@insa-toulouse.fr
http://www.toulouse-biotechnology-institute.fr/en/technology_platforms/mathematics-cell.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] uniroot violates bounds?
Le 18/02/2023 à 21:44, J C Nash a écrit :
I wrote first cut at unirootR for Martin M and he revised and put in
Rmpfr.
The following extends Ben's example, but adds the unirootR with trace
output.
c1 <- 4469.822
c2 <- 572.3413
f <- function(x) { c1/x - c2/(1-x) }; uniroot(f, c(1e-6, 1))
uniroot(f, c(1e-6, 1))
library(Rmpfr)
unirootR(f, c(1e-6, 1), extendInt="no", trace=1)
This gives more detail on the iterations, and it looks like the Inf is
the
issue. But certainly we could do more to avoid "gotchas" like this. If
someone is interested in some back and forth, I'd be happy to give it a
try, but I think progress would be better with more than one contributor.
For me, the following fix makes the job :
--- nlm.R.old 2018-09-25 10:44:49.0 +0200
+++ nlm.R 2023-02-20 10:46:39.893542531 +0100
@@ -143,14 +143,14 @@
if(check.conv) {
val <- tryCatch(.External2(C_zeroin2, function(arg) f(arg, ...),
- lower, upper, f.lower, f.upper,
+ lower, upper, f.low., f.upp.,
tol, as.integer(maxiter)),
warning = function(w)w)
if(inherits(val, "warning"))
stop("convergence problem in zero finding: ",
conditionMessage(val))
} else {
val <- .External2(C_zeroin2, function(arg) f(arg, ...),
- lower, upper, f.lower, f.upper,
+ lower, upper, f.low., f.upp.,
tol, as.integer(maxiter))
}
iter <- as.integer(val[2L])
Best,
Serguei.
Best,
John Nash
On 2023-02-18 12:28, Ben Bolker wrote:
c1 <- 4469.822
c2 <- 572.3413
f <- function(x) { c1/x - c2/(1-x) }; uniroot(f, c(1e-6, 1))
uniroot(f, c(1e-6, 1))
provides a root at -6.00e-05, which is outside of the specified
bounds. The default value of the "extendInt" argument to uniroot()
is "no", as far as I can see ...
$root
[1] -6.003516e-05
$f.root
[1] -74453981
$iter
[1] 1
$init.it
[1] NA
$estim.prec
[1] 6.103516e-05
I suspect this fails because f(1) (value at the upper bound) is
infinite, although setting interval to c(0.01, 1) does work/give a
sensible answer ... (works for a lower bound of 1e-4, fails for 1e-5
...)
Setting the upper bound < 1 appears to avoid the problem.
For what it's worth, the result has an "init.it" component, but the
only thing the documentation says about it is " component ‘init.it’
was added in R 3.1.0".
And, I think (?) that the 'trace' argument only produces any
output if the 'extendInt' option is enabled?
Inspired by
https://stackoverflow.com/questions/75494696/solving-a-system-of-non-linear-equations-with-only-one-unknown/75494955#75494955
cheers
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Combinations and Permutations
Le 13/01/2023 à 09:00, Dario Strbenac via R-devel a écrit :
Good day,
In utils, there is a function named combn. It would seem complementary for
utils to also offer permutations because of how closely mathematically related
they are to each other. Could permutations be added to save on a package
dependency if developing a package?
If you need a function returning a matrix with all permutations of a
vector x in its columns, a simple recursive one-liner can be sufficient,
no need for a whole package dependency for this:
perm=function(x) {n=length(x); f=factorial(n); if (n>1)
structure(vapply(seq_along(x), function(i) rbind(x[i], perm(x[-i])),
x[rep(1L, f)]), dim=c(n, f)) else x}
It works for all king of vectors (integer, numeric, character, ...):
perm(1:3)
perm(pi*1:3)
perm(letters[1:3])
Obviously, a particular attention should be brought to the size of x
(referred here as n) as the column number in the returned matrix growths
as n!.. E.g. 8!=40320. So growths the cpu time too.
Hoping it helps,
Serguei.
--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Looks like there is a kind of misunderstanding... Le 10/01/2023 à 17:27, RICHET Yann a écrit : > Thank you for your answer. > In facts, 10 threads are asked by armadillo for some LinAlg, which backs to > two threads as warned. But I cannot imagine this costs so much time just for > that... Excessive thread number is a problem per se. I did not say that it was responsible for excessive test time. It's up to you to configure armadillo to use no more then 2 threads when run on CRAN. May be, setting environment variable OPENBLAS_NUM_THREADS=2 could help. > > A deeper analysis of time spent seems to point that a large time was mainly > spent on testthat and Rcpp dependencies compilation... Normally, compilation time is not accounted in the quota of 15 min dedicated to tests. I would just focus on reducing this time, e.g. by running tests on smaller cases or skipping time-consuming tests conditionally when on CRAN. Serguei. > But other recent packages depending on these also are not spending so much > time. > > CRAN team, as I failed to reproduce the issue with rhub dockers, > - is there any reason that could explain that fedora-*-devel is so slow for > this package or compilation of Rcpp/testthat ? > - is our slapack a possible source of... anything ? > - are we the only package which embeds "standard armadillo" and tries to deal > with simple precision lapack issues on fedora ? > - is there any chance that I can get a deeper log of what happened ? > > Best regards, > > Yann > > -Message d'origine- > De : Serguei Sokol > Envoyé : mardi 10 janvier 2023 11:41 > À : RICHET Yann;R-devel@r-project.org > Cc : Pascal Havé > Objet : Re: [Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack > > Le 10/01/2023 à 11:37, Serguei Sokol a écrit : >> Le 10/01/2023 à 10:44, RICHET Yann a écrit : >>> Dear R-devel people, >>> >>> We are working to submit a package which is mainly a binding over a >>> C++ lib (https://github.com/libKriging) using armadillo. >>> It is _not_ a standard RcppArmadillo package, because we also had to >>> provide a python binding... so there is a huge layer of cmake & >>> scripting to make it work with a standard armadillo (but using same >>> version that RcppArmadillo). >>> It seems now working with almost all CRAN targets, but a problem >>> remains with fedora (clang & gcc) devel. >>> >>> Our issue is that the rhub docker is not well sync with the CRAN >>> fedora-clang-devel config: >>> - failing on CRAN (without clear reason): >>> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-c >>> lang/rlibkriging-00check.html >> I see 2 candidates for reasons of failing on CRAN: >> 1. test time is 30 min while 15 min are allowed; >> 2. your code try to get 30 threads > Oops, it was 10 threads not 30 but it does not change the nature of a > possible issue. > >> while CRAN limits them to 2; >> >> Try to make your tests shorter ( < 15 min) on 2 threads. May be it >> will help. >> >> Best, >> Serguei. >> >>> - passing on rhub: >>> https://builder.r-hub.io/status/rlibkriging_0.7-3.tar.gz-20f7dc756272 >>> 6497af7c678ab41f4dea >>> >>> So we cannot investigate and fix the problem. >>> >>> Note that we did quite strange things with the fedora platforms: >>> include explicitely slapack to provide simple precision for our >>> (vanilla) armadillo... >>> >>> Do you have any idea, or even known problem in mind, that could be >>> related to this ? >>> >>> Best regards, >>> >>> -- >>> Dr. Yann Richet >>> Institute for Radiological Protection and Nuclear Safety >>> (https://www.irsn.fr), >>> Department of Characterization of Natural Unexpected Events and >>> Sites Office : +33 1 58 35 88 84 >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Le 10/01/2023 à 11:37, Serguei Sokol a écrit : Le 10/01/2023 à 10:44, RICHET Yann a écrit : Dear R-devel people, We are working to submit a package which is mainly a binding over a C++ lib (https://github.com/libKriging) using armadillo. It is _not_ a standard RcppArmadillo package, because we also had to provide a python binding... so there is a huge layer of cmake & scripting to make it work with a standard armadillo (but using same version that RcppArmadillo). It seems now working with almost all CRAN targets, but a problem remains with fedora (clang & gcc) devel. Our issue is that the rhub docker is not well sync with the CRAN fedora-clang-devel config: - failing on CRAN (without clear reason): https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rlibkriging-00check.html I see 2 candidates for reasons of failing on CRAN: 1. test time is 30 min while 15 min are allowed; 2. your code try to get 30 threads Oops, it was 10 threads not 30 but it does not change the nature of a possible issue. while CRAN limits them to 2; Try to make your tests shorter ( < 15 min) on 2 threads. May be it will help. Best, Serguei. - passing on rhub: https://builder.r-hub.io/status/rlibkriging_0.7-3.tar.gz-20f7dc7562726497af7c678ab41f4dea So we cannot investigate and fix the problem. Note that we did quite strange things with the fedora platforms: include explicitely slapack to provide simple precision for our (vanilla) armadillo... Do you have any idea, or even known problem in mind, that could be related to this ? Best regards, -- Dr. Yann Richet Institute for Radiological Protection and Nuclear Safety (https://www.irsn.fr), Department of Characterization of Natural Unexpected Events and Sites Office : +33 1 58 35 88 84 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Serguei Sokol Ingenieur de recherche INRAE Cellule Mathématiques TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504 135 Avenue de Rangueil 31077 Toulouse Cedex 04 tel: +33 5 61 55 98 49 email: so...@insa-toulouse.fr http://www.toulouse-biotechnology-institute.fr/en/technology_platforms/mathematics-cell.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Le 10/01/2023 à 10:44, RICHET Yann a écrit : Dear R-devel people, We are working to submit a package which is mainly a binding over a C++ lib (https://github.com/libKriging) using armadillo. It is _not_ a standard RcppArmadillo package, because we also had to provide a python binding... so there is a huge layer of cmake & scripting to make it work with a standard armadillo (but using same version that RcppArmadillo). It seems now working with almost all CRAN targets, but a problem remains with fedora (clang & gcc) devel. Our issue is that the rhub docker is not well sync with the CRAN fedora-clang-devel config: - failing on CRAN (without clear reason): https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/rlibkriging-00check.html I see 2 candidates for reasons of failing on CRAN: 1. test time is 30 min while 15 min are allowed; 2. your code try to get 30 threads while CRAN limits them to 2; Try to make your tests shorter ( < 15 min) on 2 threads. May be it will help. Best, Serguei. - passing on rhub: https://builder.r-hub.io/status/rlibkriging_0.7-3.tar.gz-20f7dc7562726497af7c678ab41f4dea So we cannot investigate and fix the problem. Note that we did quite strange things with the fedora platforms: include explicitely slapack to provide simple precision for our (vanilla) armadillo... Do you have any idea, or even known problem in mind, that could be related to this ? Best regards, -- Dr. Yann Richet Institute for Radiological Protection and Nuclear Safety (https://www.irsn.fr), Department of Characterization of Natural Unexpected Events and Sites Office : +33 1 58 35 88 84 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Serguei Sokol Ingenieur de recherche INRAE Cellule Mathématiques TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504 135 Avenue de Rangueil 31077 Toulouse Cedex 04 tel: +33 5 61 55 98 49 email: so...@insa-toulouse.fr http://www.toulouse-biotechnology-institute.fr/en/technology_platforms/mathematics-cell.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] I do not want that R CMD build removes temp directory
Le 19/12/2022 à 10:52, Witold E Wolski a écrit : Dear Uwe, Unfortunately there isn't much of an output. This is all what I have: $ R CMD INSTALL --log prolfqua Warning: unknown option '--log' * installing to library 'C:/Users/witoldwolski/AppData/Local/R/win-library/4.2' * installing *source* package 'prolfqua' ... ** using staged installation ** R ** data ** inst ** byte-compile and prepare package for lazy loading ERROR: lazy loading failed for package 'prolfqua' * removing 'C:/Users/witoldwolski/AppData/Local/R/win-library/4.2/prolfqua' Also with --no-test-load option the install is failing : $ R CMD INSTALL --clean --no-test-load prolfqua * installing to library 'C:/Users/witoldwolski/AppData/Local/R/win-library/4.2' * installing *source* package 'prolfqua' ... ** using staged installation ** R ** data ** inst ** byte-compile and prepare package for lazy loading ERROR: lazy loading failed for package 'prolfqua' * removing 'C:/Users/witoldwolski/AppData/Local/R/win-library/4.2/prolfqua' And including "--no-clean-on-error" also does not help because the installation directory is empty. You don't show the full command you run. If you included also "--clean" as in previous command, may be it just does what is asked, i.e. clean the temp dir ? I don't know what prevails: "--clean" or "--no-clean-on-error" if put simultaneously. Best, Serguei. Tested the install, on macos M1, linux ARM64, linux x86, Windows 64, and it works everywhere except Parallels Windows 64 on ARM M1. R version 4.2.2 (2022-10-31 ucrt) -- "Innocent and Trusting" Copyright (C) 2022 The R Foundation for Statistical Computing Platform: x86_64-w64-mingw32/x64 (64-bit) best regards Witek On Fri, 16 Dec 2022 at 11:24, Uwe Ligges wrote: On 15.12.2022 21:47, Witold E Wolski wrote: Thank you Simon, It seems not to be related to the R package but rather to the OS, (just got the same error when installing the shiny R package from CRAN). I am on an M1 mac running Windows ARM in Parallels. Installed a x86_64-w64 R version. "** byte-compile and prepare package for lazy loading ERROR: lazy loading failed for package 'shiny' * removing 'C:/Users/witoldwolski/AppData/Local/R/win-library/4.2/shiny' Warning in install.packages :" Can we please have the full output? Best, Uwe Ligges On Thu, 15 Dec 2022 at 19:09, Simon Urbanek wrote: Yes: $ R CMD INSTALL --help | grep error --no-clean-on-error do not remove installed package on error But probably more commonly used way is to install the package from its unpacked directory as that avoids the use of temporary directories in the first place. In you case you can also use --no-test-load and the non-functional package will still be installed so you can inspect it. Cheers, Simon PS: please don't cross-post On Dec 16, 2022, at 7:01 AM, Witold E Wolski wrote: I am getting a package build error, and can not figure out the problem. The error is " ERROR: lazy loading failed for package 'prolfqua' * removing 'C:/Users/ " However since R CMD build removes the temp directory and does not give any other errors how can I find out what the build problem is? Is there a way to disable the temp directory removal? Best Regards Witek -- Witold Eryk Wolski __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Witold Eryk Wolski __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Serguei Sokol Ingenieur de recherche INRAE Cellule Mathématiques TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504 135 Avenue de Rangueil 31077 Toulouse Cedex 04 tel: +33 5 61 55 98 49 email: so...@insa-toulouse.fr http://www.toulouse-biotechnology-institute.fr/en/technology_platforms/mathematics-cell.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
