similar to: Refactor all factors in a data frame

Hi all, In R, it is not possible to set the font size of axis labels directly (AFAIK). Instead, scaling factors for the font chosen by the graphics device can be supplied. It appears that there is no constant font size for axis labels. My impression is that the axis label font size is scaled internally by R depending on the number of labels given for an axis. In addition to the R-internal

Hello, is there a R package that provides a log rank trend test for survival data in >=3 treatment groups? Or are there any comparable trend tests for survival data in R? Thanks a lot Markus -- Dipl. Inf. Markus Kreuz Universitaet Leipzig Institut fuer medizinische Informatik, Statistik und Epidemiologie (IMISE) Haertelstr. 16-18 D-04107 Leipzig Tel. +49 341 97 16 276 Fax. +49 341 97 16

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 all, I'm not quite sure if this is a feature or a bug or if I just fail to understand the documentation: If I use cor() with pairwise.complete.obs and method=pearson, the result is a scalar: ->cor(c(1,2,3),c(3,4,6),use="pairwise.complete.obs",method="pearson") [1] 0.9819805 The documentation says that " '"pairwise.complete.obs"' only

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

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

Dear all, actually, it is not clear to me why there is still a protection of the added Row.names column in merge using I(). This seems to stem from a time when R would automatically convert character vectors to factor in data.frame on insert. However, I can't reproduce this behaviour even in data.frames generated with stringsAsFactors = T in current versions of R. Maybe the I() inserted in r

Dear R users, is there any possibility to get an object-name completion within the R command line (UNIX-version of R). As I got to know from the FAQ that this is possible from within Emacs (ESS), but without using Emacs? Thank's Ingo -- ----------------------------------------------------------------- Ingo Roeder Institute for Medical Informatics, Statistics and Epidemiology

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: x86_64-w64-mingw32/x64 (64-bit) > list(a=1:3, b=LETTERS[1:3]) == NULL logical(0) > matrix(1:6, 2,3) == NULL logical(0) > data.frame(a=1:3,

? Fri, 12 Jul 2024 17:35:19 +0200 Hilmar Berger via R-devel <r-devel at r-project.org> ?????: > This can be finally traced to base::rank() (called from > xtfrm.default), where I found that > > "NB: rank is not itself generic but xtfrm is, and rank(xtfrm(x), ....) > will have the desired result if there is a xtfrm method. Otherwise, > rank will make use of ==, >,

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

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