similar to: '==' operator: inconsistency in data.frame(...) == NULL

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

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

Dear Martin, thanks a lot for looking into this. Of course you were right that the fix was not complete - I apologize for not having tested what I believed to be the solution. My comments on the S4 classes seemed to stem from a misunderstanding on my side. I now believe to understand that S4 classes that inherit from R base object types might dispatch Ops for the same object types. If the

>>>>> Hilmar Berger >>>>> on Sat, 14 Sep 2019 13:31:27 +0200 writes: > 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

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

Another example where a data.frame is compared to (here non-null, non-empty) non-atomic values in Ops.data.frame, resulting in an error message: setClass("FOOCLASS2", ???????? slots = c(M="matrix") ) ma = new("FOOCLASS2", M=matrix(rnorm(300), 30,10)) > isS4(ma) [1] TRUE > ma == data.frame(a=1:3) Error in eval(f) : dims [product 1] do not match the length

Hi, On 08/05/17 16:37, Ista Zahn wrote: > One of the key strengths of R is that packages are not akin to "fan > created mods". They are a central and necessary part of the R system. > I would tend to disagree here. R packages are in their majority not maintained by the core R developers. Concepts, features and lifetime depend mainly on the maintainers of the package (even

>>>>> Hilmar Berger >>>>> on Wed, 4 Sep 2019 15:25:46 +0200 writes: > Dear all, > I just stumbled upon some behavior of the == operator which is at least > somewhat inconsistent. > R version 3.6.1 (2019-07-05) -- "Action of the Toes" > Copyright (C) 2019 The R Foundation for Statistical Computing > Platform:

Hi, I experience surprisingly large timing differences for the multiplication of matrices of the same dimension. An example is given below. How can this be explained? I posted the question on Stackoverflow: https://stackoverflow.com/questions/58886111/r-why-is-matrix-product-slower-when-matrix-has-very-small-values Somebody could reproduce the behavior but I did not get any useful explanations

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

>>>>> Martin Maechler >>>>> on Wed, 18 Sep 2019 10:35:42 +0200 writes: >>>>> Hilmar Berger >>>>> on Sat, 14 Sep 2019 13:31:27 +0200 writes: >> Dear all, >> I did some more tests regarding the == operator in Ops.data.frame (see >> below).? All tests done in R 3.6.1

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 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

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

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 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")

Full_Name: Hilmar Berger Version: 2.4.1/2.6.2alpha OS: WinXP Submission from: (NULL) (84.185.128.110) Hi all, If I use tapply on an empty data.frame I get an error. I'm not quite sure if one can actually expect the function to return with a result. However, the error message suggests that this case does not get handled well. This happens both in R-2.4.1 and 2.6.2alpha (version 2008-01-26).

Hi, following up on my own question, I found smaller example that does not require LIMMA: setClass("FOOCLASS", representation("list") ) ma = new("FOOCLASS", list(M=matrix(rnorm(300), 30,10))) > ma * ma$M Error: C stack usage 7970512 is too close to the limit > library(xlsx) Loading required package: rJava Loading required package: xlsxjars

Thanks for the answers, I?m aware of the ?.? option, just wanted to give a very simple example. But the lapply ??' parameter use has eluded me and thanks for enlightening me. What do you mean by messing up the call stack. As far as I understand it, piping should translate into same code as deep nesting. So then I only see a tiny downside for debugging here. No loss of time/space efficiency