similar to: Partial matching performance in data frame rownames using [

Dear Ivan, thanks a lot, that is helpful. Still, I feel that default partial matching cripples the functionality of data.frame for larger tables. Thanks again and best regards Hilmar On 12.12.23 13:55, Ivan Krylov wrote: > ? Mon, 11 Dec 2023 21:11:48 +0100 > Hilmar Berger via R-devel <r-devel at r-project.org> ?????: > >> What was unexpected is that in this case was that

While building a package, I see the following: * checking R code for possible problems ... NOTE cheat.fit: no visible binding for global variable 'Zobs' plot.jml: no visible binding for global variable 'Var1' I see the issue has come up before, but I'm having a hard time discerning how solutions applied elsewhere would apply here. The entire code for both functions is below,

Please see the following thread to get some context on this http://marc.info/?l=linux-netdev&m=121564433018903&w=2 Basically the issue is that current multi-cast filtering stuff in the TUN/TAP driver is seriously broken. Original patch went in without proper review and ACK. It was broken and confusing to start with and subsequent patches broke it completely. To give you an idea of

Please see the following thread to get some context on this http://marc.info/?l=linux-netdev&m=121564433018903&w=2 Basically the issue is that current multi-cast filtering stuff in the TUN/TAP driver is seriously broken. Original patch went in without proper review and ACK. It was broken and confusing to start with and subsequent patches broke it completely. To give you an idea of

Hi Hilmar and Ivan, I have used your code examples to write a blog post about this topic, which has figures that show the asymptotic time complexity of the various approaches, https://tdhock.github.io/blog/2023/df-partial-match/ The asymptotic complexity of partial matching appears to be quadratic O(N^2) whereas the other approaches are asymptotically faster: linear O(N) or log-linear O(N log N).

On Wed, 13 Dec 2023 09:04:18 +0100 Hilmar Berger via R-devel <r-devel at r-project.org> wrote: > Still, I feel that default partial matching cripples the functionality > of data.frame for larger tables. Changing the default now would require a long deprecation cycle to give everyone who uses `[.data.frame` and relies on partial matching (whether they know it or not) enough time to

R-Devel, I store and retrieve a large amount of financial data (millions of rows) in a PostgreSQL database keyed by date (and represented in R by class Date). Unfortunately, I frequently find that a great deal of processing time is spent converting dates from character representations to Date class representations in R, presumably because strptime is not fast for large vectors (>10,000

> From: Douglas Bates [mailto:bates at bates4.stat.wisc.edu] > > "Liaw, Andy" <andy_liaw at merck.com> writes: > > > Sorry. I need to retract my claim. There seems to be a 3G > limit, even > > though the OS could handle nearly 8G. (I can have two > simultaneous R > > processes each using near 3G.) > > > > On another note, on

> From: Douglas Bates [mailto:bates at bates4.stat.wisc.edu] > > "Liaw, Andy" <andy_liaw at merck.com> writes: > > > Sorry. I need to retract my claim. There seems to be a 3G > limit, even > > though the OS could handle nearly 8G. (I can have two > simultaneous R > > processes each using near 3G.) > > > > On another note, on

Hi all, Assume I have a data frame with numerical and factor variables that I got through merging various other data frames and subsetting the resulting data frame afterwards. The number levels of the factors seem to be the same as in the original data frames, probably because subset() calls [.factor without drop = TRUE (that's what I gather from scanning the mailing lists). I wonder if

Note that if you force a garbage collection each iteration the times are more stable. However, on the average it is faster to let the garbage collector decide when to leap into action. mb_gc <- microbenchmark::microbenchmark(gc(), { x <- as.list(sin(1:5e5)); x <- unlist(x) / cos(1:5e5) ; sum(x) }, times=1000, control=list(order="inorder")) with(mb_gc,

Hi Hilmar, weird. The memory problem seems be due to recursion (my R, version 3.3.3, says: Error: evaluation nested too deeply: infinite recursion / options(expressions=)?, just write traceback() to see how it happens), but why does it segfault with xlsx? Nb xlsx is the culprit: neither rJava nor xlsxjars cause the problem. On the other hand, quick googling for r+xlsx+segfault returns tons of

Hi all, This occurred in R-2.11.0 (WinXP). The R-help page of .[ says that: "Character indices can in some circumstances be partially matched (see pmatch) to the names or dimnames of the object being subsetted (but never for subassignment). Unlike S (Becker et al p. 358)), R has never used partial matching when extracting by [, and as from R 2.7.0 partial matching is not by default used by

Dear Martin, On 11/09/2019 09:56, Martin Maechler wrote: > > > I wonder if data.frame(<some non-empty data>) == NULL should also return > > a value instead of an error. R help reads: > > > "At least one of |x| and |y| must be an atomic vector, but > > if the other is a list R attempts to coerce it to the > > type of the atomic

Sorry, I can't reproduce the example below even on the same machine. However, the following example produces the same error as NULL values in prior examples: > setClass("FOOCLASS", +????????? representation("list") + ) > ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10))) > isS4(ma) [1] TRUE > data.frame(a=1:3) == ma Error in

Dear all, I just found this issue: dd1 = c(rep(NaN,82), rep(-1, 144), rep(1, 74)) xx = runmed(dd1, 21) -> R crashes reproducibly in R 3.4.3, R3.4.4 (Ubuntu 14.04/Ubuntu 16.04) With GDB: Program received signal SIGSEGV, Segmentation fault. swap (l=53, r=86, window=window at entry=0xc59308, outlist=outlist at entry=0x12ea2e8, nrlist=nrlist at entry=0x114fdd8, print_level=print_level at

Hi, this is a problem that occurs in the presence of two libraries (limma, xlsx) and leads to a crash of R. The problematic code is the wrong application of sweep or the product ("*") function on an LIMMA MAList object. To my knowledge, limma does not define a "*" method for MAList objects. If only LIMMA is loaded but not package xlsx, the code does not crash but rather

Dear Hilmar Perhaps this gives an indication of why the infinite recursion happens: ## after calling `*` on ma and a matrix: > showMethods(classes=class(ma), includeDefs=TRUE, inherited = TRUE) Function: * (package base) e1="FOOCLASS", e2="matrix" (inherited from: e1="vector", e2="structure") (definition from function "Ops")

Hi January, I believe the root of the xlsx issue has been identified and a fix suggested by Tomas Kalibera (see https://github.com/s-u/rJava/pull/102). In a nutshell, Oracle Java on Linux modifies the stack in a way that makes it smaller and and the same time makes it impossible for R to detect this change, leading to segfaults. It is not clear to me that the same problem would occur on Mac,

Dear all, I did some more tests regarding the == operator in Ops.data.frame (see below).? All tests done in R 3.6.1 (x86_64-w64-mingw32). I find that errors are thrown also when comparing a zero length data.frame to atomic objects with length>0 which should be a valid case according to the documentation. This can be traced to a check in the last line of Ops.data.frame which tests for the