Re: [Rd] aggregate() naming -- bug or feature
Hello,
Not exactly an answer but here it goes.
If you use the formula interface the names will be retained. If fact,
this is even better than those names assigned by bar.
aggregate(Sepal.Length ~ Species, data = iris, FUN = foo)
# Species Sepal.Length
#1 setosa5.006
#2 versicolor5.936
#3 virginica6.588
Hope this helps,
Rui Barradas
On 3/23/2018 1:29 PM, Randall Pruim wrote:
In the examples below, the first loses the name attached by foo(), the second
retains names attached by bar(). Is this an intentional difference? I’d
prefer that the names be retained in both cases.
foo <- function(x) { c(mean = base::mean(x)) }
bar <- function(x) { c(mean = base::mean(x), sd = stats::sd(x))}
aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = foo)
#> Group.1 x
#> 1 setosa 5.006
#> 2 versicolor 5.936
#> 3 virginica 6.588
aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = bar)
#> Group.1x.mean x.sd
#> 1 setosa 5.006 0.3524897
#> 2 versicolor 5.936 0.5161711
#> 3 virginica 6.588 0.6358796
—rjp
[[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
[Rd] Bug in as.Date or strptime?
Hello,
This just came up in SO, sessionInfo() at the end.
https://stackoverflow.com/questions/50988018/seeking-explanation-for-as-date-function-in-r?noredirect=1#comment88971055_50988018
# example 1
# not even the month is right
as.Date(x = 1, format = '%j', origin= '2015-01-01')
#[1] "2018-07-21"
# example 2a
# nonsense output
as.Date(x = 1, origin= '2015-01-01')
#[1] "2015-01-02"
# example 2a
# nonsense output, see example 6 below
as.Date(x = 1, origin = as.Date('2015-01-01'))
#[1] "2015-01-02"
# example 3
# I know that the method as.Date.numeric doesn't have
# argument 'format' but does have the dots argument.
# The format is passed on to strptime so maybe the problem is there.
as.Date(x = 1, format = '%j', origin= as.Date('2015-01-01'))
#[1] "2015-01-02"
# example 4
# Wrong, documented.
# origin should be automatically coerced to class 'Date'
# This is documented to behave like example 6 below
as.Date(x = '1',format = '%j', origin= '2015-01-01')
#[1] "2018-01-01"
# example 5
# right, documented. x of class 'character' needs argument 'format'
as.Date(x = '1', origin= '2015-01-01')
#Error in charToDate(x) :
# string de caracteres não é um formato padrão não ambíguo
# example 6
# the safe way, the only one that outputs the right date
as.Date(x = '1', format = '%j', origin= as.Date('2015-01-01'))
#[1] "2018-01-01"
sessionInfo()
R version 3.4.4 (2018-03-15)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.4 LTS
Matrix products: default
BLAS: /usr/lib/libblas/libblas.so.3.6.0
LAPACK: /usr/lib/lapack/liblapack.so.3.6.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
loaded via a namespace (and not attached):
[1] compiler_3.4.4 tools_3.4.4yaml_2.1.19
Or maybe I am missing something.
Thanks in advance,
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Testing for vectors
Hello, Inline. Às 21:32 de 07-07-2018, Hadley Wickham escreveu: On Sat, Jul 7, 2018 at 1:50 PM, Gabe Becker wrote: Hadley, I was thinking primarily of completing the set of is.matrix() and is.array(), or generally, how do you say: is `x` a 1d dimensional thing? Can you clarify what you mean by dimensionality sense and specifically 1d here? What do we call a vector that is not an array? (or matrix) What do we call an object that acts 1-dimensional? (i.e. has length(dim()) %in% c(0, 1)) ? You can also have an n x 1 matrix, which technically has 2 dimensions but conceptually is equivalent to a 1d array and/or a vector. Yes. You can also have array that's n x 1 x 1. In which case it would be (length(dim(.)) - sum(dim(.) == 1)) %in% c(0, 1) Hope this helps, Rui Barradas Also, are you including lists in your conceptions of 1d vector here? I'm with Duncan here, in that i'm having trouble understanding exactly what you want to do without a bit more context. Isn't it standard terminology that a vector is the set of atomic vectors + list? Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Is this a bug in `[`?
Hello, Maybe I am not understanding how negative indexing works but 1) This is right. (1:10)[-1] #[1] 2 3 4 5 6 7 8 9 10 2) Are these right? They are at least surprising to me. (1:10)[-0] #integer(0) (1:10)[-seq_len(0)] #integer(0) It was the last example that made me ask, seq_len(0) whould avoid an if/else or something similar. Thanks in advance, Rui Barradas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is this a bug in `[`?
Às 15:51 de 04/08/2018, Iñaki Úcar escreveu: El sáb., 4 ago. 2018 a las 15:32, Rui Barradas () escribió: Hello, Maybe I am not understanding how negative indexing works but 1) This is right. (1:10)[-1] #[1] 2 3 4 5 6 7 8 9 10 2) Are these right? They are at least surprising to me. (1:10)[-0] #integer(0) (1:10)[-seq_len(0)] #integer(0) It was the last example that made me ask, seq_len(0) whould avoid an if/else or something similar. I think it's ok, because there is no negative zero integer, so -0 is 0. Ok, this makes sense, I should have thought about that. 1.0/-0L # Inf 1.0/-0.0 # - Inf And the same can be said for integer(0), which is the result of seq_len(0): there is no negative empty integer. I'm not completely convinced about this one, though. I would expect -seq_len(n) to remove the first n elements from the vector, therefore, when n == 0, it would remove none. And integer(0) is not the same as 0. (1:10)[-0] == (1:10)[0] == integer(0) # empty (1:10)[-seq_len(0)] == (1:10)[-integer(0)] And I have just reminded myself to run identical(-integer(0), integer(0)) It returns TRUE so my intuition is wrong, R is right. End of story. Thanks for the help, Rui Barradas Iñaki Thanks in advance, Rui Barradas __ 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] Is this a bug in `[`?
Thanks. This is exactly the doubt I had. Rui Barradas Às 05:26 de 05/08/2018, Kenny Bell escreveu: This should more clearly illustrate the issue: c(1, 2, 3, 4)[-seq_len(4)] #> numeric(0) c(1, 2, 3, 4)[-seq_len(3)] #> [1] 4 c(1, 2, 3, 4)[-seq_len(2)] #> [1] 3 4 c(1, 2, 3, 4)[-seq_len(1)] #> [1] 2 3 4 c(1, 2, 3, 4)[-seq_len(0)] #> numeric(0) Created on 2018-08-05 by the reprex package (v0.2.0.9000). On Sun, Aug 5, 2018 at 3:58 AM Rui Barradas <mailto:ruipbarra...@sapo.pt>> wrote: Às 15:51 de 04/08/2018, Iñaki Úcar escreveu: > El sáb., 4 ago. 2018 a las 15:32, Rui Barradas > (mailto:ruipbarra...@sapo.pt>>) escribió: >> >> Hello, >> >> Maybe I am not understanding how negative indexing works but >> >> 1) This is right. >> >> (1:10)[-1] >> #[1] 2 3 4 5 6 7 8 9 10 >> >> 2) Are these right? They are at least surprising to me. >> >> (1:10)[-0] >> #integer(0) >> >> (1:10)[-seq_len(0)] >> #integer(0) >> >> >> It was the last example that made me ask, seq_len(0) whould avoid an >> if/else or something similar. > > I think it's ok, because there is no negative zero integer, so -0 is 0. Ok, this makes sense, I should have thought about that. > > 1.0/-0L # Inf > 1.0/-0.0 # - Inf > > And the same can be said for integer(0), which is the result of > seq_len(0): there is no negative empty integer. I'm not completely convinced about this one, though. I would expect -seq_len(n) to remove the first n elements from the vector, therefore, when n == 0, it would remove none. And integer(0) is not the same as 0. (1:10)[-0] == (1:10)[0] == integer(0) # empty (1:10)[-seq_len(0)] == (1:10)[-integer(0)] And I have just reminded myself to run identical(-integer(0), integer(0)) It returns TRUE so my intuition is wrong, R is right. End of story. Thanks for the help, Rui Barradas > > Iñaki > >> >> >> Thanks in advance, >> >> Rui Barradas >> >> __ >> R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org <mailto: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] Is this a bug in `[`?
Thanks, This is what I needed. I had read the R Inferno a long time ago and apparently forgot this one. Rui Barradas Às 08:46 de 05/08/2018, Patrick Burns escreveu: This is Circle 8..1.13 of the R Inferno. On 05/08/2018 06:57, Rui Barradas wrote: Thanks. This is exactly the doubt I had. Rui Barradas Às 05:26 de 05/08/2018, Kenny Bell escreveu: This should more clearly illustrate the issue: c(1, 2, 3, 4)[-seq_len(4)] #> numeric(0) c(1, 2, 3, 4)[-seq_len(3)] #> [1] 4 c(1, 2, 3, 4)[-seq_len(2)] #> [1] 3 4 c(1, 2, 3, 4)[-seq_len(1)] #> [1] 2 3 4 c(1, 2, 3, 4)[-seq_len(0)] #> numeric(0) Created on 2018-08-05 by the reprex package (v0.2.0.9000). On Sun, Aug 5, 2018 at 3:58 AM Rui Barradas <mailto:ruipbarra...@sapo.pt>> wrote: Às 15:51 de 04/08/2018, Iñaki Úcar escreveu: > El sáb., 4 ago. 2018 a las 15:32, Rui Barradas > (mailto:ruipbarra...@sapo.pt>>) escribió: >> >> Hello, >> >> Maybe I am not understanding how negative indexing works but >> >> 1) This is right. >> >> (1:10)[-1] >> #[1] 2 3 4 5 6 7 8 9 10 >> >> 2) Are these right? They are at least surprising to me. >> >> (1:10)[-0] >> #integer(0) >> >> (1:10)[-seq_len(0)] >> #integer(0) >> >> >> It was the last example that made me ask, seq_len(0) whould avoid an >> if/else or something similar. > > I think it's ok, because there is no negative zero integer, so -0 is 0. Ok, this makes sense, I should have thought about that. > > 1.0/-0L # Inf > 1.0/-0.0 # - Inf > > And the same can be said for integer(0), which is the result of > seq_len(0): there is no negative empty integer. I'm not completely convinced about this one, though. I would expect -seq_len(n) to remove the first n elements from the vector, therefore, when n == 0, it would remove none. And integer(0) is not the same as 0. (1:10)[-0] == (1:10)[0] == integer(0) # empty (1:10)[-seq_len(0)] == (1:10)[-integer(0)] And I have just reminded myself to run identical(-integer(0), integer(0)) It returns TRUE so my intuition is wrong, R is right. End of story. Thanks for the help, Rui Barradas > > Iñaki > >> >> >> Thanks in advance, >> >> Rui Barradas >> >> __ >> R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org <mailto: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] bug report: inaccurate error message for stats::chisq.test
Hello,
A workaround could be
y <- addNA(y)
chisq.test(x,y)
But this implies that the user was aware of the reason why the error.
Hope this helps,
Rui Barradas
On 21/08/2018 15:31, Ant F wrote:
Hi,
`stats::chisq.test` checks that x and y each have at least 2 levels AFTER
filtering on complete cases.
It makes sense but the error message is misleading : “'x' and 'y' must have
at least 2 levels”
Here’s how to reproduce the issue :
x <- structure(c(1L, 1L, 1L, 2L, 1L, 2L), .Label = c("0001", "0003"),
class = "factor")
y <- structure(c(1L, 2L, 2L, NA, 2L, NA), .Label = c("0001", "0002"),
class = "factor")
chisq.test(x,y)
# Error in chisq.test(...) : 'x' and 'y' must have at least 2 levels
In this case they do have 2 levels.
Best regards,
Antoine
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
---
This email has been checked for viruses by AVG.
https://www.avg.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath degree symbol
Hello, Same here. Tested on R 3.1.1 and R 3.5.1 and they look *exactly* the same. Hope this helps, Rui Barradas On 26/08/2018 22:36, Paul Murrell wrote: Hi Sorry, but this seems to be working ok for me ... > sessionInfo() R version 3.4.2 (2017-09-28) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.5 LTS Matrix products: default BLAS: /usr/lib/libblas/libblas.so.3.6.0 LAPACK: /usr/lib/lapack/liblapack.so.3.6.0 locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8 LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8 LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.4.2 ... and ... > sessionInfo() R Under development (unstable) (2018-08-22 r75177) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.3 LTS Matrix products: default BLAS: /home/pmur002/R/r-devel/BUILD/lib/libRblas.so LAPACK: /home/pmur002/R/r-devel/BUILD/lib/libRlapack.so locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8 LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8 LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics utils datasets grDevices methods base loaded via a namespace (and not attached): [1] compiler_3.6.0 ... what is your setup ? Paul On 25/08/18 05:53, Edzer Pebesma wrote: In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. --- This email has been checked for viruses by AVG. https://www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is this a bug in `[`?
Hello, Thanks for the pointer. Inline. On 29/08/2018 04:17, Henrik Bengtsson wrote: FYI, this behavior is documented in Section 3.4.1 'Indexing by vectors' of 'R Language Definition' (accessible for instance via help.start()): "*Integer* [...] A special case is the zero index, which has null effects: x[0] is an empty vector and otherwise including zeros among positive or negative indices has the same effect as if they were omitted." So I was in part right, the zero index is handled as a special case. My use case was an operation in a function. I wasn't testing whether the result was of length zero, I was just using seq_len(result) to avoid the test. And found the error surprising. Thanks again, Rui Barradas The rest of that section is very useful and well written. I used it as the go-to reference to implement support for all those indexing alternatives in matrixStats. /Henrik On Sun, Aug 5, 2018 at 3:42 AM Iñaki Úcar wrote: El dom., 5 ago. 2018 a las 6:27, Kenny Bell () escribió: This should more clearly illustrate the issue: c(1, 2, 3, 4)[-seq_len(4)] #> numeric(0) c(1, 2, 3, 4)[-seq_len(3)] #> [1] 4 c(1, 2, 3, 4)[-seq_len(2)] #> [1] 3 4 c(1, 2, 3, 4)[-seq_len(1)] #> [1] 2 3 4 c(1, 2, 3, 4)[-seq_len(0)] #> numeric(0) Created on 2018-08-05 by the reprex package (v0.2.0.9000). IMO, the problem is that you are reading it sequentially: "-" remove "seq_" a sequence "len(0)" of length zero. But that's not how R works (how programming languages work in general). Instead, the sequence is evaluated in the first place, and then the sign may apply as long as you provided something that can hold a sign. And an empty element has no sign, so the sign is lost. Iñaki On Sun, Aug 5, 2018 at 3:58 AM Rui Barradas wrote: Às 15:51 de 04/08/2018, Iñaki Úcar escreveu: El sáb., 4 ago. 2018 a las 15:32, Rui Barradas () escribió: Hello, Maybe I am not understanding how negative indexing works but 1) This is right. (1:10)[-1] #[1] 2 3 4 5 6 7 8 9 10 2) Are these right? They are at least surprising to me. (1:10)[-0] #integer(0) (1:10)[-seq_len(0)] #integer(0) It was the last example that made me ask, seq_len(0) whould avoid an if/else or something similar. I think it's ok, because there is no negative zero integer, so -0 is 0. Ok, this makes sense, I should have thought about that. 1.0/-0L # Inf 1.0/-0.0 # - Inf And the same can be said for integer(0), which is the result of seq_len(0): there is no negative empty integer. I'm not completely convinced about this one, though. I would expect -seq_len(n) to remove the first n elements from the vector, therefore, when n == 0, it would remove none. And integer(0) is not the same as 0. (1:10)[-0] == (1:10)[0] == integer(0) # empty (1:10)[-seq_len(0)] == (1:10)[-integer(0)] And I have just reminded myself to run identical(-integer(0), integer(0)) It returns TRUE so my intuition is wrong, R is right. End of story. Thanks for the help, Rui Barradas Iñaki Thanks in advance, Rui Barradas __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel --- This email has been checked for viruses by AVG. https://www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ROBUSTNESS: x || y and x && y to give warning/error if length(x) != 1 or length(y) != 1
Hello,
Inline.
Às 16:44 de 30/08/2018, William Dunlap via R-devel escreveu:
Should the following two functions should always give the same result,
except for possible differences in the 'call' component of the warning
or error message?:
f0 <- function(x, y) x || y
f1 <- function(x, y) if (x) { TRUE } else { if (y) {TRUE } else { FALSE }
}
And the same for the 'and' version?
g0 <- function(x, y) x && y
g1 <- function(x, y) if (x) { if (y) { TRUE } else { FALSE } } else {
FALSE }
The proposal is to make them act the same when length(x) or length(y) is
not 1.
Should they also act the same when x or y is NA? 'if (x)' currently stops
if is.na(x)
and 'x||y' does not. Or should we continue with 'if' restricted to
bi-valued
logical and '||' and '&&' handling tri-valued logic?
I expect R to continue to do
f0(FALSE, NA)# [1] NA
f0(NA, FALSE)# [1] NA
g0(TRUE, NA)# [1] NA
g0(NA, TRUE)# [1] NA
f1(FALSE, NA)
#Error in if (y) { : missing value where TRUE/FALSE needed
f1(NA, FALSE)
#Error in if (x) { : missing value where TRUE/FALSE needed
g1(TRUE, NA)
#Error in if (x) { : missing value where TRUE/FALSE needed
g1(NA, TRUE)
#Error in if (x) { : missing value where TRUE/FALSE needed
Please don't change this.
There's more to the logical operators than the operands' lengths. That
issue needs to be fixed but it doesn't mean a radical change should happen.
And the same goes for 'if'. Here the problem is completely different,
there's more to 'if' than '||' and '&&'. Any change should be done with
increased care. (Which I'm sure will, as always.)
Rui Barradas
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Thu, Aug 30, 2018 at 7:16 AM, Hadley Wickham wrote:
I think this is an excellent idea as it eliminates a situation which
is almost certainly user error. Making it an error would break a small
amount of existing code (even if for the better), so perhaps it should
start as a warning, but be optionally upgraded to an error. It would
be nice to have a fixed date (R version) in the future when the
default will change to error.
In an ideal world, I think the following four cases should all return
the same error:
if (logical()) 1
#> Error in if (logical()) 1: argument is of length zero
if (c(TRUE, TRUE)) 1
#> Warning in if (c(TRUE, TRUE)) 1: the condition has length > 1 and only
the
#> first element will be used
#> [1] 1
logical() || TRUE
#> [1] TRUE
c(TRUE, TRUE) || TRUE
#> [1] TRUE
i.e. I think that `if`, `&&`, and `||` should all check that their
input is a logical (or numeric) vector of length 1.
Hadley
On Tue, Aug 28, 2018 at 10:03 PM Henrik Bengtsson
wrote:
# Issue
'x || y' performs 'x[1] || y' for length(x) > 1. For instance (here
using R 3.5.1),
c(TRUE, TRUE) || FALSE
[1] TRUE
c(TRUE, FALSE) || FALSE
[1] TRUE
c(TRUE, NA) || FALSE
[1] TRUE
c(FALSE, TRUE) || FALSE
[1] FALSE
This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the
same) and it also applies to 'x && y'.
Note also how the above truncation of 'x' is completely silent -
there's neither an error nor a warning being produced.
# Discussion/Suggestion
Using 'x || y' and 'x && y' with a non-scalar 'x' or 'y' is likely a
mistake. Either the code is written assuming 'x' and 'y' are scalars,
or there is a coding error and vectorized versions 'x | y' and 'x & y'
were intended. Should 'x || y' always be considered an mistake if
'length(x) != 1' or 'length(y) != 1'? If so, should it be a warning
or an error? For instance,
'''r
x <- c(TRUE, TRUE)
y <- FALSE
x || y
Error in x || y : applying scalar operator || to non-scalar elements
Execution halted
What about the case where 'length(x) == 0' or 'length(y) == 0'? Today
'x || y' returns 'NA' in such cases, e.g.
logical(0) || c(FALSE, NA)
[1] NA
logical(0) || logical(0)
[1] NA
logical(0) && logical(0)
[1] NA
I don't know the background for this behavior, but I'm sure there is
an argument behind that one. Maybe it's simply that '||' and '&&'
should always return a scalar logical and neither TRUE nor FALSE can
be returned.
/Henrik
PS. This is in the same vein as
https://mailman.stat.ethz.ch/pipermail/r-devel/2017-March/073817.html
- in R (>=3.4.0) we now get that if (1:2 == 1) ... is an error if
_R_CHECK_LENGTH_1_CONDITION_=true
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://hadley.nz
__
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] compairing doubles
Hello, Watch out for operator precedence. all.equal(0.3, 0.1*3) #[1] TRUE `%~~%` <- function (e1, e2) all.equal(e1, e2) 0.3 %~~% 0.1*3 #Error in 0.3 %~~% 0.1 * 3 : argumento não-numérico para operador binário 0.3 %~~% (0.1*3) #[1] TRUE Now with isTRUE. The problem changes a bit. isTRUE(all.equal(0.3, 0.1*3)) #[1] TRUE `%~~%` <- function (e1, e2) isTRUE(all.equal(e1, e2)) 0.3 %~~% 0.1*3 #[1] 0 0.3 %~~% (0.1*3) #[1] TRUE Hope this helps, Rui Barradas Às 08:20 de 03/09/2018, Juan Telleria Ruiz de Aguirre escreveu: Maybe a new Operator could be defined for a fast and easy double Comparison: `~~` `~~` <- function (e1, e2) all.equal(e1, e2) And document it properly. __ 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] R grpc
Hello,
Do you really need a prebuild binary? Wouldn't this do it?
devtools::install_github("nfultz/grpc")
Hope this helps,
Rui Barradas
Às 20:14 de 02/10/2018, Witold E Wolski escreveu:
Hello,
I am looking for a prebuild - binary MS Windows version of the R grpc package
https://github.com/nfultz/grpc
best regards
Witek
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning when calling formals() for `[`.
Hello, I believe that this is maybe not a *feature* but at least expected behaviour. The call formals(args(`[`)) breaks down to > args(`[`) NULL > formals(NULL) NULL Warning message: In formals(fun) : argument is not a function Hope this helps, Rui Barradas Às 18:26 de 06/10/2018, Laurent Gautier escreveu: Hi, A short code example showing the warning might the only thing needed here: ``` formals(args(`[`)) NULL *Warning message:In formals(fun) : argument is not a function* is.function(`[`) [1] TRUE is.primitive(`[`) [1] TRUE ``` Now with an other primitive: ``` formals(args(`sum`)) $... $na.rm [1] FALSE is.function(`sum`) [1] TRUE is.primitive(`sum`) [1] TRUE class(`[`) [1] "function" ``` Is this a feature ? Laurent [[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] Warning when calling formals() for `[`.
Hello, I forgot to ask you to also try to break the `sum` instruction into its components: args(`sum`) does return a function. Therefore formals(args(`sum`)) returns something useable and no warning. Rui Barradas Às 18:42 de 06/10/2018, Rui Barradas escreveu: Hello, I believe that this is maybe not a *feature* but at least expected behaviour. The call formals(args(`[`)) breaks down to > args(`[`) NULL > formals(NULL) NULL Warning message: In formals(fun) : argument is not a function Hope this helps, Rui Barradas Às 18:26 de 06/10/2018, Laurent Gautier escreveu: Hi, A short code example showing the warning might the only thing needed here: ``` formals(args(`[`)) NULL *Warning message:In formals(fun) : argument is not a function* is.function(`[`) [1] TRUE is.primitive(`[`) [1] TRUE ``` Now with an other primitive: ``` formals(args(`sum`)) $... $na.rm [1] FALSE is.function(`sum`) [1] TRUE is.primitive(`sum`) [1] TRUE class(`[`) [1] "function" ``` Is this a feature ? Laurent [[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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning when calling formals() for `[`.
Hello,
I don't see why you say that the documentation seems to be wrong:
class(args(`+`))
#[1] "function"
args() on a primitive does return a closure. At least in this case it does.
Rui Barradas
Às 14:05 de 07/10/2018, Peter Dalgaard escreveu:
There is more "fun" afoot here, but I don't recall what the point may be:
args(get("+"))
function (e1, e2)
NULL
args(get("["))
NULL
get("[")
.Primitive("[")
get("+")
function (e1, e2) .Primitive("+")
The other index operators, "[[", "[<-", "[[<-" are similar
The docs are pretty clear that args() on a primitive should yield a closure, so
at least the documentation seems to be wrong.
-pd
On 6 Oct 2018, at 19:26 , Laurent Gautier wrote:
Hi,
A short code example showing the warning might the only thing needed here:
```
formals(args(`[`))
NULL
*Warning message:In formals(fun) : argument is not a function*
is.function(`[`)
[1] TRUE
is.primitive(`[`)
[1] TRUE
```
Now with an other primitive:
```
formals(args(`sum`))
$...
$na.rm
[1] FALSE
is.function(`sum`)
[1] TRUE
is.primitive(`sum`)
[1] TRUE
class(`[`)
[1] "function"
```
Is this a feature ?
Laurent
[[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] Warning when calling formals() for `[`.
Hello,
This is the *third* time I send this, the first two I had a failure
notice so if you have already received it please apologize.
I believe this is consistent with the doc.
From section Value:
formals returns the formal argument list of the function specified, as a
pairlist, or NULL for a non-function or primitive.
So since `+` is primitive formals is expected to return NULL.
Now, as for formals(args(`+`)) once again break it down to its two parts.
> args(`+`)
function (e1, e2)
NULL
Now pass the return value to formals.
> formals(function (e1, e2) NULL)
$e1
$e2
(I first tried this last call with the argument between back ticks and
it didn't work, I wonder why.)
Hope this helps,
Rui Barradas
Às 18:52 de 06/10/2018, Laurent Gautier escreveu:
Hi,
Thanks for the note. How would explain the following snippet taken from
`formals` doc page (the code comment is also from that doc) ?
## formals returns NULL for primitive functions. Use it in combination with
## args for this case.
is.primitive(`+`)
formals(`+`)
formals(args(`+`))
Le sam. 6 oct. 2018 à 13:42, Rui Barradas <mailto:ruipbarra...@sapo.pt>> a écrit :
Hello,
I believe that this is maybe not a *feature* but at least expected
behaviour.
The call formals(args(`[`)) breaks down to
> args(`[`)
NULL
> formals(NULL)
NULL
Warning message:
In formals(fun) : argument is not a function
Hope this helps,
Rui Barradas
Às 18:26 de 06/10/2018, Laurent Gautier escreveu:
> Hi,
>
> A short code example showing the warning might the only thing
needed here:
>
> ```
>> formals(args(`[`))
> NULL
>
> *Warning message:In formals(fun) : argument is not a function*
>> is.function(`[`)
> [1] TRUE
>> is.primitive(`[`)
> [1] TRUE
> ```
>
> Now with an other primitive:
>
> ```
>> formals(args(`sum`))
> $...
>
>
> $na.rm
> [1] FALSE
>
>> is.function(`sum`)
> [1] TRUE
>> is.primitive(`sum`)
> [1] TRUE
>> class(`[`)
> [1] "function"
> ```
>
> Is this a feature ?
>
>
> Laurent
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org <mailto: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] Warning when calling formals() for `[`.
Hello,
Inline.
Às 15:07 de 07/10/2018, Laurent Gautier escreveu:
Note that having "function" in its class attribute does not make an
object a primitive.
I did not say it does.
What Peter said is that "args() on a primitive should yield a closure"
and this return value is indeed a closure.
Rui Barradas
For example:
> class(`[`)
[1] "function"
> is.primitive(`[`)
[1] TRUE
> class(`rnorm`)
[1] "function"
> is.primitive(`rnorm`)
[1] FALSE
Le dim. 7 oct. 2018 à 10:04, Rui Barradas <mailto:ruipbarra...@sapo.pt>> a écrit :
Hello,
I don't see why you say that the documentation seems to be wrong:
class(args(`+`))
#[1] "function"
args() on a primitive does return a closure. At least in this case
it does.
Rui Barradas
Às 14:05 de 07/10/2018, Peter Dalgaard escreveu:
> There is more "fun" afoot here, but I don't recall what the point
may be:
>
>> args(get("+"))
> function (e1, e2)
> NULL
>> args(get("["))
> NULL
>> get("[")
> .Primitive("[")
>> get("+")
> function (e1, e2) .Primitive("+")
>
> The other index operators, "[[", "[<-", "[[<-" are similar
>
> The docs are pretty clear that args() on a primitive should yield
a closure, so at least the documentation seems to be wrong.
>
> -pd
>
>
>> On 6 Oct 2018, at 19:26 , Laurent Gautier mailto:lgaut...@gmail.com>> wrote:
>>
>> Hi,
>>
>> A short code example showing the warning might the only thing
needed here:
>>
>> ```
>>> formals(args(`[`))
>> NULL
>>
>> *Warning message:In formals(fun) : argument is not a function*
>>> is.function(`[`)
>> [1] TRUE
>>> is.primitive(`[`)
>> [1] TRUE
>> ```
>>
>> Now with an other primitive:
>>
>> ```
>>> formals(args(`sum`))
>> $...
>>
>>
>> $na.rm
>> [1] FALSE
>>
>>> is.function(`sum`)
>> [1] TRUE
>>> is.primitive(`sum`)
>> [1] TRUE
>>> class(`[`)
>> [1] "function"
>> ```
>>
>> Is this a feature ?
>>
>>
>> Laurent
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org <mailto: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] Warning when calling formals() for `[`.
Hello,
This is because args(`[`) returns NULL and class(NULL) is NULL.
So the question would be why is the return value of args(`[`) NULL?
Rui Barradas
Às 15:14 de 07/10/2018, Peter Dalgaard escreveu:
On 7 Oct 2018, at 16:04 , Rui Barradas wrote:
Hello,
I don't see why you say that the documentation seems to be wrong:
class(args(`+`))
#[1] "function"
args() on a primitive does return a closure. At least in this case it does.
But in this case it doesn't:
is.primitive(get("["))
[1] TRUE
class(args(get("[")))
[1] "NULL"
Or, for that matter:
is.primitive(`[`)
[1] TRUE
class(args(`[`))
[1] "NULL"
-pd
Rui Barradas
Às 14:05 de 07/10/2018, Peter Dalgaard escreveu:
There is more "fun" afoot here, but I don't recall what the point may be:
args(get("+"))
function (e1, e2)
NULL
args(get("["))
NULL
get("[")
.Primitive("[")
get("+")
function (e1, e2) .Primitive("+")
The other index operators, "[[", "[<-", "[[<-" are similar
The docs are pretty clear that args() on a primitive should yield a closure, so
at least the documentation seems to be wrong.
-pd
On 6 Oct 2018, at 19:26 , Laurent Gautier wrote:
Hi,
A short code example showing the warning might the only thing needed here:
```
formals(args(`[`))
NULL
*Warning message:In formals(fun) : argument is not a function*
is.function(`[`)
[1] TRUE
is.primitive(`[`)
[1] TRUE
```
Now with an other primitive:
```
formals(args(`sum`))
$...
$na.rm
[1] FALSE
is.function(`sum`)
[1] TRUE
is.primitive(`sum`)
[1] TRUE
class(`[`)
[1] "function"
```
Is this a feature ?
Laurent
[[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] Subsetting row in single column matrix drops names in resulting vector
Hello,
Use drop = FALSE.
a[1, , drop = FALSE]
# col1
#row11
Hope this helps,
Rui Barradas
Às 16:51 de 21/11/2018, Dmitriy Selivanov escreveu:
Hello here. I'm struggling to understand R's subsetting behavior in couple
of edge cases - subsetting row in a single column matrix and subsetting
column in a single row matrix. I've read R's docs several times and haven't
found answer.
Consider following example:
a = matrix(1:2, nrow = 2, dimnames = list(c("row1", "row2"), c("col1")))
a[1, ]
# 1
It returns *unnamed* vector `1` where I would expect named vector. In fact
it returns named vector when number of columns is > 1.
Same issue applicable to single row matrix. Is it a bug? looks very
counterintuitive.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] nlminb with constraints failing on some platforms
Hello, R 3.5.2 on ubuntu 18.04. sessionInfo() at the end. Works with me, same results, cannot reproduce the error. f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) str(opt) xhat <- rep(1, 10) all.equal(opt$par, xhat, tol=0) # good: 5.53 e-7 #[1] "Mean relative difference: 5.534757e-07" all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12 #[1] "Mean relative difference: 1.816536e-12" abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE #[1] TRUE Hope this helps, Rui Barradas sessionInfo() R version 3.5.2 (2018-12-20) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.1 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 locale: [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8 [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8 [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] Rcpp_1.0.0 rstudioapi_0.8 bindr_0.1.1 magrittr_1.5 [5] tidyselect_0.2.5 munsell_0.5.0colorspace_1.3-2 lattice_0.20-38 [9] R6_2.3.0 rlang_0.3.0.1stringr_1.3.1plyr_1.8.4 [13] dplyr_0.7.8 tools_3.5.2 grid_3.5.2 yaml_2.2.0 [17] assertthat_0.2.0 tibble_1.4.2 crayon_1.3.4 bindrcpp_0.2.2 [21] purrr_0.2.5 reshape2_1.4.3 glue_1.3.0 stringi_1.2.4 [25] compiler_3.5.2 pillar_1.3.1 scales_1.0.0 lubridate_1.7.4 [29] pkgconfig_2.0.2 zoo_1.8-4 Às 09:00 de 01/02/2019, Martin Maechler escreveu: Kasper Kristensen via R-devel on Mon, 28 Jan 2019 08:56:39 + writes: > I've noticed unstable behavior of nlminb on some Linux > systems. The problem can be reproduced by compiling > R-3.5.2 using gcc-8.2 and running the following snippet: > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) > xhat <- rep(1, 10) > abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE > The example works perfectly when removing the bounds. However, when bounds are added the snippet returns 'FALSE'. > An older R version (3.4.4), compiled using the same gcc-8.2, did not have the problem. Between the two versions R has changed the flags to compile Fortran sources: > < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store > --- >> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse > Reverting to the old SAFE_FFLAGS 'solves' the problem. >> sessionInfo() > R version 3.5.2 (2018-12-20) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Scientific Linux release 6.4 (Carbon) > Matrix products: default > BLAS/LAPACK: /zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so > locale: > [1] C > attached base packages: > [1] stats graphics grDevices utils datasets methods base > loaded via a namespace (and not attached): > [1] compiler_3.5.2 So you us Intel's MKL library for BLAS/LAPACK .. I also use gcc 8.2 (on Fedora 28 Linux) and R's own BLAS/LAPACK and don't see such problems: The code f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) str(opt) xhat <- rep(1, 10) all.equal(opt$par, xhat, tol=0) # good: 5.53 e-7 all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12 abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE gives f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) str(opt) List of 6 $ par: num [1:10] 1 1 1 1 1 ... $ objective : num -41.4 $ convergence: int 0 $ iterations : int 66 $ evaluations: Named int [1:2] 96 830 ..- attr(*, "names")= chr [1:2] "function" "gradient" $ message: chr "relative convergence (4)" xhat <- rep(1, 10) all.equal(opt$par, xhat, tol=0) # good: 5.53 e-7 [1] "Mean relative difference: 5.534757e-07" all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12 [1] "Mean relative difference: 1.816536e-12" abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE [1] TRUE for me. Maybe others can quickly run the above 7 lines and report ? Maybe there's something else unusual with your Linux distribution's libraries? I'm not an expert on these compiler
Re: [Rd] Return/print standard error in t.test()
Hello,
Something like this?
t.test2 <- function(...) {
ht <- t.test(...)
class(ht) <- c("htest_tjl", class(ht))
ht
}
print.htest_tjl <- function(x, ...) {
NextMethod(x, ...)
se <- as.vector(abs(diff(x$estimate)/x$statistic))
cat("Standard error of the difference:", se, "\n\n")
invisible(x)
}
t.test2(1:10, y = c(7:20))
t.test2(extra ~ group, data = sleep) # last example from ?t.test
(The suffix tjl commes from the OP's initials.)
Hope this helps,
Rui Barradas
Às 21:51 de 21/02/2019, Fox, John escreveu:
Dear Thomas,
it is, unfortunately, not that simple. t.test() returns an object of class
"htest" and not all such objects have standard errors. I'm not entirely sure
what the point is since it's easy to compute the standard error of the difference from
the information in the object (adapting an example from ?t.test):
(res <- t.test(1:10, y = c(7:20)))
Welch Two Sample t-test
data: 1:10 and c(7:20)
t = -5.4349, df = 21.982, p-value = 1.855e-05
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
-11.052802 -4.947198
sample estimates:
mean of x mean of y
5.5 13.5
as.vector(abs(diff(res$estimate)/res$statistic)) # SE
[1] 1.47196
class(res)
[1] "htest"
and if you really want to print the SE as a matter of course, you could always write your
own wrapper for t.test() that returns an object of class, say, "t.test" for
which you can provide a print() method. Much of the advantage of working in a statistical
computing environment like R (or Stata, for that matter) is that you can make things work
the way you like.
Best,
John
-
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
Web: http::/socserv.mcmaster.ca/jfox
On Feb 21, 2019, at 3:57 PM, Thomas J. Leeper wrote:
A recent thread on Twitter [1] by a Stata user highlighted that t.test()
does not return or print the standard error of the mean difference, despite
it being calculated by the function.
I know this isn’t the kind of change that’s likely to be made but could we
at least return the SE even if the print() method isn’t updated? Or,
better, update the print() method to display this as well?
Best,
Thomas
[1]
https://twitter.com/amandayagan/status/1098314654470819840?s=21
--
Thomas J. Leeper
http://www.thomasleeper.com
[[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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Intermittent crashes with inset `[<-` command
Hello,
I can also reproduce this, R 3.5.2 on Ubuntu 18.04 LTS.
First run gives error after 148.
After 148:
Error in `[<-`(x, y == "a", x[y == "b"]) :
substituto tem comprimento zero
Execução interrompida
Translation:
replacement has length zero
Execution stopped
Second run gives a different error, I changed the script to start with a
sessionInfo() instruction, everything else is the same as in the OP.
After 180:
*** caught segfault ***
address 0x70002, cause 'memory not mapped'
An irrecoverable exception occurred. R is aborting now ...
Several runs with or without the sessionInfo() always give the two
different errors above.
The sessionInfo() was the following.
sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.1 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.5.2
Hope this helps,
Rui Barradas
Às 08:46 de 27/02/2019, Serguei Sokol escreveu:
On 26/02/2019 05:18, Brian Montgomery via R-devel wrote:
The following code crashes after about 300 iterations on
my x86_64-w64-mingw32 machine on R 3.5.2 --vanilla.
Others have duplicated this
(see https://github.com/tidyverse/magrittr/issues/190 if necessary),
but I don't know how machine/OS-dependent it may be.
It crashes too on my Mageia6 (RPM based Linux distribution):
184 185 186 187
*** caught segfault ***
address 0x70002, cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
The crash can happen at different moments, sometimes after i=187 like in
the example above, sometimes after i=915. The error is not always
segfault. It can also be
915 Error in `[<-`(x, y == "a", x[y == "b"]) : replacement has length zero
or
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Error in
`[<-`(x, y == "a", x[y == "b"]) :
types (de raw a integer) incompatibles dans l'ajustement
d'affectation de type
(sorry, this crash was in french locale)
Hoping this helps.
Serguei.
> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Mageia 6
Matrix products: default
BLAS/LAPACK: /home/opt/OpenBLAS/lib/libopenblas_sandybridge-r0.3.3.so
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.5.2
If it doesn't crash for you, please try increasing the length of the x
vector.
Substituting the commented-out line for the one below it works
correctly (prints out 1:1000 and ends normally) every time.
x <- 1:20
y <- rep(letters[1:5], length(x) / 5L)
for (i in 1:1000) {
# x[y == 'a'] <- x[y == 'b']
x <- `[<-`(x, y == 'a', x[y == 'b'])
cat(i, '')
}
cat('\n')
The point of using this syntax is to make it work better with pipes,
but the errors occur without pipes or magrittr.
Thank you for your help!
__
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] Exit status of Rscript
Hello,
I cannot reproduce this, R 3.5.2 on Ubuntu 18.04 LTS. sessionInfo() below.
system2("Rscript", c("-e", shQuote("stop('foo')"))) == 0
#Erro: foo
#Execução interrompida
#[1] FALSE
r <- system2("Rscript", c("-e", shQuote("stop('foo')")))
#Erro: foo
#Execução interrompida
print(r)
#[1] 1
sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.1 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
loaded via a namespace (and not attached):
[1] compiler_3.5.2 tools_3.5.2yaml_2.2.0
Hope this helps,
Rui Barradas
Às 12:23 de 28/02/2019, Michel Lang escreveu:
Current R release (3.5.2) and devel return a 0 exit status on error,
while prior versions returned a non-zero exit status. On Linux and
MacOs, the following line returns TRUE for R-3.5.2 and R-devel, and
FALSE for R-3.5.1 and R-3.5.0:
system2("Rscript", c("-e", shQuote("stop('foo')"))) == 0
I didn't find this in the NEWS, so I believe this is a bug.
Best,
Michel
__
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] Discrepancy between is.list() and is(x, "list")
Hello,
Here is another example.
df1 <- data.frame(a = 1:3, b = 4:6)
inherits(df1, "data.frame")
#[1] TRUE
class(df1)
#[1] "data.frame"
inherits(df1, "list")
#[1] FALSE
This is documented behavior, the help page ?inherits says
The function class prints the vector of names of classes an object
inherits from.
So far, so good. But now comes the part I don't like.
is.list(df1)
#[1] TRUE
Strictly speaking this is not unexpected behavior (because it's
documented) but isn't it *inconsistent* behavior?
Rui Barradas
Às 16:30 de 26/03/2019, Berry, Charles escreveu:
In the case of inherits (at least) this seems intended.
The help page says:
"If the object does not have a class attribute, it has an implicit class..."
which I take to mean that if an object does have a class attribute it does not
also have an implicit class.
The behavior you noted below will apply to other types bearing implicit
classes. For example:
inherits(1.0, "numeric")
[1] TRUE
inherits(structure(1.0, class="myclass"), "numeric")
[1] FALSE
I think this is reasonable behavior. Consider the "Date" class, which stores values as
"numeric":
class(Sys.Date())
[1] "Date"
inherits(Sys.Date(),"numeric")
[1] FALSE
class(unclass(Sys.Date()))
[1] "numeric"
Sys.Date()%%2
Error in Ops.Date(Sys.Date(), 2) : %% not defined for "Date" objects
Letting the modulus operator (as one example) inherit the numeric class here
could create problems.
Of course for classes that should inherit the implicit type, it can be
explicitly added to the end of the class() vector by its constructor.
HTH,
Chuck
On Mar 25, 2019, at 8:27 PM, Abs Spurdle wrote:
I have noticed a discrepancy between is.list() and is(x, “list”)
There's a similar problem with inherits().
On R 3.5.3:
f = function () 1
class (f) = "f"
is.function (f)
[1] TRUE
inherits (f, "function")
[1] FALSE
I didn't check what happens with:
class (f) = c ("f", "function")
However, they should have the same result, regardless.
Is this discrepancy intentional?
I hope not.
[[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] [r-devel] integrate over an infinite region produces wrong results depending on scaling
Hello, A solution is to use package cubature, both unscaled and scaled versions return the correct result, 3.575294. But the performance penalty is BIG. This is because the number of evaluations is much bigger. library(cubature) cubintegrate(f, -Inf, 0, method = "hcubature") #$integral #[1] 3.575294 # #$error #[1] 1.494242e-07 # #$neval #[1] 375 # #$returnCode #[1] 0 cubintegrate(f, -Inf, 0, method = "hcubature", numstab = sc) #$integral #[1] 3.575294 # #$error #[1] 1.064195e-05 # #$neval #[1] 255 # #$returnCode #[1] 0 library(microbenchmark) microbenchmark( base1 = integrate(f, -Inf, 0), base2 = integrate(f, -Inf, 0, numstab = sc), cuba1 = cubintegrate(f, -Inf, 0, method = "hcubature"), cuba2 = cubintegrate(f, -Inf, 0, method = "hcubature", numstab = sc) ) Hope this helps, Rui Barradas Às 15:52 de 12/04/19, Andreï V. Kostyrka escreveu: Dear all, This is the first time I am posting to the r-devel list. On StackOverflow, they suggested that the strange behaviour of integrate() was more bug-like. I am providing a short version of the question (full one with plots: https://stackoverflow.com/q/55639401). Suppose one wants integrate a function that is just a product of two density functions (like gamma). The support of the random variable is (-Inf, 0]. The scale parameter of the distribution is quite small (around 0.01), so often, the standard integration routine would fail to integrate a function that is non-zero on a very small section of the negative line (like [-0.02, -0.01], where it takes huge values, and almost 0 everywhere else). R’s integrate would often return the machine epsilon as a result. So I stretch the function around the zero by an inverse of the scale parameter, compute the integral, and then divide it by the scale. Sometimes, this re-scaling also failed, so I did both if the first result was very small. Today when integration of the rescaled function suddenly yielded a value of 1.5 instead of 3.5 (not even zero). The MWE is below. cons <- -0.020374721416129591 sc <- 0.00271245601724757383 sh <- 5.704 f <- function(x, numstab = 1) dgamma(cons - x * numstab, shape = sh, scale = sc) * dgamma(-x * numstab, shape = sh, scale = sc) * numstab curve(f, -0.06, 0, n = 501, main = "Unscaled f", bty = "n") curve(f(x, sc), -0.06 / sc, 0, n = 501, main = "Scaled f", bty = "n") sum(f(seq(-0.08, 0, 1e-6))) * 1e-6 # Checking by summation: 3.575294 sum(f(seq(-30, 0, 1e-4), numstab = sc)) * 1e-4 # True value, 3.575294 str(integrate(f, -Inf, 0)) # Gives 3.575294 # $ value : num 3.58 # $ abs.error : num 1.71e-06 # $ subdivisions: int 10 str(integrate(f, -Inf, 0, numstab = sc)) # $ value : num 1.5 # What?! # $ abs.error : num 0.000145 # What?! # $ subdivisions: int 2 It stop at just two subdivisions! The problem is, I cannot try various stabilising multipliers for the function because I have to compute this integral thousands of times for thousands of parameter values on thousands of sample windows for hundreds on models, so even in the super-computer cluster, this takes weeks. Besides that, reducing the rel.tol just to 1e-5 or 1e-6, helped a bit, but I am not sure whether this guarantees success (and reducing it to 1e-7 slowed down the computations in some cases). And I have looked at the Fortran code of the quadrature just to see the integration rule, and was wondering. How can I make sure that the integration routine will not produce such wrong results for such a function, and the integration will still be fast? Yours sincerely, Andreï V. Kostyrka __ 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] [R] Open a file which name contains a tilde
Hello,
R 3.6.0 on Ubuntu 19.04.
Since no one mentioned it, notice that the tilde in the middle of a
string needs to be surrounded by spaces to be expanded.
The first code line works as expected, only the second is wrong (buggy).
path.expand('a~b')
#[1] "a~b"
path.expand('a ~ b')
#[1] "a /home/rui b"
Rui Barradas
Às 04:27 de 08/06/19, Richard O'Keefe escreveu:
?path.expand
Expand a path name, for example by replacing a leading tilde by
the user's home directory (if defined on that platform).
*A* path name. The argument is a character vector.
If multiple path names are passed, they are passed
On most builds of R *A LEADING* "~user" will be replaced...
Nothing is said in the R documentation about *multiple* or
*non-leading* tildes being replaced.
The actual behaviour is inconsistent with the documentation.
SOMETHING is a bug.
It's not clear to me why this is in any way dependent on
readline. I've implemented tilde expansion several times
and always without readline.
It sounds as though R might be calling tilde_expand()
when it *should*, to be consistent with the documentation,
be calling tilde_expand_word().
as separate elements of the character vector.
On Sat, 8 Jun 2019 at 04:10, Berry, Charles wrote:
On Jun 6, 2019, at 2:04 PM, Richard O'Keefe wrote:
How can expanding tildes anywhere but the beginning of a file name NOT be
considered a bug?
I think that that IS what libreadline is doing if one allows a whitespace
separated list of file names.
As reported in R-help,
https://www.mail-archive.com/r-help@r-project.org/msg254116.html
path.expand seems to expand tildes beginning whitespace separated strings
that could be filenames, but not other tildes.
Thus,
path.expand("~/.newsrc ~/.R/*") # expands both tildes
[1] "/Users/cberry/.newsrc /Users/cberry/.R/*"
path.expand("~/.newsrc~/.R/*") # expands only the first
[1] "/Users/cberry/.newsrc~/.R/*"
This could be a feature if what one wanted was to pass the result to a
system command that will process multiple file arguments, e.g.
system(paste( "wc", path.expand("~/.newsrc ~/.R/*"))) # run wc on some
files
I doubt that this was intended by R-core, but perhaps the readline devs
had this in mind.
Chuck
On Thu, 6 Jun 2019 at 23:04, Ivan Krylov wrote:
On Wed, 5 Jun 2019 18:07:15 +0200
Frank Schwidom wrote:
+> path.expand("a ~ b")
[1] "a /home/user b"
How can I switch off any file crippling activity?
It doesn't seem to be possible if readline is enabled and works
correctly.
Calls to path.expand [1] end up [2] in R_ExpandFileName [3], which
calls R_ExpandFileName_readline [4], which uses libreadline function
tilde_expand [5]. tilde_expand seems to be designed to expand '~'
anywhere in the string it is handed, i.e. operate on whole command
lines, not file paths.
I am taking the liberty of Cc-ing R-devel in case this can be
considered a bug.
--
Best regards,
Ivan
[1]
https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/names.c#L807
[2]
https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/main/platform.c#L1915
[3]
https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-unix.c#L147
[4]
https://github.com/wch/r-source/blob/12d1d2d232d84aa355e48b81180a0e2c6f2f/src/unix/sys-std.c#L494
[5]
https://git.savannah.gnu.org/cgit/readline.git/tree/tilde.c?h=devel#n187
__
r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[[alternative HTML version deleted]]
[[alternative HTML version deleted]]
__
r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calculation of e^{z^2/2} for a normal deviate z
Hello, Well, try it: p <- .Machine$double.eps^seq(0.5, 1, by = 0.05) z <- qnorm(p/2) pnorm(z) # [1] 7.450581e-09 1.22e-09 2.026908e-10 3.343152e-11 5.514145e-12 # [6] 9.094947e-13 1.500107e-13 2.474254e-14 4.080996e-15 6.731134e-16 #[11] 1.110223e-16 p/2 # [1] 7.450581e-09 1.22e-09 2.026908e-10 3.343152e-11 5.514145e-12 # [6] 9.094947e-13 1.500107e-13 2.474254e-14 4.080996e-15 6.731134e-16 #[11] 1.110223e-16 exp(z*z/2) # [1] 9.184907e+06 5.301421e+07 3.073154e+08 1.787931e+09 1.043417e+10 # [6] 6.105491e+10 3.580873e+11 2.104460e+12 1.239008e+13 7.306423e+13 #[11] 4.314798e+14 p is the smallest possible such that 1 + p != 1 and I couldn't find anything to worry about. R version 3.6.0 (2019-04-26) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 19.04 Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0 locale: [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8 [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8 [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods [7] base other attached packages: [many packages loaded] Hope this helps, Rui Barradas Às 15:24 de 21/06/19, jing hua zhao escreveu: Dear R-developers, I am keen to calculate exp(z*z/2) with z=qnorm(p/2) and p is very small. I wonder if anyone has experience with this? Thanks very much in advance, Jing Hua [[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] Calculation of e^{z^2/2} for a normal deviate z
Hello,
Sorry, my mistake, I grossly misunderstood the question.
qnorm(1e-300)
#[1] -37.0471
Anyway, you cannot go much smaller.
p <- 10^seq(-300, -400, by = -10)
z <- qnorm(p/2)
exp(z*z/2)
Hope this helps,
Rui Barradas
Às 16:11 de 21/06/19, jing hua zhao escreveu:
Dear Rui,
Thanks for your quick reply -- this allows me to see the bottom of this.
I was hoping we could have a handle of those p in genmoics such as
1e-300 or smaller.
Best wishes,
Jing Hua
*From:* Rui Barradas
*Sent:* 21 June 2019 15:03
*To:* jing hua zhao; r-devel@r-project.org
*Subject:* Re: [Rd] Calculation of e^{z^2/2} for a normal deviate z
Hello,
Well, try it:
p <- .Machine$double.eps^seq(0.5, 1, by = 0.05)
z <- qnorm(p/2)
pnorm(z)
# [1] 7.450581e-09 1.22e-09 2.026908e-10 3.343152e-11 5.514145e-12
# [6] 9.094947e-13 1.500107e-13 2.474254e-14 4.080996e-15 6.731134e-16
#[11] 1.110223e-16
p/2
# [1] 7.450581e-09 1.22e-09 2.026908e-10 3.343152e-11 5.514145e-12
# [6] 9.094947e-13 1.500107e-13 2.474254e-14 4.080996e-15 6.731134e-16
#[11] 1.110223e-16
exp(z*z/2)
# [1] 9.184907e+06 5.301421e+07 3.073154e+08 1.787931e+09 1.043417e+10
# [6] 6.105491e+10 3.580873e+11 2.104460e+12 1.239008e+13 7.306423e+13
#[11] 4.314798e+14
p is the smallest possible such that 1 + p != 1 and I couldn't find
anything to worry about.
R version 3.6.0 (2019-04-26)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 19.04
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8 LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8 LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
other attached packages:
[many packages loaded]
Hope this helps,
Rui Barradas
Às 15:24 de 21/06/19, jing hua zhao escreveu:
Dear R-developers,
I am keen to calculate exp(z*z/2) with z=qnorm(p/2) and p is very small. I
wonder if anyone has experience with this?
Thanks very much in advance,
Jing Hua
[[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] Possible bug in `class<-` when a class-specific '[[.' method is defined
Hello,
Clean R 3.6.1 session on Ubuntu 19.04, RStudio 1.1.453. sessionInfo() at
the end.
I can reproduce this.
counttt <- 0
`[[.MYCLASS` = function(x, ...) {
counttt <<- counttt + 1
# browser()
x = NextMethod()
return(x)
}
df <- as.data.frame(matrix(1:20, nrow=5))
class(df) <- c("MYCLASS","data.frame")
counttt
#[1] 9
But there's more. I tried to print the values of x in the method and got
really strange results
counttt <- 0
`[[.MYCLASS` = function(x, ...) {
counttt <<- counttt + 1
print(x)
# browser()
x = NextMethod()
return(x)
}
df <- as.data.frame(matrix(1:20, nrow=5))
class(df) <- c("MYCLASS","data.frame")
counttt
#[1] 151
If I change print to print.data.frame it goes up to
counttt
#[1] 176
With print.default back to 9. What is the print method called in the
second example?
sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 19.04
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
loaded via a namespace (and not attached):
[1] sos_2.0-0 nlme_3.1-140matrixStats_0.54.0
[4] fs_1.2.7xts_0.11-2 usethis_1.5.0
[7] lubridate_1.7.4 devtools_2.0.2 RColorBrewer_1.1-2
[10] rprojroot_1.3-2 rbenchmark_1.0.0tools_3.6.1
[13] backports_1.1.4 R6_2.4.0rpart_4.1-15
[16] Hmisc_4.2-0 lazyeval_0.2.2 colorspace_1.4-1
[19] nnet_7.3-12 npsurv_0.4-0withr_2.1.2
[22] tidyselect_0.2.5gridExtra_2.3 prettyunits_1.0.2
[25] processx_3.3.0 curl_3.3compiler_3.6.1
[28] cli_1.1.0 htmlTable_1.13.1randomNames_1.4-0.0
[31] dvmisc_1.1.3desc_1.2.0 tseries_0.10-46
[34] scales_1.0.0checkmate_1.9.1 lmtest_0.9-36
[37] fracdiff_1.4-2 mvtnorm_1.0-10 quadprog_1.5-6
[40] callr_3.2.0 stringr_1.4.0 digest_0.6.18
[43] foreign_0.8-71 rio_0.5.16 base64enc_0.1-3
[46] stocks_1.1.4pkgconfig_2.0.2 htmltools_0.3.6
[49] sessioninfo_1.1.1 readxl_1.3.1htmlwidgets_1.3
[52] rlang_0.3.4 TTR_0.23-4 rstudioapi_0.10
[55] quantmod_0.4-14 MLmetrics_1.1.1 zoo_1.8-5
[58] zip_2.0.1 acepack_1.4.1 dplyr_0.8.0.1
[61] car_3.0-2 magrittr_1.5Formula_1.2-3
[64] Matrix_1.2-17 Rcpp_1.0.1 munsell_0.5.0
[67] abind_1.4-5 stringi_1.4.3 forecast_8.6
[70] yaml_2.2.0 carData_3.0-2 MASS_7.3-51.3
[73] pkgbuild_1.0.3 plyr_1.8.4 grid_3.6.1
[76] parallel_3.6.1 forcats_0.4.0 crayon_1.3.4
[79] lattice_0.20-38 haven_2.1.0 splines_3.6.1
[82] hms_0.4.2 knitr_1.22 ps_1.3.0
[85] pillar_1.4.0pkgload_1.0.2 urca_1.3-0
[88] glue_1.3.1 lsei_1.2-0 babynames_1.0.0
[91] latticeExtra_0.6-28 data.table_1.12.2 remotes_2.0.4
[94] cellranger_1.1.0testthat_2.1.0 gtable_0.3.0
[97] purrr_0.3.2 assertthat_0.2.1ggplot2_3.1.1
[100] openxlsx_4.1.0 xfun_0.6survey_3.35-1
[103] survival_2.44-1.1 timeDate_3043.102 tibble_2.1.1
[106] memoise_1.1.0 cluster_2.0.8 toOrdinal_1.1-0.0
[109] fitdistrplus_1.0-14 brew_1.0-6
Hope this helps,
Rui Barradas
Às 13:16 de 15/07/19, Duncan Murdoch escreveu:
On 07/07/2019 11:49 a.m., Ghiggi Gionata wrote:
Hi all !
I noticed a strange behaviour of the function `class<-` when a
class-specific '[[.' method is defined.
Here below a reproducible example :
#---.
counttt <- 0
`[[.MYCLASS` = function(x, ...) {
counttt <<- counttt + 1
# browser()
x = NextMethod()
return(x)
}
df <- as.data.frame(matrix(1:20, nrow=5))
class(df) <- c("MYCLASS","data.frame")
counttt
# The same occurs when using structure(, class=) or attr(,"class")<-
df <- as.data.frame(matrix(1:20, nrow=5))
df <- structure(df, class=c("MYCLASS","data.frame"))
attr(df, "class") <- c("MYCLASS","data.frame")
#---.
Why in this example `class<-` is calling `[[.MYCLASS` 9 times ?
Is there a way to avoid `class<-` to call `[[.MYCLASS` ?
Thank you in advance for your help and suggestions.
This is what I see:
Re: [Rd] Possible bug in `class<-` when a class-specific '[[.' method is defined
Hello, Inline. Às 14:26 de 15/07/19, Duncan Murdoch escreveu: On 15/07/2019 8:57 a.m., Rui Barradas wrote: Hello, Clean R 3.6.1 session on Ubuntu 19.04, RStudio 1.1.453. sessionInfo() at the end. That's not what I'd call a "clean session" with all those packages loaded: You are right, but when I wrote that it *was* clean. Then, for some reason I don't understand, RStudio loaded them all. Guess I'll have to check what is going on here. loaded via a namespace (and not attached): [1] sos_2.0-0 nlme_3.1-140 matrixStats_0.54.0 [4] fs_1.2.7 xts_0.11-2 usethis_1.5.0 [7] lubridate_1.7.4 devtools_2.0.2 RColorBrewer_1.1-2 [10] rprojroot_1.3-2 rbenchmark_1.0.0 tools_3.6.1 [13] backports_1.1.4 R6_2.4.0 rpart_4.1-15 [16] Hmisc_4.2-0 lazyeval_0.2.2 colorspace_1.4-1 [19] nnet_7.3-12 npsurv_0.4-0 withr_2.1.2 [22] tidyselect_0.2.5 gridExtra_2.3 prettyunits_1.0.2 [25] processx_3.3.0 curl_3.3 compiler_3.6.1 [28] cli_1.1.0 htmlTable_1.13.1 randomNames_1.4-0.0 [31] dvmisc_1.1.3 desc_1.2.0 tseries_0.10-46 [34] scales_1.0.0 checkmate_1.9.1 lmtest_0.9-36 [37] fracdiff_1.4-2 mvtnorm_1.0-10 quadprog_1.5-6 [40] callr_3.2.0 stringr_1.4.0 digest_0.6.18 [43] foreign_0.8-71 rio_0.5.16 base64enc_0.1-3 [46] stocks_1.1.4 pkgconfig_2.0.2 htmltools_0.3.6 [49] sessioninfo_1.1.1 readxl_1.3.1 htmlwidgets_1.3 [52] rlang_0.3.4 TTR_0.23-4 rstudioapi_0.10 [55] quantmod_0.4-14 MLmetrics_1.1.1 zoo_1.8-5 [58] zip_2.0.1 acepack_1.4.1 dplyr_0.8.0.1 [61] car_3.0-2 magrittr_1.5 Formula_1.2-3 [64] Matrix_1.2-17 Rcpp_1.0.1 munsell_0.5.0 [67] abind_1.4-5 stringi_1.4.3 forecast_8.6 [70] yaml_2.2.0 carData_3.0-2 MASS_7.3-51.3 [73] pkgbuild_1.0.3 plyr_1.8.4 grid_3.6.1 [76] parallel_3.6.1 forcats_0.4.0 crayon_1.3.4 [79] lattice_0.20-38 haven_2.1.0 splines_3.6.1 [82] hms_0.4.2 knitr_1.22 ps_1.3.0 [85] pillar_1.4.0 pkgload_1.0.2 urca_1.3-0 [88] glue_1.3.1 lsei_1.2-0 babynames_1.0.0 [91] latticeExtra_0.6-28 data.table_1.12.2 remotes_2.0.4 [94] cellranger_1.1.0 testthat_2.1.0 gtable_0.3.0 [97] purrr_0.3.2 assertthat_0.2.1 ggplot2_3.1.1 [100] openxlsx_4.1.0 xfun_0.6 survey_3.35-1 [103] survival_2.44-1.1 timeDate_3043.102 tibble_2.1.1 [106] memoise_1.1.0 cluster_2.0.8 toOrdinal_1.1-0.0 [109] fitdistrplus_1.0-14 brew_1.0-6 However, even when I load almost all of those, I don't see the problem. I've got the same R version, and a newer Rstudio version (mine is 1.2.1335 on a Mac). I couldn't load ] "latticeExtradata.table" and "fitdistrplusbrew", and I didn't check my package versions against yours. I'd suspect the issue is with RStudio somehow, because it needs to do a lot to maintain its environment view. Do you see this when running R from the command line? Duncan Murdoch It's a RStudio thing. Tested with Rscript --vanilla test.R the result is the expected one. (test.R has the obvious contents.) Rui Barradas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inconsistent behaviour of c(...)
Hello, A way to see this is with ?class # OP's code typeof(c(1,"2")) # "character" d.f <- data.frame(C=c(1,"2")) typeof(d.f$C)# "integer" # And check the objects' classes class(c(1,"2")) # "character" class(d.f$C)# "factor" Hope this helps, Rui Barradas Às 08:19 de 19/07/19, Peter Langfelder escreveu: I think your character vector got converted to a factor. See ?options, section stringsAsFactors: ‘stringsAsFactors’: The default setting for arguments of ‘data.frame’ and ‘read.table’. The default is TRUE, so strings get converted to factors when building data frames. Set options(stringsAsFactors=FALSE) and try again. Peter On Fri, Jul 19, 2019 at 12:15 AM Michael Meyer via R-devel wrote: Greetings, Running R 3.5.0 under Windows 7 typeof(c(1,"2")) yields "character" as expected. But in d.f <- data.frame(C=c(1,"2")) typeof(d.f$C) yields "integer". Is this a bug? Michael Meyer __ 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] inconsistent behaviour of c(...)
I forgot there is also ?mode. mode(c(1,"2")) # "character" mode(d.f$C)# "numeric" (not "integer") Rui Barradas Às 11:54 de 19/07/19, Rui Barradas escreveu: Hello, A way to see this is with ?class # OP's code typeof(c(1,"2")) # "character" d.f <- data.frame(C=c(1,"2")) typeof(d.f$C) # "integer" # And check the objects' classes class(c(1,"2")) # "character" class(d.f$C) # "factor" Hope this helps, Rui Barradas Às 08:19 de 19/07/19, Peter Langfelder escreveu: I think your character vector got converted to a factor. See ?options, section stringsAsFactors: ‘stringsAsFactors’: The default setting for arguments of ‘data.frame’ and ‘read.table’. The default is TRUE, so strings get converted to factors when building data frames. Set options(stringsAsFactors=FALSE) and try again. Peter On Fri, Jul 19, 2019 at 12:15 AM Michael Meyer via R-devel wrote: Greetings, Running R 3.5.0 under Windows 7 typeof(c(1,"2")) yields "character" as expected. But in d.f <- data.frame(C=c(1,"2")) typeof(d.f$C) yields "integer". Is this a bug? Michael Meyer __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] should base R have a piping operator ?
Hello,
R is a functional language, pipes are not. There are even higher order
functions such as [1] and [2].
Besides, packages are part of R, R couldn't live without them. I find
pipes a good idea but I also find it better not to have them as part of
base R. If you want to use them, load a package, if you don't, don't.
This simple.
As for your example, compose, there is a StackOverflow question on it.
See this answer [3].
[1] https://stat.ethz.ch/R-manual/R-devel/library/base/html/funprog.html
[2] https://stat.ethz.ch/R-manual/R-devel/library/base/html/Recall.html
[3] https://stackoverflow.com/a/52465956/8245406
Hope this helps,
Rui Barradas
Às 16:48 de 05/10/19, Ant F escreveu:
Hi John,
Thanks, but the Bizzaro pipe comes with many flaws though :
* It's not a single operator
* It has a different precedence
* It cannot be used in a subcall
* The variable assigned to must be on the right
* It doesn't trigger indentation when going to the line
* It creates/overwrite a `.` variable in the worksace.
And it doesn't deal gracefully with some lazy evaluation edge cases such as
:
compose <- function(f, g) { function(x) g(f(x)) }
plus1 <- function(x) x + 1
plus2 <- plus1 %.% compose(.,plus1)
plus2(5)
#> [1] 7
plus1 ->.; compose(.,plus1) -> .; . -> plus2
plus2(5)
#> Error: C stack usage 15923776 is too close to the limit
What I propose on the other hand can always substitute any existing proper
pipe in their standard feature, as long as the dot is made explicit.
Best regards,
Antoine
Le sam. 5 oct. 2019 à 16:59, John Mount a écrit :
Actually, base R already has a pipe fairly close to the one you describe:
->.;
iris ->.; head(.) ->.; dim(.)
# [1] 6 5
I've called it the Bizarro pipe (
http://www.win-vector.com/blog/2016/12/magrittrs-doppelganger/ ), and for
some reason we chickened out and didn't spend time on it in the dot pipe
paper ( https://journal.r-project.org/archive/2018/RJ-2018-042/index.html
).
For documentation Bizarro pipe has the advantage that one can work out how
it works from the application itself, with out reference to a defining
function.
On Oct 5, 2019, at 7:34 AM, Ant F wrote:
Dear R-devel,
The most popular piping operator sits in the package `magrittr` and is used
by a huge amount of users, and imported /reexported by more and more
packages too.
Many workflows don't even make much sense without pipes nowadays, so the
examples in the doc will use pipes, as do the README, vignettes etc. I
believe base R could have a piping operator so packages can use a pipe in
their code or doc and stay dependency free.
I don't suggest an operator based on complex heuristics, instead I suggest
a very simple and fast one (>10 times than magrittr in my tests) :
`%.%` <- function (e1, e2) {
eval(substitute(e2), envir = list(. = e1), enclos = parent.frame())
}
iris %.% head(.) %.% dim(.)
#> [1] 6 5
The difference with magrittr is that the dots must all be explicit (which
sits with the choice of the name), and that special magrittr features such
as assignment in place and building functions with `. %>% head() %>% dim()`
are not supported.
Edge cases are not surprising:
```
x <- "a"
x %.% quote(.)
#> .
x %.% substitute(.)
#> [1] "a"
f1 <- function(y) function() eval(quote(y))
f2 <- x %.% f1(.)
f2()
#> [1] "a"
```
Looking forward for your thoughts on this,
Antoine
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
---
John Mount
http://www.win-vector.com/
Our book: Practical Data Science with R
https://www.manning.com/books/practical-data-science-with-r-second-edition
<http://www.manning.com/zumel/>
[[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] Stroring and extracting AICs from an ARIMA model using a nested loop
Hello,
You can solve the problem in two different ways.
1. Redefine storage1 as a matrix and extract the aic *in* the loop.
storage1 <- matrix(0, 4, 4)
for(p in 0:3){
for(q in 0:3){
storage1[p + 1, q + 1] <- arima(etc)$aic
}
}
2. define storage1 as a list.
storage1 <- vector("list", 16)
i <- 0L
for(p in 0:3){
for(q in 0:3){
i <- i + 1L
storage1[[i]] <- arima(etc)
}
}
lapply(storage1, '[[', "aic") # get the aic's.
Maybe sapply is better it will return a vector.
Hope this helps,
Rui Barradas
Às 06:23 de 03/02/20, ismael ismael via R-devel escreveu:
Hello
I am trying to extract AICs from an ARIMA estimation with different
combinations of p & q ( p =0,1,2,3
and q=0,1.2,3). I have tried using the following code unsucessfully. Can
anyone help?
code:
storage1 <- numeric(16)
for (p in 0:3){
for (q in 0:3){
storage1[p] <- arima(x,order=c(p,0,q), method="ML")}
}
storage1$aic
[[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] Stroring and extracting AICs from an ARIMA model using a nested loop
Hello,
Inline.
Às 11:04 de 03/02/20, Martin Maechler escreveu:
ismael ismael via R-devel
on Mon, 3 Feb 2020 04:09:24 -0600 writes:
> It works!!!
> Thank you so much for your help!
and it was an "R help" question which Rui so generously answered.
But this is the R-devel mailing list.
Please do *NOT* misuse it for R-help questions in the future:
These should go to the R-help mailing list instead!
Yes, and I had noticed it but then, after writing down the answer,
forgot to mention it.
Thanks for the warning.
Rui Barradas
Best,
Martin Maechler
>> On Feb 3, 2020, at 3:47 AM, Rui Barradas wrote:
>>
>> Hello,
>>
>> You can solve the problem in two different ways.
>>
>> 1. Redefine storage1 as a matrix and extract the aic *in* the loop.
>>
>> storage1 <- matrix(0, 4, 4)
>> for(p in 0:3){
>> for(q in 0:3){
>> storage1[p + 1, q + 1] <- arima(etc)$aic
>> }
>> }
>>
>>
>> 2. define storage1 as a list.
>>
>> storage1 <- vector("list", 16)
>> i <- 0L
>> for(p in 0:3){
>> for(q in 0:3){
>> i <- i + 1L
>> storage1[[i]] <- arima(etc)
>> }
>> }
>>
>> lapply(storage1, '[[', "aic") # get the aic's.
>>
>> Maybe sapply is better it will return a vector.
>>
>>
>> Hope this helps,
>>
>> Rui Barradas
>>
>>
>>
>>
>> Às 06:23 de 03/02/20, ismael ismael via R-devel escreveu:
>>> Hello
>>> I am trying to extract AICs from an ARIMA estimation with different
>>> combinations of p & q ( p =0,1,2,3
>>> and q=0,1.2,3). I have tried using the following code unsucessfully.
Can
>>> anyone help?
>>> code:
>>> storage1 <- numeric(16)
>>> for (p in 0:3){
>>> for (q in 0:3){
>>> storage1[p] <- arima(x,order=c(p,0,q), method="ML")}
>>> }
>>> storage1$aic
>>> [[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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Stroring and extracting AICs from an ARIMA model using a nested loop
Hello,
Don't worry, we've seen worst questions :).
Inline.
Às 13:20 de 04/02/20, ismael ismael escreveu:
I am now aware that I should not post this type of questions on this
group. However, I would like to have some clarifications related to the
response you've already provided. The code you provided yields accurate
results, however I still have issues grasping the loop process in case 1
& 2.
In case 1, the use of "p+1" and "q+1" is still blurry to me?
1. R indexes starting from 1, both your orders p and q are 0:3. So to
assign the results to the results matrix, add 1 and get indices 1:4.
You could also set the row and column names after, to make it more clear:
dimnames(storage1) <- list(paste0("p", 0:3), paste0("q", 0:3))
2. 0L is an integer, just 0 is a floating-point corresponding to the C
language double.
class(0L) # "integer"
class(0)# "numeric"
typeof(0L) # "integer"
typeof(0) # "double"
Indices are integers, so I used integers and added 1L every iteration
through the inner loop.
This also means that in point 1. I should have indexed the matrix with p
+ 1L and q + 1L, see the output of
class(0:3)
Hope this helps,
Rui Barradas
Likewise
"0L" and " i + 1L" in case 2.
Can you please provide explanations on the loop mechanisms you've used.
Le lundi 3 février 2020 à 03:47:20 UTC−6, Rui Barradas
a écrit :
Hello,
You can solve the problem in two different ways.
1. Redefine storage1 as a matrix and extract the aic *in* the loop.
storage1 <- matrix(0, 4, 4)
for(p in 0:3){
for(q in 0:3){
storage1[p + 1, q + 1] <- arima(etc)$aic
}
}
2. define storage1 as a list.
storage1 <- vector("list", 16)
i <- 0L
for(p in 0:3){
for(q in 0:3){
i <- i + 1L
storage1[[i]] <- arima(etc)
}
}
lapply(storage1, '[[', "aic") # get the aic's.
Maybe sapply is better it will return a vector.
Hope this helps,
Rui Barradas
Às 06:23 de 03/02/20, ismael ismael via R-devel escreveu:
> Hello
> I am trying to extract AICs from an ARIMA estimation with different
> combinations of p & q ( p =0,1,2,3
> and q=0,1.2,3). I have tried using the following code unsucessfully. Can
> anyone help?
>
> code:
> storage1 <- numeric(16)
> for (p in 0:3){
>
> for (q in 0:3){
>
> storage1[p] <- arima(x,order=c(p,0,q), method="ML")}
> }
> storage1$aic
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org <mailto: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] Why is any() only defined for a numeric and not logical data.frame?
Hello,
As it turns out, this is valid for all generics of the ?Summary group.
From help("Summary"):
Group "Summary":
all, any
sum, prod
min, max
range
methods("Summary") shows that there is a method for df's.
And the code of Summary.data.frame has an explicit test
if (!is.numeric(x) && !is.complex(x))
stop("only defined on a data frame with all numeric variables")
So now the question is even more pertinent (?)(I think):
If sum() is a valid instruction, why only
sum()
sum()
are valid?
Rui Barradas
Às 19:23 de 16/02/20, Karolis Koncevičius escreveu:
Hello,
I recently stumbled on an unusual behaviour of any() and all() and have
been adviced from StackOverflow to share it here [1].
df1 <- data.frame(A=TRUE, B=FALSE)
df2 <- data.frame(A=1, B=0)
> any(df1)
Error in FUN(X[[i]], ...):
only defined on a data frame with all numeric variables
> any(df2)
[1] TRUE
Warning message: In any(c(1, 2), na.rm = FALSE):
coercing argument of type 'double' to logical
Same results happen when using all()
So the any() and all() do not work on data frames with logical values,
but work if the values are numeric.
This doesn't seem to be a bug because error correctly states that any()
will only work on an all-numeric data.frame. However the behaviour
doesn't seem intentional and I cannot come up with any reason for it
behaving this way.
Maybe any() and all() need to be modified to not work on data.frames()
at all, which would also be consistent with is.nan() ?
[1]:
https://stackoverflow.com/questions/60251847/why-is-any-only-defined-for-a-numeric-and-not-logical-data-frame
__
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] dput()
Hello, FAQ 7.31 See also this StackOverflow post: https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal Hope this helps, Rui Barradas Às 00:08 de 29/02/20, robin hankin escreveu: My interpretation of dput.Rd is that dput() gives an exact ASCII form of the internal representation of an R object. But: rhankin@cuttlefish:~ $ R --version R version 3.6.2 (2019-12-12) -- "Dark and Stormy Night" Copyright (C) 2019 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) [snip] rhankin@cuttlefish:~ $ R --vanilla --quiet x <- sum(dbinom(0:20,20,0.35)) dput(x) 1 x-1 [1] -4.440892e-16 x==1 [1] FALSE So, dput(x) gives 1, but x is not equal to 1. Can anyone advise? __ 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] strange bahaviour of predict.lm
Hello, The problem seems to be that A is a matrix. The following solves the error. # create A and b as in your code then run A <- as.data.frame(A) df1 <- cbind(A, b) reg <- lm(b ~ ., df1) # etc Hope this helps, Rui Barradas Às 04:36 de 17/03/20, Moshe Olshansky via R-devel escreveu: Hello, Below is my code: A <- matrix(rnorm(10*3),ncol=3) b <- runif(10) reg <- lm(b ~ A) A1 <- matrix(rnorm(5*3),ncol=3) A1 <- as.data.frame(A1) b1 <- predict(reg,A1) Warning message: 'newdata' had 5 rows but variables found have 10 rows And instead of being an array of length 5, b1 is of length 10 and is identical to reg$fitted.values I think that it should not be like this. Let me note that for lm I do not care about this as much since I can use reg$coefficients, but unfortunately this behaviour is "inherited" by other methods. When I am trying to fit a regression tree, predicting from the object without using 'predict' method is less trivial. Thank you,Moshe. P.S. just in case:> sessionInfo() R version 3.6.2 (2019-12-12) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Linux Mint 19.1 Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 locale: [1] C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.6.2 tools_3.6.2 [[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] strange bahaviour of predict.lm
Hello, I'm glad that it worked. Two things: 1. Please, click reply all to keep this threaded. 2. The question should have belonged to r-h...@r-project.org, not to r-devel@r-project.org. Rui Barradas Às 07:10 de 17/03/20, Moshe Olshansky escreveu: It works, thank you! On Tuesday, 17 March 2020, 5:47:05 pm AEDT, Rui Barradas wrote: Hello, The problem seems to be that A is a matrix. The following solves the error. # create A and b as in your code then run A <- as.data.frame(A) df1 <- cbind(A, b) reg <- lm(b ~ ., df1) # etc Hope this helps, Rui Barradas Às 04:36 de 17/03/20, Moshe Olshansky via R-devel escreveu: > Hello, > Below is my code: >> A <- matrix(rnorm(10*3),ncol=3) >> b <- runif(10) >> reg <- lm(b ~ A) >> A1 <- matrix(rnorm(5*3),ncol=3) >> A1 <- as.data.frame(A1) >> b1 <- predict(reg,A1) > Warning message: > 'newdata' had 5 rows but variables found have 10 rows > > And instead of being an array of length 5, b1 is of length 10 and is identical to reg$fitted.values > I think that it should not be like this. > Let me note that for lm I do not care about this as much since I can use reg$coefficients, but unfortunately this behaviour is "inherited" by other methods. When I am trying to fit a regression tree, predicting from the object without using 'predict' method is less trivial. > Thank you,Moshe. > P.S. just in case:> sessionInfo() > R version 3.6.2 (2019-12-12) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Linux Mint 19.1 > > Matrix products: default > BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 > LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 > > locale: > [1] C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_3.6.2 tools_3.6.2 > > > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org <mailto: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] order function called on a data.frame?
Hello, There is a result with lists? I am getting order(list(letters, 1:26)) #Error in order(list(letters, 1:26)) : # unimplemented type 'list' in 'orderVector1' order(data.frame(letters, 1:26)) # [1] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 #[22] 48 49 50 51 52 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #[43] 17 18 19 20 21 22 23 24 25 26 And I agree that order with data.frames should give a warning. The result is indeed useless: data.frame(letters, 1:26)[order(data.frame(letters, 1:26)), ] Hope this helps, Rui Barradas Às 00:19 de 18/05/20, Jan Gorecki escreveu: Hi, base::order main input arguments are defined as: a sequence of numeric, complex, character or logical vectors, all of the same length, or a classed R object When passing a list or a data.frame, the resuts seems to be a bit useless. Shouldn't that raise an error, or at least warning? Best Regards, Jan Gorecki __ 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] Downloader that Resolves library dependencies
Hello,
Try ?install.packages from within R.
install.packages("car", dependencies = TRUE)
Hope this helps,
Rui Barradas
Em 11-04-2017 12:01, Ulrich Windl escreveu:
Hi!
If you want to install an extra library like "car", there is a long list of dependencies.
If you just download "car", you cannot use it.
Unfortunately the download links offer no solution to select all dependent
libraries for download also. It would be nice, however.
(This is interesting for people that want to use R in an Intranet that does not
have Internet access)
Regards,
Ulrich
__
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] "table(droplevels(aq)$Month)" in manual page of droplevels
Hello, Inline. Em 12-04-2017 16:40, Henric Winell escreveu: (Let's keep the discussion on-list -- I've added back R-devel.) On 2017-04-12 16:39, Ulrich Windl wrote: Henric Winell schrieb am 12.04.2017 um 15:35 in Nachricht : On 2017-04-12 14:40, Ulrich Windl wrote: The last line of the example in droplevels' manual page seems to be incorrect to me. I think it should read: "table(droplevels(aq$Month))". Amazingly (I don't understand) both variants seem to produce the same result (R 3.3.3): --- The manual says that "The function 'droplevels' is used to drop unused levels from a 'factor' or, more commonly, from factors in a data frame." and, as documented, the 'droplevels' generic has methods for objects of class "data.frame" and "factor". So, your being amazed is a bit surprising given that 'aq' is a data frame. The "surprising" thing is the syntax: I was unaware that '$' is a generic operator that can be applied to the result of a function (i.e.: droplevels); I thought it's kind of a special variable syntax. Then your surprise is unrelated to the use of 'droplevels'. Since the 'droplevels' method for objects of class "data.frame" returns a data frame, the extraction operator '$' works directly on the resulting object. So, 'droplevels(aq)$Month' is essentially the same as aq <- droplevels(aq) aq$Month > Isn't there also the syntax ``droplevels(aq)["Month"]''? Sure, and there are even more ways to do subsetting. But this is basic stuff and therefore off-topic for R-devel. Please see the manual (?Extract) or, e.g., Chapter 3 of Hadley Wickham's "Advanced R". But note that droplevels(aq)["Month"] and droplevels(aq)$Month are _not_ the same. The first returns a data.frame (with just one vector), the latter returns a vector. To return just a vector you could also use droplevels(aq)[["Month"]] which is preferable for programming, by the way. The '$' operator should be reserved for interactive use only. Hope this helps, Rui Barradas Henric Winell Regards, Ulrich Henric Winell aq <- transform(airquality, Month = factor(Month, labels = month.abb[5:9])) aq <- subset(aq, Month != "Jul") table(aq$Month) May Jun Jul Aug Sep 31 30 0 31 30 table(droplevels(aq)$Month) May Jun Aug Sep 31 30 31 30 table(droplevels(aq$Month)) May Jun Aug Sep 31 30 31 30 --- For the sake of learners, try to keep the examples simple and useful, even though you experts want to impress the newbees... Ulrich __ 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
[Rd] install.packages problem
Hello,
R 3.4.1 on Windows 7, sessionInfo at the end.
Is there a problem with install.packages? Since last friday every time I
try to install a package in RGui, I start by choosing the CRAN mirror
Cloud-0 and RGui hangs. So I restart RGui and choose Portugal (Lisbon)
and get the following warning after a long while (minutes).
install.packages("igraph")
--- Please select a CRAN mirror for use in this session ---
Warning: unable to access index for repository
http://www.stats.ox.ac.uk/pub/RWin/src/contrib:
cannot open URL 'http://www.stats.ox.ac.uk/pub/RWin/src/contrib/PACKAGES'
Warning: unable to access index for repository
http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4:
cannot open URL
'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4/PACKAGES'
There is a binary version available but the source version is later:
binary source needs_compilation
igraph 1.0.1 1.1.1 TRUE
Do you want to install from sources the package which needs compilation?
y/n: y
installing the source package ‘igraph’
trying URL 'http://cran.radicaldevelop.com/src/contrib/igraph_1.1.1.tar.gz'
Content type 'application/x-gzip' length 3376077 bytes (3.2 MB)
downloaded 3.2 MB
[...]
The rest of the process goes on with success.
The problem seems to be with http://www.stats.ox.ac.uk/pub/RWin/src/contrib
When I check
> options("repos")
$repos
CRANCRANextra
"http://cran.radicaldevelop.com"; "http://www.stats.ox.ac.uk/pub/RWin";
I'm lead to think that install.packages should try
"http://cran.radicaldevelop.com"; first, only in case of failure CRANextra.
What is going on?
> sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252
LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] igraph_1.0.1
loaded via a namespace (and not attached):
[1] compiler_3.4.1 magrittr_1.5 tools_3.4.1
Thanks in advance,
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install.packages problem on Windows: CRANextras timeout
Hello,
Thanks for the answer.
No, in the end there's no problem, just a warning.
Rui Barradas
Em 17-07-2017 09:29, Martin Maechler escreveu:
Rui Barradas
on Mon, 17 Jul 2017 09:03:33 +0100 writes:
> Hello,
> R 3.4.1 on Windows 7, sessionInfo at the end.
> Is there a problem with install.packages? Since last friday every time I
> try to install a package in RGui, I start by choosing the CRAN mirror
> Cloud-0 and RGui hangs. So I restart RGui and choose Portugal (Lisbon)
> and get the following warning after a long while (minutes).
As (I think) you notice below yourself, the problem is not with
the regular CRAN repos but with the 'CRANextra' repos that
R users of Windows use sometimes.
We had heard offline of a potential timeout/downtime for a short
period at Oxford for that, so this may be the simple explanation.
On the other hand everything ends up working fine,
so all this is just a warning, right?
If I do the same thing I don't have to wait and get the same
warning as you (and when I then decide to use the older *binary*
for igraph that is installed fine).
Martin
> install.packages("igraph")
> --- Please select a CRAN mirror for use in this session ---
> Warning: unable to access index for repository
> http://www.stats.ox.ac.uk/pub/RWin/src/contrib:
> cannot open URL 'http://www.stats.ox.ac.uk/pub/RWin/src/contrib/PACKAGES'
> Warning: unable to access index for repository
> http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4:
> cannot open URL
> 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4/PACKAGES'
> There is a binary version available but the source version is later:
> binary source needs_compilation
> igraph 1.0.1 1.1.1 TRUE
> Do you want to install from sources the package which needs compilation?
> y/n: y
> installing the source package ‘igraph’
> trying URL
'http://cran.radicaldevelop.com/src/contrib/igraph_1.1.1.tar.gz'
> Content type 'application/x-gzip' length 3376077 bytes (3.2 MB)
> downloaded 3.2 MB
> [...]
> The rest of the process goes on with success.
> The problem seems to be with
http://www.stats.ox.ac.uk/pub/RWin/src/contrib
> When I check
>> options("repos")
> $repos
> CRANCRANextra
> "http://cran.radicaldevelop.com"; "http://www.stats.ox.ac.uk/pub/RWin";
> I'm lead to think that install.packages should try
> "http://cran.radicaldevelop.com"; first, only in case of failure
CRANextra.
> What is going on?
>> sessionInfo()
> R version 3.4.1 (2017-06-30)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1
> Matrix products: default
> locale:
> [1] LC_COLLATE=Portuguese_Portugal.1252
> LC_CTYPE=Portuguese_Portugal.1252
> [3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
> [5] LC_TIME=Portuguese_Portugal.1252
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> other attached packages:
> [1] igraph_1.0.1
> loaded via a namespace (and not attached):
> [1] compiler_3.4.1 magrittr_1.5 tools_3.4.1
> Thanks in advance,
> Rui Barradas
> __
> 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] Problem with a regular expression.
Hello,
This seems to be serious.
RGui.exe, fresh session. I've clicked File > New Script and wrote
Oldterm <- c("A", "B", "A", "*", "B")
strsplit(Oldterm, ")" )
Ran each instruction at a time with Ctrl+r and with the strsplit call
the system froze.
Ctrl+Alt+Del didn't work, I had to go for the power switch button.
sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252
LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.4.1
Rui Barradas
Em 16-08-2017 23:31, Chris Triggs escreveu:
Hi...
I have come upon a problem with a regular expression which causes base-R to
freeze. I have reproduced the phenomenon on several machines running R under
Windows 10, and also under OSX on different Apple MACs.
The minimal example is:-
Oldterm is a vector of characters, e.g. "A", "B", "A", "*", "B"
The regular expression is ")"
The call which freezes R is
strsplit(Oldterm, ")" )
Thomas - after he had reproduced the problem - suggested that I submit it to
r-devel.
Best wishes
Chris Triggs
[[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] Unexpected behaviour with download.packages on Windows
Hello,
The help pages for download.packages and install.packages say
'type = getOption("pkgType")'.
And on Windows I get
getOption("pkgType")
[1] "both"
which means in ?getOptions
pkgType:
The default type of packages to be downloaded and installed – see
install.packages. Possible values are "win.binary", "source" and "both"
(the default).
Are you sure the package you're downloading has a binary version or is
it source only?
sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252
LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] Hmisc_4.0-3 Formula_1.2-2survival_2.41-3
[4] lattice_0.20-35 DescTools_0.99.22RecordLinkage_0.4-10
[7] ffbase_0.12.3ff_2.2-13bit_1.1-12
[10] RSQLite_2.0 DBI_0.7 tcR_2.2.1.11
[13] igraph_1.1.2 reshape2_1.4.2 gridExtra_2.2.1
[16] dplyr_0.7.1 ggplot2_2.2.1sos_2.0-0
[19] brew_1.0-6
loaded via a namespace (and not attached):
[1] Rcpp_0.12.11stringdist_0.9.4.6 mvtnorm_1.0-6
[4] class_7.3-14assertthat_0.2.0digest_0.6.12
[7] ipred_0.9-6 R6_2.2.2plyr_1.8.4
[10] backports_1.1.0 acepack_1.4.1 ada_2.0-5
[13] e1071_1.6-8 rlang_0.1.1 lazyeval_0.2.0
[16] data.table_1.10.4 blob_1.1.0 rpart_4.1-11
[19] Matrix_1.2-10 checkmate_1.8.3 splines_3.4.1
[22] stringr_1.2.0 foreign_0.8-69 htmlwidgets_0.9
[25] munsell_0.4.3 compiler_3.4.1 pkgconfig_2.0.1
[28] base64enc_0.1-3 manipulate_1.0.1htmltools_0.3.6
[31] nnet_7.3-12 evd_2.3-2 htmlTable_1.9
[34] tibble_1.3.3prodlim_1.6.1 expm_0.999-2
[37] MASS_7.3-47 grid_3.4.1 xtable_1.8-2
[40] gtable_0.2.0magrittr_1.5scales_0.4.1
[43] stringi_1.1.5 bindrcpp_0.2latticeExtra_0.6-28
[46] boot_1.3-19 fastmatch_1.1-0 lava_1.5.1
[49] RColorBrewer_1.1-2 tools_3.4.1 bit64_0.9-7
[52] glue_1.1.1 parallel_3.4.1 colorspace_1.3-2
[55] cluster_2.0.6 memoise_1.1.0 knitr_1.16
[58] bindr_0.1
Hope this helps,
Rui Barradas
Em 29-09-2017 16:00, Hong Ooi via R-devel escreveu:
If no 'type' is specified, download.packages("pkgname") will download source
packages (.tar.gz files), even on Windows. However, the help says
type character string, indicate which type of packages: see
install.packages.
and on Windows, install.packages defaults to downloading binary packages.
Is this intended behaviour on the part of download.packages? This is on R 3.3.3
and 3.4.1; I haven't tested on 3.4.2 but there's no indication the function has
changed.
__
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] split() - unexpected sorting of results
Hello, In order to solve that problem of sorting numerics made characters there is package stringr, functions str_sort and str_order. library(stringr) set.seed(2447) x <- sample(11L) sort(as.character(x)) [1] "1" "10" "11" "2" "3" "4" "5" "6" "7" "8" "9" str_sort(as.character(x), numeric = TRUE) [1] "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" str_order(as.character(x), numeric = TRUE) #[1] 1 4 11 8 6 5 3 10 9 7 2 i <- str_order(as.character(x), numeric = TRUE) as.character(x)[i] #[1] "1" "2" "3" "4" "5" "6" "7" "8" "9" "10" "11" Unfortunately this does not solve the OP's question, factor(), as.factor(), split() and others use the base R sorter and this can only be changed by changing their sources. Hope this helps, Rui Barradas Em 21-10-2017 00:32, Hervé Pagès escreveu: Hi, On 10/20/2017 12:53 PM, Peter Meissner wrote: Thanks, for the explanation. Still, I think this is surprising bahaviour which might be handled better. Maybe a little surprising, but no more than: > x <- sample(11L) > sort(x) [1] 1 2 3 4 5 6 7 8 9 10 11 > sort(as.character(x)) [1] "1" "10" "11" "2" "3" "4" "5" "6" "7" "8" "9" The fact that sort(), as.factor(), split() and many other things behave consistently with respect to the underlying order of character vectors avoids other even bigger surprises. Also note that the underlying order of character vectors actually depends on your locale. One way to guarantee consistent results across platforms/locales is by explicitly specifying the levels when making a factor e.g. f <- factor(x, levels=unique(x)) split(1:11, f) This is particularly sensible when writing unit tests. Cheers, H. Best, Peter Am 20.10.2017 9:49 nachm. schrieb "Iñaki Úcar" : Hi Peter, 2017-10-20 21:33 GMT+02:00 Peter Meissner : Hey, I found this - for me - quite surprising and puzzling behaviour of split(). split(1:11, as.character(1:11)) split(1:11, 1:11) When splitting by numerics everything works as expected - sorting of input == sorting of output -- but when using a character vector everything gets re-sorted alphabetical. Although, there are some references in the help files to what happens when using split, I did not find any note on this - for me - rather unexpected behaviour. As the documentation states, f: a ‘factor’ in the sense that ‘as.factor(f)’ defines the grouping, or a list of such factors in which case their interaction is used for the grouping. And, in fact, as.factor(1:11) [1] 1 2 3 4 5 6 7 8 9 10 11 Levels: 1 2 3 4 5 6 7 8 9 10 11 as.factor(as.character(1:11)) [1] 1 2 3 4 5 6 7 8 9 10 11 Levels: 1 10 11 2 3 4 5 6 7 8 9 Regards, Iñaki I would like it best when the sorting of split results stays the same no matter the input (sorting of input == sorting of output) If that is not possibly a note of caution in the help pages and maybe an example might be valuable. Best, Peter [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=o5-lZT7zAjFNU8C0Z9D7XaQO_2NGmhKF-IbGZFhSvO0&s=4cZ9rSLJAVnnjULGMCDPAclXHoc9_le3Z1DrZg0nQqg&e= [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=o5-lZT7zAjFNU8C0Z9D7XaQO_2NGmhKF-IbGZFhSvO0&s=4cZ9rSLJAVnnjULGMCDPAclXHoc9_le3Z1DrZg0nQqg&e= __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typos in file.path documentation.
Hello, R 4.0.2 on Ubuntu 20.04, sessionInfo() below. I believe there are two typos in ?file.path, section Value, 2nd paragraph. 1. There is a close parenthesis missing after Encoding, as it is reading is a bit confusing, I had to backtrack and repeat. 2. I'm not a native language speaker but before a consonant it's 'a', not 'an', right? an component should be a component Current: An element of the result will be marked (see Encoding as UTF-8 if run in a UTF-8 locale (when marked inputs are converted to UTF-8) or if an component of the result is marked as UTF-8, or as Latin-1 in a non-Latin-1 locale. Should be: An element of the result will be marked (see Encoding) as UTF-8 if run in a UTF-8 locale (when marked inputs are converted to UTF-8) or if a component of the result is marked as UTF-8, or as Latin-1 in a non-Latin-1 locale. sessionInfo() R version 4.0.2 (2020-06-22) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 20.04.1 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0 locale: [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8 [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8 [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.2 Hope this helps, Rui Barradas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] more Matrix weirdness
Hello,
R 4.0.2 on Ubuntu 20.04, sessionInfo() below.
I can reproduce this, sort of. The error I'm getting is different:
x[rr, cc] <- m
#Error in x[rr, cc] <- m : replacement has length zero
But if I check lengths and dimensions, they are identical().
identical(length(x[rr, cc]), length(m))
#[1] TRUE
identical(dim(x[rr, cc]), dim(m))
#[1] TRUE
What works is
x[rr, cc] <- as.matrix(m)
I ran Ben's code on RStudio 1.3.1073, the following is run with Rscript
and the error message is the same.
rui@rui:~$ Rscript --vanilla rhelp.R
R version 4.0.2 (2020-06-22)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] Matrix_1.2-18
loaded via a namespace (and not attached):
[1] compiler_4.0.2 grid_4.0.2 lattice_0.20-41
Error in x[rr, cc] <- m :
number of items to replace is not a multiple of replacement length
Execution halted
Hope this helps,
Rui Barradas
Às 03:04 de 09/09/20, Ben Bolker escreveu:
Am I being too optimistic in expecting this (mixing and matching
matrices and Matrices) to work? If x is a matrix and m is a Matrix,
replacing a commensurately sized sub-matrix of x with m throws "number
of items to replace is not a multiple of replacement length" ...
x <- matrix(0,nrow=3,ncol=10, dimnames=list(letters[1:3],LETTERS[1:10]))
rr <- c("a","b","c")
cc <- c("B","C","E")
m <- Matrix(matrix(1:9,3,3))
x[rr,cc] <- m
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
Re: [Rd] [R] jitter-bug? problematic behaviour of the jitter function
Hello, R 4.0.2 on Ubuntu 20.04, sessionInfo at end. This came up in r-help, I'm answering to the OP and also posting to r-devel since I believe it is more appropriate there. I can confirm this. The original instructions are the first and the last, but even with smaller numbers the error shows up. set.seed(2020) jitter(c(1,2,10^4)) # desired behaviour #[1] 1.058761 1.957690 1.047401 jitter(c(0,1,10^4)) # bad behaviour #[1] -92.43546 -1454.61126 8269.53754 jitter(c(-1,0,10^4)) # bad behaviour #[1] -1484.3895 -427.5283 8010.3308 jitter(c(1,2,10^5)) # bad behaviour #[1] 4809.238 10578.561 109753.430 To the OP: I am cc-ing this to r-devel@r-project.org. Questions like this are about R itself and should be posted there. sessionInfo() R version 4.0.2 (2020-06-22) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 20.04.1 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0 locale: [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8 [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8 [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.2 Hope this helps, Rui Barradas Às 11:32 de 23/09/20, Martin Keller-Ressel escreveu: Dear all, i have noticed some strange behaviour in the „jitter“ function in R. On the help page for jitter it is stated that "The result, say r, is r <- x + runif(n, -a, a) where n <- length(x) and a is the amount argument (if specified).“ and "If amount is NULL (default), we set a <- factor * d/5 where d is the smallest difference between adjacent unique (apart from fuzz) x values.“ This works fine as long as there is no (very) large outlier jitter(c(1,2,10^4)) # desired behaviour [1]1.0832431.851571 .942716 But for very large outliers the added noise suddenly ‚jumps‘ to a much larger scale: jitter(c(1,2,10^5)) # bad behaviour [1] -19535.649 9578.702 115693.854 # Noise should be of order (2-1)/5 = 0.2 but is of much larger order. This probably does not matter much when jitter is used for plotting, but it can cause problems when jitter is used to break ties. best regards, Martin Martin Keller-Ressel Professor für Stochastische Analysis und Finanzmathematik Technische Universität Dresden Institut für Mathematische Stochastik Willersbau B 316, Zellescher Weg 12-14 01062 Dresden [[alternative HTML version deleted]] __ r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Data Table not rendering properly using R shiny
Hello,
Or maybe
logical_idx <- max_usage_hours_per_region$Region %in% input$Region
Another option is ?match
Hope this helps,
Rui Barradas
Às 15:41 de 07/11/20, Jeff Newmiller escreveu:
This looks odd...
max_usage_hours_per_region[input$Region,]
This would only work if you had rownames on that data frame corresponding to
the names of the Regions. This is a common R mistake... you probably need
logical_idx <- max_usage_hours_per_region$Region == input$Region
max_usage_hours_per_region[ logical_idx,]
That said, it is very difficult to separate out R questions when mixed into
shiny code, so you would help yourself and this list to work on minimal
reproducible examples that focus on the R syntax if possible for posts here.
Read the Posting Guide.
On November 7, 2020 2:42:58 AM PST, Ritwik Mohapatra wrote:
Hi All,
I have a data output as below.I want to display them in an interactive
html
report using shiny but the data table is not rendering properly and
instead
giving NA values.
max_usage_hours_per_region<-setNames(aggregate(df3_machine_region$sum_as_hours~df3_machine_region$Region,df3_machine_region,max),c("Region","Sum_as_Hours"))
Region Sum_as_Hours
1 Africa 1156.0833
2 Americas 740.1667
3 APAC 740.2833
4 Europe 1895.2000
5 PDO 1053.3500
6 UK 0.
Rshiny code:
library(shiny)
ui <- fluidPage(
selectInput("Region","Select
Region",max_usage_hours_per_region$Region,selected = TRUE),
tableOutput("table")
)
server <- function(input, output) {
output$table <- renderTable(
max_usage_hours_per_region[input$Region,])
}
shinyApp(ui = ui, server = server)
[[alternative HTML version deleted]]
__
r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
Hello, If Hilbert liked beer, I like "pipe". More seriously, a new addition like this one is going to cause problems yet unknown. But it's a good idea to have a pipe operator available. As someone used to magrittr's data pipelines, I will play with this base one before making up my mind. I don't expect its behavior to be exactly like magrittr "%>%" (and it's not). For the moment all I can say is that it is something R users are used to and that it now avoids loading a package. As for the new way to define anonymous functions, I am less sure. Too much syntatic sugar? Or am I finding the syntax ugly? Hope this helps, Rui Barradas Às 03:22 de 06/12/20, Gregory Warnes escreveu: If we’re being mathematically pedantic, the “pipe” operator is actually function composition > That being said, pipes are a simple and well-known idiom. While being less than mathematically exact, it seems a reasonable label for the (very useful) behavior. On Sat, Dec 5, 2020 at 9:43 PM Abby Spurdle wrote: This is a good addition I can't understand why so many people are calling this a "pipe". Pipes connect processes, via their I/O streams. Arguably, a more general interpretation would include sockets and files. https://en.wikipedia.org/wiki/Pipeline_(Unix) https://en.wikipedia.org/wiki/Named_pipe https://en.wikipedia.org/wiki/Anonymous_pipe As far as I can tell, the magrittr-like operators are functions (not pipes), with nonstandard syntax. This is not consistent with R's original design philosophy, building on C, Lisp and S, along with lots of *important* math and stats. It's possible that some parties are interested in creating a kind of "data pipeline". I'm interested in this myself, and I think we could discuss this more. But I'm not convinced the magrittr-like operators help to achieve this goal. Which, in my opinion, would require one to model programs as directed graphs, along with some degree of asynchronous input. Presumably, these operators will be added to R anyway, and (almost) no one will listen to me. So, I would like to make one suggestion: Is it possible for these operators to *not* be named: The R Pipe The S Pipe Or anything with a similar meaning. Maybe tidy pipe, or something else that links it to its proponents? __ 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
[Rd] Small bug in the documentation of `[.data.frame`
Hello, R 4.0.3 on Ubuntu 20.10, session info at end. Isn't the default value of argument drop missing in ?`[.data.frame` Usage: ## S3 method for class 'data.frame' x[i, j, drop = ] I had the impression that it was TRUE (it is when running the function, I'm talking about the docs). sessionInfo() R version 4.0.3 (2020-10-10) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 20.04.1 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0 locale: [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8 [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8 [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.3 tools_4.0.3 Happy holidays, Rui Barradas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Small bug in the documentation of `[.data.frame`
Hello, Thank you both, Duncan and Martin, for the quick and clear answer. I hadn't considered printing `[.data.frame`, which is in fact very useful, but I had read the Arguments section. What I didn't realize was that it was the answer to the question. Sorry for the noise. Rui Barradas Às 13:51 de 29/12/20, Martin Maechler escreveu: Duncan Murdoch on Tue, 29 Dec 2020 08:37:51 -0500 writes: > On 29/12/2020 8:29 a.m., Rui Barradas wrote: >> Hello, >> >> R 4.0.3 on Ubuntu 20.10, session info at end. >> >> Isn't the default value of argument drop missing in >> >> ?`[.data.frame` >> >> Usage: >> >> ## S3 method for class 'data.frame' >> x[i, j, drop = ] >> >> >> I had the impression that it was TRUE (it is when running the function, >> I'm talking about the docs). > No, you can see it if you print `[.data.frame`: >> `[.data.frame` > function (x, i, j, drop = if (missing(i)) TRUE else length(cols) == > 1) > So if you ask for specific rows and your dataframe has more than one > column, it defaults to FALSE. > I think the Rd checks allow you to leave out defaults, but don't allow > you to state them incorrectly, so that's probably why it is left as > blank in the Usage section, and explained in the Arguments section. > Duncan Murdoch Yes, indeed, Duncan, it is as you think (above). It is "official" in the sense that we've used this for a long time in order to keep the 'Usage' section cleaner, when some defaults are sophisticated, and a help page reader should rather read the corresponding argument description. Martin >> sessionInfo() >> R version 4.0.3 (2020-10-10) >> Platform: x86_64-pc-linux-gnu (64-bit) >> Running under: Ubuntu 20.04.1 LTS >> >> Matrix products: default >> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 >> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0 >> >> locale: >> [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C >> [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8 >> [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8 >> [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C >> [9] LC_ADDRESS=C LC_TELEPHONE=C >> [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> loaded via a namespace (and not attached): >> [1] compiler_4.0.3 tools_4.0.3 >> >> >> Happy holidays, >> >> Rui Barradas >> >> __ >> 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
[Rd] Unexpected behavior of '[' in an apply instruction
Hello, This came up in this StackOverflow post [1]. If x is an array with n dimensions, how to subset by just one dimension? If n is known, it's simple, add the required number of commas in their proper places. But what if the user doesn't know the value of n? The example below has n = 3, and subsets by the 1st dim. The apply loop solves the problem as expected but note that the index i has length(i) > 1. x <- array(1:60, dim = c(10, 2, 3)) d <- 1L i <- 1:5 apply(x, MARGIN = -d, '[', i) x[i, , ] If length(i) == 1, argument drop = FALSE doesn't work as I expected it to work, only the other way does: i <- 1L apply(x, MARGIN = -d, '[', i, drop = FALSE) x[i, , drop = FALSE] What am I missing? [1] https://stackoverflow.com/questions/66168564/is-there-a-native-r-syntax-to-extract-rows-of-an-array Thanks in advance, Rui Barradas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected behavior of '[' in an apply instruction
Hello, Yes, although there is an accepted solution, I believe you should post this solution there. It's a base R solution, what the question asks for. And thanks, I would have never reminded myself of slice.index. Rui Barradas Às 20:45 de 12/02/21, robin hankin escreveu: Rui > x <- array(runif(60), dim = c(10, 2, 3)) > array(x[slice.index(x,1) %in% 1:5],c(5,dim(x)[-1])) (I don't see this on stackoverflow; should I post this there too?) Most of the magic package is devoted to handling arrays of arbitrary dimensions and this functionality might be good to include if anyone would find it useful. HTH Robin <mailto:hankin.ro...@gmail.com> On Sat, Feb 13, 2021 at 12:26 AM Rui Barradas <mailto:ruipbarra...@sapo.pt>> wrote: Hello, This came up in this StackOverflow post [1]. If x is an array with n dimensions, how to subset by just one dimension? If n is known, it's simple, add the required number of commas in their proper places. But what if the user doesn't know the value of n? The example below has n = 3, and subsets by the 1st dim. The apply loop solves the problem as expected but note that the index i has length(i) > 1. x <- array(1:60, dim = c(10, 2, 3)) d <- 1L i <- 1:5 apply(x, MARGIN = -d, '[', i) x[i, , ] If length(i) == 1, argument drop = FALSE doesn't work as I expected it to work, only the other way does: i <- 1L apply(x, MARGIN = -d, '[', i, drop = FALSE) x[i, , drop = FALSE] What am I missing? [1] https://stackoverflow.com/questions/66168564/is-there-a-native-r-syntax-to-extract-rows-of-an-array Thanks in advance, Rui Barradas __ R-devel@r-project.org <mailto: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
[Rd] Trivial typo in help("browser")
Hello,
R 4.1.0 on Ubuntu 20.04, session info below.
I am not an English native speaker but in help("browser"), section
Arguments, argument expr, there is a wrong verb tense:
"invoked" should be "invoke", right?
expr
An expression, which if it evaluates to TRUE the debugger will invoked,
otherwise control is returned directly.
sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.2 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.0
Thanks to all R Core Team members for their great work for all of us.
Hope this helps,
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trivial typo in help("browser")
Hello,
Thanks, you are absolutely right. I had noticed that last night and then
I din't know what happened but it went like that.
Thanks for the correction.
Rui Barradas
Às 07:59 de 29/07/21, Peter Langfelder escreveu:
I'm also not a native speaker but my take is that a "be" is missing in
the sentence and it should read
An expression, which if it evaluates to TRUE the debugger will be invoked,
otherwise control is returned directly.
On Wed, Jul 28, 2021 at 11:52 PM Rui Barradas wrote:
Hello,
R 4.1.0 on Ubuntu 20.04, session info below.
I am not an English native speaker but in help("browser"), section
Arguments, argument expr, there is a wrong verb tense:
"invoked" should be "invoke", right?
expr
An expression, which if it evaluates to TRUE the debugger will invoked,
otherwise control is returned directly.
sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.2 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.0
Thanks to all R Core Team members for their great work for all of us.
Hope this helps,
Rui Barradas
__
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] Trivial typo in help("browser")
Hello,
Double thanks, for the correction and for the lesson.
In particular, I had never noticed the f2() example's behavior.
It's always good to learn something new.
Rui Barradas
Às 08:57 de 29/07/21, Martin Maechler escreveu:
Rui Barradas
on Thu, 29 Jul 2021 07:52:02 +0100 writes:
> Hello,
> R 4.1.0 on Ubuntu 20.04, session info below.
> I am not an English native speaker but in help("browser"),
> section Arguments, argument expr, there is a wrong verb
> tense:
> "invoked" should be "invoke", right?
> expr An expression, which if it evaluates to TRUE the
> debugger will invoked, otherwise control is returned
> directly.
> sessionInfo() R version 4.1.0 .
Thank you, Rui. Indeed, there's a typo there.
I claim that it is a missing 'be': "be invoked" almost surealy
was intended.
As we are on the R-devel mailing list, however, let's dig and learn a bit more:
Note that the *default* is `expr = TRUE`
which is already a bit "special" for an "expression"..
Let's try to understand what was meant --- NB a strategy I
strongly recommend even if you're somewhat experienced :
ff <- function(x) { y <- x^2; browser("in ff():", expr = (y == 4)); y }
ff(1)
[1] 1
ff(2)
Called from: ff(2)
Browse[1]> debug at #1: y
Browse[2]> ls.str()
x : num 2
y : num 4
Browse[2]> c
[1] 4
ff(3)
[1] 9
So indeed, it does behave as I expected.
A further experiment, play with
f2 <- function(x, e=1) { y <- x^2; browser("in ff():", expr = e); y }
shows that 'evaluates to TRUE' is also
not as precise as it could be, and even "wrong":
'expr = pi' also behaves as TRUE, and even
'expr = NA' behaves the same.
I don't know when/how `expr` was introduced (probably taken
from 'S / S+' ..), but to me it seems actually somewhat a
misnomer because in that generalized sense, *every*
argument passed to an R function is an "expression".
Instead, what counts is that a low-level as.logical(expr) is not TRUE.
So, yes, the documentation about `expr` definitely needs to be
changed.
Unless I get convincing suggestions for improvements, I'll commit
\item{expr}{a \dQuote{condition}. By default, and whenever not false
after being coerced to \code{\link{logical}}, the debugger will be
invoked, otherwise control is returned directly.}
(and also amend the formulation a bit later on the help page
where expr is mentioned again).
Martin
> Thanks to all R Core Team members for their great work for
> all of us.
> Hope this helps,
> Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Crash/bug when calling match on latin1 strings
Hello,
R 4.1.1 on Ubuntu 20.04.
I can reproduce this error but not ~90% of the time, only the 1st time I
run the script.
If I run other (terminal) commands before rerunning the R script it
sometimes segfaults again but once again very far from 90% of the time.
rui@rui:~/tmp$ R -q -f rhelp.R
> sessionInfo()
R version 4.1.1 (2021-08-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.3 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.1
>
> # A bunch of words in UTF8; replace *'s
> words <- readLines("h://pastebin.c**/raw/MFCQfhpY", encoding =
"UTF-8")
> words2 <- iconv(words, "utf-8", "latin1")
> gctorture(TRUE)
> y <- match(words2, words2)
*** caught segfault ***
address 0x10, cause 'memory not mapped'
*** recursive gc invocation
*** recursive gc invocation
*** recursive gc invocation
*** recursive gc invocation
*** recursive gc invocation
*** recursive gc invocation
*** recursive gc invocation
*** recursive gc invocation
*** recursive gc invocation
*** recursive gc invocation
Traceback:
1: match(words2, words2)
An irrecoverable exception occurred. R is aborting now ...
Falta de segmentação (núcleo despejado)
This last line is Portuguese for
Segmentation fault (core dumped)
Hope this helps,
Rui Barradas
Às 06:05 de 11/10/21, Travers Ching escreveu:
Here's a brief example:
# A bunch of words in UTF8; replace *'s
words <- readLines("h://pastebin.c**/raw/MFCQfhpY", encoding = "UTF-8")
words2 <- iconv(words, "utf-8", "latin1")
gctorture(TRUE)
y <- match(words2, words2)
I searched bugzilla but didn't see anything. Apologies if this is already
reported.
The bug appears in both R-devel and the release, but doesn't seem to affect
R 4.0.5.
[[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] capturing multiple warnings in tryCatch()
Hello,
I remembered having seen a function tryCatch.W.E and after an online
search, found where.
It was in a R-Help post and in demo(error.catching). The question by
Marius Hofert [1] was answered, among others, by Martin Maechler [2]
which included the function tryCatch.W.E.
These posts refer to an old thread dated 2004 [3], with an answer by
Luke Tierney [4]. The function withWarnings posted by Luke returns all
warning messages in a list, as seen below.
I repost the function to have this self contained.
withWarnings <- function (expr) {
warnings <- character()
retval <- withCallingHandlers(expr, warning = function(ex) {
warnings <<- c(warnings, conditionMessage(ex))
invokeRestart("muffleWarning")
})
list(Value = retval, Warnings = warnings)
}
withWarnings(foo())
#$Value
#[1] "warning 2"
#
#$Warnings
#[1] "warning 1" "warning 2"
Function tryCatch.W.E is now part of contributed package simsalapar [5],
with credits to Marius and Martin given in its documentation.
[1] https://stat.ethz.ch/pipermail/r-help/2010-December/262185.html
[2] https://stat.ethz.ch/pipermail/r-help/2010-December/262626.html
[3] https://stat.ethz.ch/pipermail/r-help/2004-June/052092.html
[4] https://stat.ethz.ch/pipermail/r-help/2004-June/052132.html
[5] https://CRAN.R-project.org/package=simsalapar
Hope this helps,
Rui Barradas
Às 22:37 de 02/12/21, Fox, John escreveu:
Dear Henrik, Simon, and Adrian,
As it turns out Adrian's admisc::tryCatchWEM() *almost* does what I want, which
is both to capture all messages and the result of the expression (rather than
the visible representation of the result). I was easily able to modify
tryCatchWEM() to return the result.
Henrik: I was aware that tryCatch() doesn't return the final result of the
expression, and I was previously re-executing the expression to capture the
reult, but only getting the first warning message, along with the result.
Thanks for responding to my question and providing viable solutions,
John
On 2021-12-02, 5:19 PM, "Henrik Bengtsson" wrote:
Simon's suggestion with withCallingHandlers() is the correct way.
Also, note that if you use tryCatch() to catch warnings, you're
*interrupting* the evaluation of the expression of interest, e.g.
> res <- tryCatch({ message("hey"); warning("boom"); message("there"); 42 }, warning
= function(w) { message("Warning caught: ", conditionMessage(w)); 3.14 })
hey
Warning caught: boom
> res
[1] 3.14
Note how it never completes your expression.
/Henrik
On Thu, Dec 2, 2021 at 1:14 PM Simon Urbanek
wrote:
>
>
> Adapted from demo(error.catching):
>
> > W=list()
> > withCallingHandlers(foo(), warning=function(w) { W <<- c(W, list(w));
invokeRestart("muffleWarning") })
> > str(W)
> List of 2
> $ :List of 2
> ..$ message: chr "warning 1"
> ..$ call : language foo()
> ..- attr(*, "class")= chr [1:3] "simpleWarning" "warning" "condition"
> $ :List of 2
> ..$ message: chr "warning 2"
> ..$ call : language foo()
> ..- attr(*, "class")= chr [1:3] "simpleWarning" "warning" "condition"
>
> Cheers,
> Simon
>
>
> > On Dec 3, 2021, at 10:02 AM, Fox, John wrote:
> >
> > Dear R-devel list members,
> >
> > Is it possible to capture more than one warning message using
tryCatch()? The answer may be in ?conditions, but, if it is, I can't locate it.
> >
> > For example, in the following only the first warning message is
captured and reported:
> >
> >> foo <- function(){
> > + warning("warning 1")
> > + warning("warning 2")
> > + }
> >
> >> foo()
> > Warning messages:
> > 1: In foo() : warning 1
> > 2: In foo() : warning 2
> >
> >> bar <- function(){
> > + tryCatch(foo(), warning=function(w) print(w))
> > + }
> >
> >> bar()
> >
> >
> > Is there a way to capture "warning 2" as well?
> >
> > Any help would be appreciated.
> >
> > John
> >
> > --
> > John Fox, Professor Emeritus
> > McMaster University
> > Hamilton, Ontario, Canada
> > Web: http://socserv.mcmaster.ca/jfox/
> >
> >
> >
> > __
> > 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] string concatenation operator (revisited)
Hello, Bert Gunter started a very recent R-Help thread [1] about the following method not working. `+.character` <- function(x, y) paste0(x, y) The discussion is worth reading and at least partly answers to the reason why the feature request has never made it to base R. It goes without saying that I do not speak for the R Core team. [1] https://stat.ethz.ch/pipermail/r-help/2021-December/473163.html Hope this helps, Rui Barradas Às 22:36 de 04/12/21, Grant McDermott escreveu: Hi all, I wonder if the R Core team might reconsider an old feature request, as detailed in this 2005 thread: https://stat.ethz.ch/pipermail/r-help/2005-February/thread.html#66698 The TL;DR version is base R support for a `+.character` method. This would essentially provide a shortcut to `paste0`, in much the same way that `\(x)` now provides a shortcut to `function(x)`. a = "hello "; b = "world" a + b [1] "hello world" I appreciate some of the original concerns raised against a native "string1 + string2" implementation. The above thread also provides several use-at-your-own-risk workarounds. But sixteen years is a long time in software development and R now stands as something of an exception on this score. Python, Julia, Stata, and SQL (among various others) all support native string concatenation/interpolation using binary/arithmetic operators. It's been a surprising source of frustration for students in some of the classes I teach, particularly those coming from another language. Many thanks for considering. PS. I hope I didn't miss any additional discussion of this issue beyond the original 2005 thread. My search efforts didn't turn anything else up, except this popular Stackoverflow question: https://stackoverflow.com/questions/4730551/making-a-string-concatenation-operator-in-r Grant McDermott Assistant Professor Department of Economics University of Oregon www.grantmcdermott.com [[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] calloc() vs. R_Calloc()
Hello, Tomas is right, there are many memory operations allocating with malloc and freeing with R_Free: line: variables - operation 55: p_pichart - malloc 336: p_pichart - R_Free 236: copy_implicants - malloc 260: copy_implicants - R_Free 240: p_tempic - malloc 262: p_tempic - R_Free And there are more cases like these. For what I've seen, the frequent (unique?) case is malloc/R_Free. Hope this helps, Rui Barradas Às 09:59 de 07/04/2022, Tomas Kalibera escreveu: On 4/7/22 10:32, Adrian Dușa wrote: On Thu, 7 Apr 2022 at 10:32, Tomas Kalibera wrote: [...] And what are the errors you run into? On which platforms, under what circumstances, etc? It would be much easier to give advice knowing that. In principle, one issue you may run into when switching allocators is that you accidentally end up freeing by a different allocator from the one used to allocate it. It is common on Windows but can in principle happen elsewhere as well. Also by a slightly different heap layout or different allocator implementation you may wake up bugs in the program not seen previously (use after free, invalid memory accesses, etc) That is something I do not know yet, since the only information the server gives is this: https://builder.r-hub.io/status/original/QCA_3.16.tar.gz-a03b4462b41df37c6284be1d5519e8b3 I'll probably end up debugging the C code, but since the only difference is using Free() vs free() on exactly the same objects, I suspected a mis-usage of the R commands. The same setup passes with no problems on my local MacOS, but the errors still seem to occur on the Windows setup from r-hub. This is very likely because you are freeing memory allocated by calloc() (or something else but not R_Calloc() in your program) using R_Free() or memory allocated using R_Calloc() by using free() in your program. I would recommend checking the source code manually for that. It is not surprising that the problem doesn't appear on other platforms where the allocators happen to be the same. Best Tomas Best wishes, Adrian [[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] simplify2array assumes non-NA dim() -- base or method bug?
Hello,
I don't think it's a bug in ncol.
nrow and ncol are not generic, they are defined simply as
nrow <- function(x) dim(x)[1L]
ncol <- function(x) dim(x)[2L]
Checking:
nrow
#function (x)
#dim(x)[1L]
#
#
ncol
#function (x)
#dim(x)[2L]
#
#
Since dim(table(letters)) returns a length 1 vector, nrow returns that
value and ncol's return is the expected behavior of subsetting past the
vector length.
dim(table(letters)) # length 1
# [1] 26
nrow(table(letters)) # works as expected
# [1] 26
ncol(table(letters)) # works as expected
# [1] NA
Hope this helps,
Rui Barradas
Às 04:19 de 26/08/2022, Michael Chirico via R-devel escreveu:
Does this somewhat contradict the requirement that dimensions are non-missing?
ncol(table(letters))
# [1] NA
On the other hand,
dim(table(letters))
# [1] 26
Maybe that's a bug for the ncol() method of table?
On Thu, Aug 25, 2022 at 2:55 AM Sebastian Meyer wrote:
Hmm. I think I haven't seen NA dims in base R before. R-lang says
The 'dim' attribute is used to implement arrays. The content of
the array is stored in a vector in column-major order and the 'dim'
attribute is a vector of integers specifying the respective extents of
the array. R ensures that the length of the vector is the product of
the lengths of the dimensions.
And R-intro says:
A dimension vector is a vector of non-negative integers.
I understand "vector of [non-negative] integers" as excluding NA_integer_.
Correspondingly:
a <- 1
dim(a) <- NA_integer_
Error in dim(a) <- NA_integer_ : the dims contain missing values
matrix(1, NA_integer_)
Error in matrix(1, NA_integer_) : invalid 'nrow' value (too large or NA)
array(1, NA_integer_)
Error in array(1, NA_integer_) : negative length vectors are not allowed
There must be many more examples where non-NULL dim() is assumed to
not contain missing values.
simplify2array() aligns with that specification and only needs to check
for numeric (non-NULL) dims at this point and not also !anyNA(c.dim).
So my take is that there is no bug.
Best regards,
Sebastian Meyer
Am 25.08.22 um 04:51 schrieb Michael Chirico via R-devel:
If any component of the dim() returned as c.dim here[1] are missing,
simplify2array() errors inscrutably (specifically, because the last &&
condition is missing):
Error in if (higher && length(c.dim <- unique(lapply(x, dim))) == 1 && :
missing value where TRUE/FALSE needed
At root here is that dim.tbl_lazy ({dbplyr} package method [2]) very
intentionally neglects to count the # of rows in the result -- the
whole point of a lazy table is to avoid calculating full queries
unless specifically requested, so the # of rows is left as missing,
i.e., there _is_ a quantity of rows, but the exact number is not
known.
That seems to me like a proper usage of NA, and hence this is a
simplify2array() bug, but I am curious other thoughts here before
attempting a patch.
[1]
https://github.com/r-devel/r-svn/blob/2d4f8c283d53ff2c98d92c7b77b11e652297742c/src/library/base/R/sapply.R#L46-L48
[2]
https://github.com/tidyverse/dbplyr/blob/36b146e36d6d9af215dc48e60862d4b807b9e606/R/tbl-lazy.R#L45-L47
__
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] Parser bug? A comma too much.
Hello, A bit late but thanks for the extra explanation. Rui Barradas Às 16:00 de 16/09/2022, peter dalgaard escreveu: As a general matter, empty arguments are allowed and are used meaningfully in some contexts, notably A[i,], which is syntactic sugarcoating of "["(A,i,). I.e., these are different: "["(Sigma,2,) # 2nd row [1] 0.077 0.168 "["(Sigma,2) # 2nd element [1] 0.077 It is somewhat rare to have an empty last argument, intermediate ones are more common: seq(0,1,,5) [1] 0.00 0.25 0.50 0.75 1.00 -pd On 16 Sep 2022, at 16:33 , Rui Barradas wrote: Hello, Why doesn't the comma throw an error? plot(1:5,)# works, no complaints Shouldn't this be considered a bug? I would expect the parser to at least give a warning. sessionInfo() R version 4.2.1 (2022-06-23 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 22000) Matrix products: default locale: [1] LC_COLLATE=Portuguese_Portugal.utf8 LC_CTYPE=Portuguese_Portugal.utf8 [3] LC_MONETARY=Portuguese_Portugal.utf8 LC_NUMERIC=C [5] LC_TIME=Portuguese_Portugal.utf8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.2.1 Rui Barradas __ 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] as.Date without "origin"
Às 20:47 de 02/11/2022, Johannes Rauh escreveu: Dear all, I would throw in my vote to have origin = "1970-01-01" as a default in as.Date(). Why? Well, in fact, the "converse" function as.numeric() does have an implicit default: as.numeric(Sys.Date()) [1] 19298 In fact, as.numeric seems to not even have a method for class "Date", and so as.numeric() does not even have an argument "origin" or the like. In any case, when using Date objects, it may happen that the result is of clas numeric. For example: ifelse(TRUE, Sys.Date(), Sys.Date() + 1) [1] 19298 So, in order to transform the result back to class "Date" using as.Date(), I always need to remember the universal default origin 1970-01-01 and I need to write it out explicitly. I find that rather inconvenient, and so having the default origin as a default would make very much sense to me here. Of course, for that particular example, it would also help me if ifelse() would properly handle Date vectors. Best Johannes Gesendet: Mittwoch, 02. November 2022 um 14:38 Uhr Von: "Dan Dalthorp via R-devel" An: "Spencer Graves" Cc: "r-devel@r-project.org" Betreff: Re: [Rd] as.Date without "origin" I don't see a compelling rationale for changing the default behavior as.Date to deviate from the wholly reasonable status quo of "as.Date will accept numeric data (the number of days since an epoch), but only if origin is supplied." That has been the expectation for a long, long time. In any case, the manual should match the behavior. -DHD --- Original Message --- On Wednesday, November 2nd, 2022 at 6:20 AM, Spencer Graves wrote: I've felt that "as.Date" should default to origin "1970-01-01", so I added a modification to Ecfun: Ecfun::as.Date1970(0) If R-devel chose to change the default on this, I would happily deprecate Ecfun::as.Date1970 in favor of base::as.Date ;-) I would therefore support changing the documentation to match the new behavior. Spencer Graves On 11/2/22 7:30 AM, Dan Dalthorp via R-devel wrote: The new (2022-10-11 r83083 ucrt) as.Date function returns a date rather than an error when called without "origin" specified. # previous versions of R as.Date(0) # Error in as.Date.numeric(0) : 'origin' must be supplied # new: as.Date(0) # [1] "1970-01-01" This is at odds with the help file, which gives: origin aDateobject, or something which can be coerced byas.Date(origin, ...)to such an object. And: as.Datewill accept numeric data (the number of days since an epoch), butonlyiforiginis supplied. The behavior described in the help file and implemented in previous versions seems more reasonable than returning a date with an arbitrary "origin". In any case, in the r-devel there is a mismatch between the function and its description. -Dan [[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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Hello, ifelse does properly handle Date objects. From its documentation: Usage ifelse(test, yes, no) [...] Value A vector of the same length and attributes (including dimensions and "class") as test and data values from the values of yes or no. In your example test = TRUE and yes = Sys.Date() so the return value is class(ifelse(TRUE, Sys.Date(), Sys.Date() + 1)) # [1] "numeric" class(ifelse(TRUE, Sys.Date(), Sys.Date() + 1L)) # [1] "numeric" This is expected behavior. I was expecting class "integer", not "numeric" but this too is documented in ?Dates section Details 2nd paragraph. It is intended that the date should be an integer, but this is not enforced in the internal representation. Fractional days will be ignored when printing. It is possible to produce fractional days via the mean method or by adding or subtracting (see Ops.Date). Hope this helps, Rui Barradas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in optim for specific orders of magnitude
Às 17:30 de 23/12/2022, Collin Erickson escreveu:
Hello,
I've come across what seems to be a bug in optim that has become a nuisance
for me.
To recreate the bug, run:
optim(c(0,0), function(x) {x[1]*1e-317}, lower=c(-1,-1), upper=c(1,1),
method='L-BFGS-B')
The error message says:
Error in optim(c(0, 0), function(x) { :
non-finite value supplied by optim
What makes this particularly treacherous is that this error only occurs for
specific powers. By running the following code you will find that the error
only occurs when the power is between -309 and -320; above and below that
work fine.
p <- 1:1000
giveserror <- rep(NA, length(p))
for (i in seq_along(p)) {
tryout <- try({
optim(c(0,0), function(x) {x[1]*10^-p[i]}, lower=c(-1,-1),
upper=c(1,1), method='L-BFGS-B')
})
giveserror[i] <- inherits(tryout, "try-error")
}
p[giveserror]
Obviously my function is much more complex than this and usually doesn't
fail, but this reprex demonstrates that this is a problem. To avoid the
error I may multiply by a factor or take the log, but it seems like a
legitimate bug that should be fixed.
I tried to look inside of optim to track down the error, but the error lies
within the external C code:
.External2(C_optim, par, fn1, gr1, method, con, lower,
upper)
For reference, I am running R 4.2.2, but was also able to recreate this bug
on another device running R 4.1.2 and another running 4.0.3.
Thanks,
Collin Erickson
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Hello,
See if this R-Help thread [1] earlier this year is relevant.
In particular, the post by R Core team member Luke Tierney [2], that
answers much better than what I could.
The very small numbers in your question seem to have hit a limit and
this limit is not R related.
[1] https://stat.ethz.ch/pipermail/r-help/2022-February/473840.html
[2] https://stat.ethz.ch/pipermail/r-help/2022-February/473844.html
Hope this helps,
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NROW and NCOL on NULL
Às 20:41 de 23/09/2023, Simone Giannerini escreveu: I know it's documented and I know there are other ways to guard against this behaviour, once you know about this. The point is whether it might be worth it to make NCOL and NROW return the same value on NULL and make R more consistent/intuitive and possibly less error prone. Regards, Simone On Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch wrote: It's been documented for a long time that NCOL(NULL) is 1. What particular problems did you have in mind? There might be other ways to guard against them. Duncan Murdoch On 23/09/2023 1:43 p.m., Simone Giannerini wrote: Dear list, I do not know what would be the 'correct' answer to the following but I think that they should return the same value to avoid potential problems and hard to debug errors. Regards, Simone --- NCOL(NULL) [1] 1 NROW(NULL) [1] 0 sessionInfo() R version 4.3.1 RC (2023-06-08 r84523 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 11 x64 (build 22621) Matrix products: default locale: [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.utf8 time zone: Europe/Rome 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 Hello, The way I think of this behavior that made it intuitive is to think that in R matrices are column-major, therefore if length(NULL) == 0 then NULL can be seen as a matrix with one column and zero rows, no data. Here are other examples for which that reasoning works: m <- matrix(integer(0L)) NCOL(m) NROW(m) x <- integer(0L) NCOL(x) NROW(x) Not very convincing? Maybe with time... Hope this helps, Rui Barradas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of `[` with array and resulting class
Às 17:33 de 29/09/2023, Joseph Wood escreveu: Hello, I recently discovered a possible inconsistency with usage of an object of class array. Consider the following example: ## Setup a <- array(1:6, dim = c(1, 3, 2)) a , , 1 [,1] [,2] [,3] [1,]123 , , 2 [,1] [,2] [,3] [1,]456 class(a) [1] "array" dim(a) [1] 1 3 2 ## Now use `[` a[1,,] [,1] [,2] [1,]14 [2,]25 [3,]36 class(a[1,,]) [1] "matrix" "array" dim(a[1,,]) [1] 3 2 Up until this point, it makes sense to me. Now, let's consider when dim = c(1, 6, 1). This is where I have a little trouble understanding the behavior. ## Array with dim = c(1, any_number_here, 1) b <- array(1:6, dim = c(1, 6, 1)) b , , 1 [,1] [,2] [,3] [,4] [,5] [,6] [1,]123456 class(b) [1] "array" dim(b) [1] 1 6 1 ## The problem b[1,,] [1] 1 2 3 4 5 6 dim(b[1,,]) NULL class(b[1,,]) [1] "integer" I would have expected: b[1,,] ## produced the output with matrix(1:6, ncol = 1) [,1] [1,]1 [2,]2 [3,]3 [4,]4 [5,]5 [6,]6 class(b[1,,]) [1] "matrix" "array" dim(b[1,,]) [1] 3 1 Is this a bug? If not, any help understanding this behaviour would be much appreciated. Thanks, Joseph [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Hello, You are using the default behavior for objects of class "array" (and "matrix"), which is drop = TRUE. See ?`[`. You probably want the second example below. b <- array(1:6, dim = c(1, 6, 1)) # the default is drop = TRUE b[1,,] #> [1] 1 2 3 4 5 6 # keep the dim attribute b[1, , , drop = FALSE] #> , , 1 #> #> [,1] [,2] [,3] [,4] [,5] [,6] #> [1,]123456 Hope this helps, Rui Barradas -- Este e-mail foi analisado pelo software antivírus AVG para verificar a presença de vírus. www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Subset has No Examples for Vector Data
Às 11:00 de 10/10/2023, Dario Strbenac via R-devel escreveu: Hello, Could the documentation page for subset gain an example of how to use it for something other than a data frame or matrix? I arrived at random <- LETTERS[rpois(100, 10)] subset(table(random), x > 10) named integer(0) I expected a part of the table to be returned rather than an empty vector. -- Dario Strbenac University of Sydney Camperdown NSW 2050 Australia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Hello, If you want to subset then you must refer to a variable in the original data set. In your example there is no 'x' in the output of table. set.seed(2023) random <- LETTERS[rpois(100, 10)] (tbl <- table(random)) #> random #> C D E F G H I J K L M N P Q S #> 1 2 4 4 8 13 14 10 17 9 11 2 1 3 1 subset(tbl, tbl > 10) #> random #> H I K M #> 13 14 17 11 So it is subsetting vector data as wanted. It is your expectation that a part of the table should be returned that is not in agreement with the data you have. Hope this helps, Rui Barradas -- Este e-mail foi analisado pelo software antivírus AVG para verificar a presença de vírus. www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools error
Às 05:07 de 27/11/2023, Neha gupta escreveu: Hello, I want to download a package and it gives me the error: WARNING: Rtools is required to build R packages, but no version of Rtools compatible with R 4.2.0 was found. (Only the following incompatible version(s) of Rtools were found: 4.3.5550) Please download and install Rtools 4.2 from https://cran.r-project.org/bin/windows/Rtools/. I have downloaded it but dont know what to do further. Best regards [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Hello, Have you checked it is in the PATH system variable? After installing Rtools you must edit the Windows PATH. It not, the system will still find the older Rtools version. Hope this helps, Rui Barradas -- Este e-mail foi analisado pelo software antivírus AVG para verificar a presença de vírus. www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] round.Date and trunc.Date not working / implemented
Às 14:36 de 08/02/2024, Olivier Benz via R-devel escreveu:
On 8 Feb 2024, at 15:15, Martin Maechler wrote:
Jiří Moravec
on Wed, 7 Feb 2024 10:23:15 +1300 writes:
This is my first time working with dates, so if the answer is "Duh, work
with POSIXt", please ignore it.
Why is not `round.Date` and `trunc.Date` "implemented" for `Date`?
Is this because `Date` is (mostly) a virtual class setup for a better
inheritance or is that something that is just missing? (like
`sort.data.frame`). Would R core welcome a patch?
I decided to convert some dates to date using `as.Date` function, which
converts to a plain `Date` class, because that felt natural.
But then when trying to round to closest year, I have realized that the
`round` and `trunc` for `Date` do not behave as for `POSIXt`.
I would assume that these will have equivalent output:
Sys.time() |> round("years") # 2024-01-01 NZDT
Sys.Date() |> round("years") # Error in round.default(...): non-numeric
argument to mathematical function
Looking at the code (and reading the documentation more carefully) shows
the issue, but this looks like an omission that should be patched.
-- Jirka
You are wrong: They *are* implemented,
both even visible since they are in the 'base' package!
==> they have help pages you can read
Here are examples:
trunc(Sys.Date())
[1] "2024-02-08"
trunc(Sys.Date(), "month")
[1] "2024-02-01"
trunc(Sys.Date(), "year")
[1] "2024-01-01"
Maybe he meant
r$> Sys.time() |> round.POSIXt("years")
[1] "2024-01-01 CET"
r$> Sys.Date() |> round.POSIXt("years")
[1] "2024-01-01 UTC"
The only difference is the timezone
__
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
Hello,
You are right that the timezones are different but Sys.date() returns an
object of class "Date" so the method called is not that one.
Here an example with trunc.
Sys.Date() |> class()
Sys.Date() |> trunc("years")
Sys.Date() |> trunc.Date("years")
Sys.Date() |> trunc.POSIXt("years")
As for the OP, the problem is thhat the generic roun())) doesn't have
unit argument. So I am nnnot understanding why round.POSIXt works.
Sys.Date() |> round("years")
#> Error in round.default(structure(19761, class = "Date"), "years"):
non-numeric argument to mathematical function
Sys.Date() |> round.Date("years")
#> Error in NextMethod(): generic function not specified
Sys.Date() |> round.POSIXt("years")
#> [1] "2024-01-01 UTC"
Sys.Date() |> round.POSIXt("months")
#> [1] "2024-02-01 UTC"
Sys.Date() |> round.POSIXt("days")
#> [1] "2024-02-08 UTC"
Hope this helps,
Rui Barradas
--
Este e-mail foi analisado pelo software antivírus AVG para verificar a presença
de vírus.
www.avg.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.csv
Às 11:46 de 16/04/2024, jing hua zhao escreveu:
Dear R-developers,
I came to a somewhat unexpected behaviour of read.csv() which is trivial but worthwhile
to note -- my data involves a protein named "1433E" but to save space I drop
the quote so it becomes,
Gene,SNP,prot,log10p
YWHAE,13:62129097_C_T,1433E,7.35
YWHAE,4:72617557_T_TA,1433E,7.73
Both read.cv() and readr::read_csv() consider prot(ein) name as (possibly
confused by scientific notation) numeric 1433 which only alerts me when I tried
to combine data,
all_data <- data.frame()
for (protein in proteins[1:7])
{
cat(protein,":\n")
f <- paste0(protein,".csv")
if(file.exists(f))
{
p <- read.csv(f)
print(p)
if(nrow(p)>0) all_data <- bind_rows(all_data,p)
}
}
proteins[1:7]
[1] "1433B" "1433E" "1433F" "1433G" "1433S" "1433T" "1433Z"
dplyr::bind_rows() failed to work due to incompatible types nevertheless
rbind() went ahead without warnings.
Best wishes,
Jing Hua
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Hello,
I wrote a file with that content and read it back with
read.csv("filename.csv", as.is = TRUE)
There were no problems, it all worked as expected.
Hope this helps,
Rui Barradas
--
Este e-mail foi analisado pelo software antivírus AVG para verificar a presença
de vírus.
www.avg.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv problems
Às 17:02 de 28/06/2024, Spencer Graves escreveu:
Hello, All:
I'm getting strange errors with write.csv with some objects of
class c('findFn', 'data.frame'). Consider the following:
df1 <- data.frame(x=1)
class(df1) <- c('findFn', 'data.frame')
write.csv(df1, 'df1.csv')
# Error in x$Package : $ operator is invalid for atomic vectors
df2 <- data.frame(a=letters[1:2],
b=as.POSIXct('2024-06-28'))
class(df2) <- c('findFn', 'data.frame')
write.csv(df2, 'df1.csv')
# Error in tapply(rep(1, nrow(x)), xP, length) :
# arguments must have same length
"write.csv" works with some objects of class c('findFn',
'data.frame') but not others. I have 'findFn' object with 5264 rows that
fails with the following error:
Error in `[<-.data.frame`(`*tmp*`, needconv, value = list(Count =
c("83", :
replacement element 1 has 526 rows, need 5264
I have NOT yet been able to reproduce this error with a smaller
example. However, starting 'write.csv' with something like the following
should fix all these problems:
if(is.data.frame(x)) class(x) <- 'data.frame'
Comments?
Thanks for all your work to help improve the quality of
statistical software available to the world.
Spencer Graves
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Hello,
I don't know if this answers to question.
I wasn't able to reproduce errors but warnings, yes I was.
A way of not giving errors or warnings is to call write.csv at the end
of a pipe such as the following.
df1 <- findFn("mean")
df1 |> as.data.frame() |> write.csv("df1.csv")
This solution is equivalent to the code proposed in the OP without the
need for a change in base R.
Hope this helps,
Rui Barradas
--
Este e-mail foi analisado pelo software antivírus AVG para verificar a presença
de vírus.
www.avg.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange Behavior in RNG
Às 01:45 de 17/08/2024, Jiefei Wang escreveu: Hi, I just observed a strange behavior in R. The rnorm function does not give me the numbers with a given length. I think it is somehow related to the internal representation of double-type numbers but I am not sure if this is supposed to happen. Below is a reproducible example ``` ## Create a list, we will only take the forth value, which is 0.6 nList <- seq(0,1,0.2) n <- nList[4] n # [1] 0.6 length(rnorm(1000*n)) # [1] 600 length(rnorm(1000-1000*n)) # [1] 399 <--- What happened here? length(rnorm(1000-1000*0.6)) # [1] 400 1000-1000*n # [1] 400 <- this looks good to me... 1000-1000*0.6 # [1] 400 identical(n, 0.6) # [1] FALSE .Internal(inspect(n)) # @0x0217c75d79d0 14 REALSXP g0c1 [REF(1)] (len=1, tl=0) 0.6 .Internal(inspect(0.6)) # @0x0217c791e0c8 14 REALSXP g0c1 [REF(2)] (len=1, tl=0) 0.6 ``` As you can see, length(rnorm(1000-1000*n)) does not really give me the result I want. This is somewhat surprising because it is hard to imagine that a manually-typed 0.6 can behave differently than 0.6 from a sequence. Furthermore, 0.6 is the only problematic number from `nList`. The rest numbers work fine. I can guess it is due to the rounding mechanism, but I think this should be treated as a bug: if the print function can show the result of 1000-1000*n correctly, it will be strange that rnorm behaves differently. Below is my session info R version 4.3.0 (2023-04-21 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 19045) Matrix products: default locale: [1] LC_COLLATE=English_United States.utf8 [2] LC_CTYPE=English_United States.utf8 [3] LC_MONETARY=English_United States.utf8 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.utf8 time zone: America/Chicago tzcode source: internal __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Hello, This is R FAQ 7.31. In fact, the sequences seq(0, 1, 0.1) seq(0, 1, 0.2) should probably be a FAQ 7.31 example. If you print the numbers with more decimals you will see why the error. # generate the list nList <- seq(0,1,0.2) # compare the list with manually typed numbers nList != c(0, 0.2, 0.4, 0.6, 0.8, 1) #> [1] FALSE FALSE FALSE TRUE FALSE FALSE # note the value of 0.6 print(nList, digits = 16L) #> [1] 0. 0.2000 0.4000 0.6001 #> [5] 0.8000 1.0000 Hope this helps, Rui Barradas -- Este e-mail foi analisado pelo software antivírus AVG para verificar a presença de vírus. www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cat with backspace and newline characters
Hello,
Can't reproduce it, there must be something with your console. I get
> cat("abc\b")
ab> cat("abc\b\n")
ab
>
Hope this helps,
Rui Barradas
Em 01-11-2013 11:06, Renaud Gaujoux escreveu:
Hi,
when mixing newline and backspace characters I get the following output
(see below). In the second call, the backspace character is simply not
applied. Is this normal behaviour?
Thank you.
cat("abc\b")
ab> cat("abc\b\n")
abc
[[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] parallel::detectCores(TRUE) gives: Error in system(cmd, TRUE) : error in running command
Hello,
Inline.
Em 22-08-2014 22:18, Tobias Verbeke escreveu:
- Original Message -
From: "Marius Hofert"
To: "R-devel"
Sent: Friday, August 22, 2014 10:03:13 PM
Subject: [Rd] parallel::detectCores(TRUE) gives: Error in system(cmd, TRUE) :
error in running command
Hi,
Both under the current R-devel (r66456) and a version from about 3
months ago, I experience the following behavior:
parallel::detectCores(TRUE)
Error in system(cmd, TRUE) : error in running command
traceback()
3: system(cmd, TRUE)
2: gsub("^ +", "", system(cmd, TRUE)[1])
1: parallel::detectCores(TRUE)
This is on Ubuntu 14.04. Does anybody else see this? [I currently have
quite a heavy workload, otherwise I would have installed and tested it
also under 3.1.1]
Same under R 3.1.1
parallel::detectCores(TRUE)
Error in system(cmd, TRUE) : error in running command
I'm Using R 3.1.1 on Windows 7 and it works.
> parallel::detectCores(TRUE)
[1] 4
> sessionInfo()
R version 3.1.1 (2014-07-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252
LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] parallel_3.1.1
Rui Barradas
Best,
Tobias
__
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] Bug in new behaviour for all.equal and environments?
Hello, In R 3.1.1 on Windows 7 it's ok. > all.equal(baseenv(), baseenv()) [1] TRUE > sessionInfo() R version 3.1.1 (2014-07-10) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=Portuguese_Portugal.1252 LC_CTYPE=Portuguese_Portugal.1252 [3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C [5] LC_TIME=Portuguese_Portugal.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base Rui Barradas Em 21-09-2014 18:06, Kevin Ushey escreveu: Hi R-devel, The following code: all.equal(baseenv(), baseenv()) gives the error when run in a clean R session with latest R-devel (r66650): kevin:~$ R --vanilla --slave -e "all.equal(baseenv(), baseenv())" Error in all.equal.envRefClass(target[[i]], current[[i]], check.attributes = check.attributes, : attempt to apply non-function Calls: all.equal ... all.equal.list -> all.equal -> all.equal.envRefClass Execution halted Although I don't know if it's helpful -- it appears that packages that include some S4 machinery will effect the outcome of this error, e.g. if we load 'Biobase' first: kevin:~$ R --vanilla --slave -e "suppressPackageStartupMessages(library(Biobase)); all.equal(baseenv(), baseenv())" Error in target$getClass() : object '.refClassDef' not found Calls: all.equal ... all.equal.list -> all.equal -> all.equal.envRefClass -> Execution halted We were bumping into an error with this in Rcpp -- we used all.equal (through RUnit) to confirm that baseenv(), and a function returning the base environment, would return TRUE. For completeness: kevin:~$ R --vanilla --slave -e "sessionInfo()" R Under development (unstable) (2014-09-20 r66650) Platform: x86_64-apple-darwin13.3.0 (64-bit) locale: [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base Thanks, Kevin __ 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] How to create data frame column name in a function
Hello,
pvshankar wrote
>
> Hello all,
>
> I have a data frame with column names s1, s2, s3s11
>
> I have a function that gets two parameters, one is used as a subscript for
> the column names and another is used as an index into the chosen column.
>
> For example:
>
> my_func <- function(subscr, index)
> {
> if (subscr == 1)
> {
> df$s1[index] <- some value
> }
> }
>
> The problem is, I do not want to create a bunch of if statements (one for
> each 1:11 column names)).
> Instead, I want to "create" the column name in run time based on subscr
> value.
>
> I tried eval(as.name(paste("df$s",subscr,sep="")))[index] <- some value
>
> and it complains that object df$s1 is not found.
>
> Could someone please help me with this?
> (Needless to say, I have just started programing in R)
>
> Thanks,
> Shankar
>
Instead of operator '$' use function`[<-` with the right indexes.
cname <- paste("s", subscr, sep="")
DF[index, cname] <- value
See
?"[<-.data.frame"
(And df is the name of an R function, use something else, it can be
confusing.)
Hope this helps,
Rui Barradas
--
View this message in context:
http://r.789695.n4.nabble.com/How-to-create-data-frame-column-name-in-a-function-tp4605358p4605939.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Negative years with strptime?
Hello,
Is there a bug with negative dates? Just see:
seq(as.Date("-01-01"), length = 22, by = "-1 year")
[1] "-01-01" "000/-01-01" "000.-01-01" "000--01-01" "000,-01-01"
[6] "000+-01-01" "000*-01-01" "000)-01-01" "000(-01-01" "000'-01-01"
[11] "00/0-01-01" "00//-01-01" "00/.-01-01" "00/--01-01" "00/,-01-01"
[16] "00/+-01-01" "00/*-01-01" "00/)-01-01" "00/(-01-01" "00/'-01-01"
[21] "00.0-01-01" "00./-01-01"
See the year number: "after" the zero, i.e., downward from zero, the
printed character is '/' which happens to be the ascii character before
'0', and before it's '.', etc. This sequence gives the nine ascii
characters before zero as last digit of the year, then the 10th is '0'
as (now) expected, then goes to the second digit, etc.
It seems to stop at the first 9, or else we would have some sort of real
problem.
Anyway, this doesn't look right.
Rui Barradas
Em 10-07-2012 22:17, Winston Chang escreveu:
Is there a way to make as.Date() and strptime() process strings with
negative years? It appears that Date objects can contain negative years and
you can convert them to strings, but you can't convert them back to Date
objects.
x <- as.Date(c("0001-01-24", "0500-01-24"))
as.character(x)
# "0001-01-24" "0500-02-02"
as.Date(as.character(x))
# "0001-01-24" "0500-01-24"
# Minus 391 days gives negative year
as.character(x - 391)
# "-001-12-30" "0498-12-29"
# Can't convert this string back to Date
as.Date(as.character(x - 391))
# Error during wrapup: character string is not in a standard unambiguous
format
# as.Date.character uses strptime, so we can try using strptime directly
strptime(as.character(x), "%Y-%m-%d")
# "0001-01-24" "0500-01-24"
strptime(as.character(x - 391), "%Y-%m-%d")
# NA "0498-12-29"
Thanks,
-Winston
[[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] Negative years with strptime?
On my earlier post I forgot to mention the sessionInfo()
R version 2.15.0 (2012-03-30)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252
LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Rui Barradas
Em 11-07-2012 02:05, Winston Chang escreveu:
It looks different on my system (Mac, R 2.15.1)
seq(as.Date("-01-01"), length = 22, by = "-1 year")
[1] "-01-01" "-001-01-01" "-002-01-01" "-003-01-01" "-004-01-01"
[6] "-005-01-01" "-006-01-01" "-007-01-01" "-008-01-01" "-009-01-01"
[11] "-010-01-01" "-011-01-01" "-012-01-01" "-013-01-01" "-014-01-01"
[16] "-015-01-01" "-016-01-01" "-017-01-01" "-018-01-01" "-019-01-01"
[21] "-020-01-01" "-021-01-01"
So in addition to the issues with converting a negative-year string to a
Date, it looks like converting a negative date to a string with
as.character.Date() is probably also not consistent.
It certainly would be useful to have a way of handling dates with
negative years.
-Winston
On Tue, Jul 10, 2012 at 4:59 PM, Rui Barradas mailto:ruipbarra...@sapo.pt>> wrote:
Hello,
Is there a bug with negative dates? Just see:
seq(as.Date("-01-01"), length = 22, by = "-1 year")
[1] "-01-01" "000/-01-01" "000.-01-01" "000--01-01" "000,-01-01"
[6] "000+-01-01" "000*-01-01" "000)-01-01" "000(-01-01" "000'-01-01"
[11] "00/0-01-01" "00//-01-01" "00/.-01-01" "00/--01-01" "00/,-01-01"
[16] "00/+-01-01" "00/*-01-01" "00/)-01-01" "00/(-01-01" "00/'-01-01"
[21] "00.0-01-01" "00./-01-01"
See the year number: "after" the zero, i.e., downward from zero, the
printed character is '/' which happens to be the ascii character
before '0', and before it's '.', etc. This sequence gives the nine
ascii characters before zero as last digit of the year, then the
10th is '0' as (now) expected, then goes to the second digit, etc.
It seems to stop at the first 9, or else we would have some sort of
real problem.
Anyway, this doesn't look right.
Rui Barradas
Em 10-07-2012 22:17, Winston Chang escreveu:
Is there a way to make as.Date() and strptime() process strings with
negative years? It appears that Date objects can contain
negative years and
you can convert them to strings, but you can't convert them back
to Date
objects.
x <- as.Date(c("0001-01-24", "0500-01-24"))
as.character(x)
# "0001-01-24" "0500-02-02"
as.Date(as.character(x))
# "0001-01-24" "0500-01-24"
# Minus 391 days gives negative year
as.character(x - 391)
# "-001-12-30" "0498-12-29"
# Can't convert this string back to Date
as.Date(as.character(x - 391))
# Error during wrapup: character string is not in a standard
unambiguous
format
# as.Date.character uses strptime, so we can try using strptime
directly
strptime(as.character(x), "%Y-%m-%d")
# "0001-01-24" "0500-01-24"
strptime(as.character(x - 391), "%Y-%m-%d")
# NA "0498-12-29"
Thanks,
-Winston
[[alternative HTML version deleted]]
R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/__listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows 7 and .libPaths()
Hello,
I'm having some trouble trying to set the .libPaths() on Windows 7,
R-2.15.0 and R-2.15.1. The environment variables R_LIBS and R_LIBS_USER
are set according to the help page for .libPaths() and the Rprofile.site
file has the default setting, as shown below. R-2.14.1 recognizes the
lib paths but not R-2.15. Is this a bug or am I doing something wrong?
(I've also tried with R-2.12.0 and R-2.13.0 and it works as documented
but I only show here the output for R-2.14.1, R-2.15.0 and R-2.15.1)
First, the Windows settings.
Microsoft Windows [Versão 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Todos os direitos reservados.
C:\Users\Rui>echo %R_LIBS%
C:/PROGRA~1/R/win-library;
C:\Users\Rui>echo %R_LIBS_USER%
C:/PROGRA~1/R/win-library;C:/PROGRA~1/R/win-library/%v;
Then, file Rprofile.site .
# set libPath to win-library
.libPaths(new="C:PROGRA~1/R/win-library")
.libPaths(new=paste("C:PROGRA~1/R/win-library",
paste(R.version$major,as.integer(R.version$minor),sep='.'), sep="/"))
Finally, three R sessions.
#- R-2.14.1
> .libPaths()
[1] "C:/Program Files/R/win-library" "C:/Program
Files/R/win-library/2.14"
[3] "C:/Program Files/R/R-2.14.1/library"
>
> sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252 LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
#- R-2.15.0
> .libPaths()
[1] "C:/Program Files/R/R-2.15.0/library"
>
> sessionInfo()
R version 2.15.0 (2012-03-30)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252 LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
#- R-2.15.1
> .libPaths()
[1] "C:/Program Files/R/R-2.15.1/library"
>
> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252 LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] fortunes_1.5-0
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows 7 and .libPaths()
Hello,
Thanks, part of the problem was solved when I corrected the typo. Now it
recognizes one of the missing directories.
> .libPaths()
[1] "C:/Program Files/R/win-library/2.15" "C:/Program
Files/R/R-2.15.1/library"
That typo is in the original files, I haven't changed that part, just
tested if R, Rgui and Rterm were reading Rprofile.site by changing the
options("help_type") setting from "html" to "text" and back to "html".
It all went well.
And yes, the directories C:/Program Files/R/win-library and C:/Program
Files/R/win-library/2.15 do exist. So now I'll play with the
Rprofile.site file a bit to see if the other directory can also be found
at startup or by .libPaths(new).
Just played a bit. With .libPaths(new = a dir I want). It doesn't extend
the path, it overrides the previous setting. So, since in Rprofile.site
C:/Program Files/R/win-library comes before C:/Program
Files/R/win-library/2.15, only the latter is in effect during the R
session. This is documented behaviour, " If called with argument |new|,
the library search path is set to the existing directories in
|unique(c(new, .Library.site, .Library))| and this is returned." So I've
tried with a vector with two elements,
new <- c("C:/Program Files/R/win-library", "C:/Program
Files/R/win-library/2.15")
.libPaths(new = new)
.libPaths()
[1] "C:/Program Files/R/win-library" "C:/Program
Files/R/win-library/2.15"
[3] "C:/Program Files/R/R-2.15.1/library"
All well now, I just have to edit Rprofile.site.
Thanks a lot, your tip solved the problem.
Rui Barradas
Em 06-08-2012 13:12, Duncan Murdoch escreveu:
> On 12-08-06 6:09 AM, Rui Barradas wrote:
>> Hello,
>>
>> I'm having some trouble trying to set the .libPaths() on Windows 7,
>> R-2.15.0 and R-2.15.1. The environment variables R_LIBS and R_LIBS_USER
>> are set according to the help page for .libPaths() and the Rprofile.site
>> file has the default setting, as shown below. R-2.14.1 recognizes the
>> lib paths but not R-2.15. Is this a bug or am I doing something wrong?
>
> There's at least one typo below, but besides that, it's hard to tell.
> Do the directories you're trying to set exist? More inline.
>
>> (I've also tried with R-2.12.0 and R-2.13.0 and it works as documented
>> but I only show here the output for R-2.14.1, R-2.15.0 and R-2.15.1)
>>
>> First, the Windows settings.
>>
>> Microsoft Windows [Versão 6.1.7601]
>> Copyright (c) 2009 Microsoft Corporation. Todos os direitos reservados.
>>
>> C:\Users\Rui>echo %R_LIBS%
>> C:/PROGRA~1/R/win-library;
>
> I don't think the terminal semicolon is needed, though it shouldn't
> cause a problem.
>
>>
>> C:\Users\Rui>echo %R_LIBS_USER%
>> C:/PROGRA~1/R/win-library;C:/PROGRA~1/R/win-library/%v;
>
> Does C:/PROGRA~1/R/win-library exist? Does
> C:/PROGRA~1/R/win-library/2.5 exist? Does
> normalizePath("C:/PROGRA~1/R/win-library", winslash="/") give a
> directory that exists?
>
>>
>> Then, file Rprofile.site .
>>
>> # set libPath to win-library
>> .libPaths(new="C:PROGRA~1/R/win-library")
>> .libPaths(new=paste("C:PROGRA~1/R/win-library",
>> paste(R.version$major,as.integer(R.version$minor),sep='.'), sep="/"))
>
> These lines have the typo: it should be C:/PROGRA~1, not C:PROGRA~1.
>
>>
>> Finally, three R sessions.
>>
>> #- R-2.14.1
>>
>> > .libPaths()
>> [1] "C:/Program Files/R/win-library" "C:/Program
>> Files/R/win-library/2.14"
>> [3] "C:/Program Files/R/R-2.14.1/library"
>> >
>> > sessionInfo()
>> R version 2.14.1 (2011-12-22)
>> Platform: i386-pc-mingw32/i386 (32-bit)
>>
>> locale:
>> [1] LC_COLLATE=Portuguese_Portugal.1252
>> LC_CTYPE=Portuguese_Portugal.1252
>> [3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
>> [5] LC_TIME=Portuguese_Portugal.1252
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> #- R-2.15.0
>>
>> > .libPaths()
>> [1] "C:/Program Files/R/R-2.15.0/library"
>> >
>> > sessionInfo()
>> R version 2.15.0 (2012-03-30)
>> Platform: i386-pc-mingw32/i386 (32-bit)
>>
>> locale:
>> [1] LC_COLLATE=Portuguese_Portugal.1252
>> LC_CTYPE=Portuguese_Portugal.1252
>> [3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
>> [5] LC_TIME=Portuguese_Portugal.1252
>>
>> attach
Re: [Rd] Quiz: How to get a "named column" from a data frame
Hello, A bit more general nv <- c(a=1, d=17, e=101); nv nv2 <- c(a="a", d="d", e="e") df2 <- data.frame(VAR = nv, CHAR = nv2); df2 identical( nv, drop(t( df2[1] )) ) # TRUE identical( nv, drop(t( df2[[1]] )) ) # FALSE Rui Barradas Em 18-08-2012 16:16, Joshua Ulrich escreveu: I don't know if this is better, but it's the most obvious/shortest I could come up with. Transpose the data.frame column to a 'row' vector and drop the dimensions. R> identical(nv, drop(t(df))) [1] TRUE Best, -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com On Sat, Aug 18, 2012 at 10:03 AM, Martin Maechler wrote: Today, I was looking for an elegant (and efficient) way to get a named (atomic) vector by selecting one column of a data frame. Of course, the vector names must be the rownames of the data frame. Ok, here is the quiz, I know one quite "cute"/"slick" answer, but was wondering if there are obvious better ones, and also if this should not become more idiomatic (hence "R-devel"): Consider this toy example, where the dataframe already has only one column : nv <- c(a=1, d=17, e=101); nv a d e 1 17 101 df <- as.data.frame(cbind(VAR = nv)); df VAR a 1 d 17 e 101 Now how, can I get 'nv' back from 'df' ? I.e., how to get identical(nv, ...) [1] TRUE where .. only uses 'df' (and no non-standard R packages)? As said, I know a simple solution (*), but I'm sure it is not obvious to most R users and probably not even to the majority of R-devel readers... OTOH, people like Bill Dunlap will not take long to provide it or a better one. (*) In my solution, the above '...' consists of 17 letters. I'll post it later today (CEST time) ... or confirm that someone else has done so. Martin __ 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] memory management in C code
Hello, This is explained in Writing R Extensions, Section 6.1 file R-exts.pdf in your distribution of R, folder doc. There are two types of functions to allocate memory in C functions called from R code. 1. R_alloc() - the memory is automatically reclaimed at the end of the function call. 2. Calloc/Realloc - you must call Free() [ uppercase, not free() ] at the end of the function call. Hope this helps, Rui Barradas Em 07-12-2012 12:40, Vineeth Mohan escreveu: Hi , I am a newbie to R and i am trying to create a R package which is pretty main memory intensive. I would like to know what happens to the variables allocated in the C code while writing R extensions based on C. Are they preserved until someone de-allocate them or are they taken out by R's garbage collection ? Thanks Vineeth [[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
[Rd] file.link on Windows 7
Hello,
A post to R-Help by Oliver Soong reports what seems to be a bug specific
to Windows (I'm on Windows 7).
The original post is as follows:
from: Oliver Soong
to: r-help
date: Fri, 7 Dec 2012 22:07:49 -0800
subject: [R] file.link fails on NTFS
Windows 7 64-bit, R 2.15.2 i386. Working directory is on an NTFS drive.
writeLines("", "file.txt")
file.link("file.txt", "link.txt")
Warning in file.link("file.txt", "link.txt") :
cannot link 'link.txt' to 'link.txt', reason 'The system cannot find
the file specified'
No link is created. The 'link.txt' to 'link.txt' is suspicious. Does
this happen to anybody else? I didn't find anything in my searches.
Oliver
The above code runs with no problems on Ubuntu 12.04/ R 2.15.2,
file.link returns TRUE.
I've checked the sources and .Internal calls "file.link", executing
do_filelink(). The segment in file src/main/platform.c seems right, not
mistaking argument 'from' for 'to':
#ifdef Win32
wchar_t *from, *to;
from = filenameToWchar(STRING_ELT(f1, i%n1), TRUE);
to = filenameToWchar(STRING_ELT(f2, i%n2), TRUE);
LOGICAL(ans)[i] = CreateHardLinkW(to, from, NULL) != 0;
if(!LOGICAL(ans)[i]) {
warning(_("cannot link '%ls' to '%ls', reason '%s'"),
from, to, formatError(GetLastError()));
}
#else
But there's something going on. The link is not created and the warning
message is wrong.
Bug report? (Why CreateHardLinkW, and not CreateHardLink?)
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file.link on Windows 7
Sorry, forgot the session info.
> sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252 LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Rui Barradas
Em 08-12-2012 11:38, Rui Barradas escreveu:
Hello,
A post to R-Help by Oliver Soong reports what seems to be a bug
specific to Windows (I'm on Windows 7).
The original post is as follows:
from: Oliver Soong
to: r-help
date: Fri, 7 Dec 2012 22:07:49 -0800
subject: [R] file.link fails on NTFS
Windows 7 64-bit, R 2.15.2 i386. Working directory is on an NTFS drive.
writeLines("", "file.txt")
file.link("file.txt", "link.txt")
Warning in file.link("file.txt", "link.txt") :
cannot link 'link.txt' to 'link.txt', reason 'The system cannot find
the file specified'
No link is created. The 'link.txt' to 'link.txt' is suspicious. Does
this happen to anybody else? I didn't find anything in my searches.
Oliver
The above code runs with no problems on Ubuntu 12.04/ R 2.15.2,
file.link returns TRUE.
I've checked the sources and .Internal calls "file.link", executing
do_filelink(). The segment in file src/main/platform.c seems right,
not mistaking argument 'from' for 'to':
#ifdef Win32
wchar_t *from, *to;
from = filenameToWchar(STRING_ELT(f1, i%n1), TRUE);
to = filenameToWchar(STRING_ELT(f2, i%n2), TRUE);
LOGICAL(ans)[i] = CreateHardLinkW(to, from, NULL) != 0;
if(!LOGICAL(ans)[i]) {
warning(_("cannot link '%ls' to '%ls', reason '%s'"),
from, to, formatError(GetLastError()));
}
#else
But there's something going on. The link is not created and the
warning message is wrong.
Bug report? (Why CreateHardLinkW, and not CreateHardLink?)
Rui Barradas
__
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] C function, double problem
Hello,
The double in R and the double in C are the same type, with the same
number of decimals (64 bits), so it's not because the numbers are too long.
Try calling .C("function", other parameters, result = double(quantity)).
Or maybe the error is in the C code, of which we know nothing about.
Rui Barradas
Em 08-12-2012 02:26, mpietro escreveu:
Hi everybody,
here's my problem:
i call a C function which calculates a large number of double values and
puts them into an array which is passed from R as a parameter in the
function (like .C("function", other parameters, result = as.double( c ( 1
: quantity ) ).
When the values come back to R in the result array, they are all truncated
to their integer value (i.e. I lose the decimal parts).
I think that the problem is that this calculated double numbers are actually
too long, with many decimals, because i changed in code the calculated
values with arbitrary double values with a few decimals and it works.
Has anybody any idea of where the problem is?
Thanks in advance!
--
View this message in context:
http://r.789695.n4.nabble.com/C-function-double-problem-tp4652537.html
Sent from the R devel mailing list archive at Nabble.com.
__
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] bug in plot.ts?
Hello,
You're right, it has to do with the argument xy.labels. The relevant
lines in the source are
(file src/library/stats/R/ts.R, function plot.ts)
[...]
n <- length(xy $ x) #-> default for xy.l(ines|abels)
if(missing(xy.labels)) xy.labels <- (n <= 150)
if(!is.logical(xy.labels)) {
if(!is.character(xy.labels))
stop("'xy.labels' must be logical or character")
do.lab <- TRUE
} else do.lab <- xy.labels
[...]
ptype <-
if(do.lab) "n" else if(missing(type)) "p" else type
plot.default(xy, type = ptype,
[...]
if(do.lab)
text(xy, labels =
if(is.character(xy.labels)) xy.labels
else if(all(tsp(x) == tsp(y))) formatC(time(x), width = 1)
else seq_along(xy$x),
col = col, cex = cex)
if(xy.lines)
lines(xy, col = col, lty = lty, lwd = lwd,
type = if(do.lab) "c" else "l")
[...]
Note that this is executed only if both 'x' and 'y' are passed to plot.ts.
The variable 'do.lab' will control the plot.default type and whether the
points are labeled using text() and the lines() type.
This variable is set according to xy.labels. This behavior is more or
less documented in plot.ts:
|"xy.labels|||logical, indicating if |text
<http://127.0.0.1:29428/library/stats/help/text>()| labels should be
used for an x-y plot, /or/ character, supplying a vector of labels to be
used. The default is to label for up to 150 points, and not for more."
but I believe the documentation could be more clear. It could say that
in the case of a y ~ x plot, to supress the plot xy.labels should be set
to FALSE.
Hope this helps,
Rui Barradas
Em 29-12-2012 17:04, Simone Giannerini escreveu:
> Dear all,
>
> I think I have found a buglet in plot.ts
>
> plot.ts(x=1,type="n") # correct: does not show the plot
> plot.ts(x=1,y=1,type="n") # not correct: does show the plot
>
> I did not investigate the problem in depth but it could be related to
> the switch xy.labels, in fact
>
> plot.ts(x=1,y=1,type="n",xy.labels=TRUE) # does show the plot
> plot.ts(x=1,y=1,type="n",xy.labels=FALSE) # does not show the plot
>
>> sessionInfo()
> R version 2.15.2 Patched (2012-10-26 r61028)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252
> [3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C
> [5] LC_TIME=Italian_Italy.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] tools_2.15.2
>
>
> Kind regards
>
> Simone
> __
>
>
> Simone Giannerini
> Dipartimento di Scienze Statistiche "Paolo Fortunati"
> Universita' di Bologna
> Via delle belle arti 41 - 40126 Bologna, ITALY
> Tel: +39 051 2098262 Fax: +39 051 232153
> http://www2.stat.unibo.it/giannerini/
>
> __
> 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] bug in plot.ts?
Just to add, on documentation, to my previous post. The following
illustrates my point.
# This is the last instruction in the original post.
plot.ts(x=1, y=1, type="n", xy.labels=FALSE) # does not show the plot
plot.ts(x=1, y=1, xy.labels=FALSE) # does show the plot, does not label
it, documented
plot.ts(x=1, y=1, type="n") # does show the plot (labels it), not
properly documented
plot.ts(x=1:151, y=1:151, type="n") # does not show the plot, documented
Rui Barradas
Em 29-12-2012 19:07, Rui Barradas escreveu:
Hello,
You're right, it has to do with the argument xy.labels. The relevant
lines in the source are
(file src/library/stats/R/ts.R, function plot.ts)
[...]
n <- length(xy $ x) #-> default for xy.l(ines|abels)
if(missing(xy.labels)) xy.labels <- (n <= 150)
if(!is.logical(xy.labels)) {
if(!is.character(xy.labels))
stop("'xy.labels' must be logical or character")
do.lab <- TRUE
} else do.lab <- xy.labels
[...]
ptype <-
if(do.lab) "n" else if(missing(type)) "p" else type
plot.default(xy, type = ptype,
[...]
if(do.lab)
text(xy, labels =
if(is.character(xy.labels)) xy.labels
else if(all(tsp(x) == tsp(y))) formatC(time(x), width = 1)
else seq_along(xy$x),
col = col, cex = cex)
if(xy.lines)
lines(xy, col = col, lty = lty, lwd = lwd,
type = if(do.lab) "c" else "l")
[...]
Note that this is executed only if both 'x' and 'y' are passed to plot.ts.
The variable 'do.lab' will control the plot.default type and whether the
points are labeled using text() and the lines() type.
This variable is set according to xy.labels. This behavior is more or
less documented in plot.ts:
|"xy.labels|||logical, indicating if |text
<http://127.0.0.1:29428/library/stats/help/text>()| labels should be
used for an x-y plot, /or/ character, supplying a vector of labels to be
used. The default is to label for up to 150 points, and not for more."
but I believe the documentation could be more clear. It could say that
in the case of a y ~ x plot, to supress the plot xy.labels should be set
to FALSE.
Hope this helps,
Rui Barradas
Em 29-12-2012 17:04, Simone Giannerini escreveu:
Dear all,
I think I have found a buglet in plot.ts
plot.ts(x=1,type="n") # correct: does not show the plot
plot.ts(x=1,y=1,type="n") # not correct: does show the plot
I did not investigate the problem in depth but it could be related to
the switch xy.labels, in fact
plot.ts(x=1,y=1,type="n",xy.labels=TRUE) # does show the plot
plot.ts(x=1,y=1,type="n",xy.labels=FALSE) # does not show the plot
sessionInfo()
R version 2.15.2 Patched (2012-10-26 r61028)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252
[3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C
[5] LC_TIME=Italian_Italy.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.15.2
Kind regards
Simone
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
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] extracting tables from web pages?
Hello,
The following seems to work.
library(XML)
url <- "http://house.gov/representatives/";
dat <- readHTMLTable(readLines(url), which=1, header=TRUE)
str(dat)
head(dat)
Hope this helps,
Rui Barradas
Em 25-04-2013 21:00, Spencer Graves escreveu:
Hello:
What tools would you recommend for extracting the table of
members of the US House of representatives from
"http://house.gov/representatives/"; and
"http://en.wikipedia.org/wiki/List_of_current_members_of_the_United_States_House_of_Representatives_by_age";?
I started writing something using getURL{RCurl}. However, I'm
getting bogged down manually selecting character sequences to search for
and split on.
Thanks,
Spencer Graves
__
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
[Rd] Typo in DateTimeClasses.Rd
Hello, In my previous e-mail I forgot the link to the thread I mention. [1] https://stat.ethz.ch/pipermail/r-help/2024-October/480098.html Sorry for the mess, Rui Barradas -- Este e-mail foi analisado pelo software antivírus AVG para verificar a presença de vírus. www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in DateTimeClasses.Rd
Hello,
When following a thread that started today [1], I read the documentation
for DateTimeClasses {base} more carefully and noticed a typo in the
"Details on POSIXlt" section, in the paragraph right after the
components list.
The original and corrected are "he" instead of "the".
From earlier versions of R, he last two components will not be present
for times in UTC and are platform-dependent.
From earlier versions of R, the last two components will not be present
for times in UTC and are platform-dependent.
--- datetimeclasses.rd 2024-03-26 23:02:03.0 +
+++ datetimeclasses_2.rd2024-10-10 20:39:16.496162900 +0100
@@ -198,7 +198,7 @@
}
The components must be in this order: that was only minimally checked
prior to \R 4.3.0. All objects created in \R 4.3.0 have the optional
- components. From earlier versions of \R, he last two components will
+ components. From earlier versions of \R, the last two components will
not be present for times in UTC and are platform-dependent. Currently
\code{gmtoff} is set on almost all current platforms: those based on
BSD or \code{glibc} (including Linux and macOS) and those using the
Hope this helps,
Rui Barradas
--
Este e-mail foi analisado pelo software antivírus AVG para verificar a presença
de vírus.
www.avg.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suppressed "graphical parameter" warnings reviving themselves magically
Às 05:51 de 21/03/2025, Henrik Bengtsson escreveu:
What's going on here?
$ R --vanilla --quiet
plot.new(); suppressWarnings({ points(0, 0, foo = TRUE) })
NULL
NULL
Warning messages:
1: "foo" is not a graphical parameter
2: "foo" is not a graphical parameter
Note how the warnings are revived in that second "NULL" call. I can
reproduce this in R 4.4.3 and R-devel (2025-03-19 r88003). This might
be specific to "graphical parameter" warnings, because it won't happen
with, say, suppressWarnings({ log(-1) }).
It also doesn't appear if I call split up the first call into to
different REPL calls;
$ R --vanilla --quiet
plot.new()
suppressWarnings({ points(0, 0, foo = TRUE) })
NULL
NULL
/Henrik
PS. I thought I had sent this many months ago, but I just now found
this message in my draft folder, so now I'm not sure. Sorry, if this
is a duplicate.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Hello,
I cannot reproduce this on Windows 11, R 4.4.3.
The command below is not exactly the same but I have tried it with the
command in the OP and got the same result.
$ R --vanilla --quiet -f "rdevel.R" > ./Temp/rdevel.txt
> plot.new(); suppressWarnings({ points(0, 0, foo = TRUE) })
> NULL
NULL
> sessionInfo()
R version 4.4.3 (2025-02-28 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 11 x64 (build 22631)
Matrix products: default
locale:
[1] LC_COLLATE=Portuguese_Portugal.utf8
LC_CTYPE=Portuguese_Portugal.utf8
[3] LC_MONETARY=Portuguese_Portugal.utf8 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.utf8
time zone: Europe/Lisbon
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.4.3
>
Hope this helps,
Rui Barradas
--
Este e-mail foi analisado pelo software antivírus AVG para verificar a presença
de vírus.
www.avg.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Vuori - Due Diligence
Hello, R [1] and RStudio (now Posit) [2] are different things. Though I don't speak for any of the two, you should address Posit directly. [1] https://cran.r-project.org/ [2] https://posit.co/ Hope this helps, Rui Barradas Às 19:27 de 25/02/2025, Geoff Wolkis via R-devel escreveu: Hello - My name is Geoff Wolkis and I'm with Vuori's Third Party Risk Management Team. I've been assigned to conduct due diligence on the services and/or products your organization is providing to Vuori. In this case R Studio is providing statistical data and create reporting to be used internally. You should have received an email from our GRC platform. There is 1 questionnaire that needs to be completed: An INFOSEC Questionnaire. Appreciate your assistance in this effort and look forward to working with you. We're looking for a completed date of both assessments no later than 3/7. Feel free to reach out to me if you have any questions. Kind Regards, [-] Geoffrey Wolkis, CTPRP Information Security Analyst - Third Party Risk E: geoff.wol...@vuori.com<mailto:geoff.wol...@vuori.com> _ vuoriclothing.com<http://vuoriclothing.com/> #therisetheshine [-] <https://www.linkedin.com/company/vuori-inc-/> [-] <https://www.instagram.com/vuoriclothing/> [-] <https://twitter.com/vuoriclothing> [-] <https://www.facebook.com/vuoriclothing/> [-] <https://www.pinterest.com/vuoriclothing/> [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Este e-mail foi analisado pelo software antivírus AVG para verificar a presença de vírus. www.avg.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
