similar to: R (development) changes in arith, logic relop with 0-extent arrays

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Tue, 6 Sep 2016 22:26:31 +0200 writes: > Yesterday, changes to R's development version were committed, relating > to arithmetic, logic ('&' and '|') and > comparison/relational ('<', '==') binary operators > which in NEWS are

>>>>> robin hankin <hankin.robin at gmail.com> >>>>> on Thu, 8 Sep 2016 10:05:21 +1200 writes: > Martin I'd like to make a comment; I think that R's > behaviour on 'edge' cases like this is an important thing > and it's great that you are working on it. > I make heavy use of zero-extent arrays, chiefly

Shouldn't binary operators (arithmetic and logical) should throw an error when one operand is NULL (or other type that doesn't make sense)? This is a different case than a zero-length operand of a legitimate type. E.g., any(x < 0) should return FALSE if x is number-like and length(x)==0 but give an error if x is NULL. I.e., I think the type check should be done before the length

On 09/08/2016 01:22 PM, Gabriel Becker wrote: > On Thu, Sep 8, 2016 at 10:05 AM, William Dunlap <wdunlap at tibco.com> wrote: > >> Shouldn't binary operators (arithmetic and logical) should throw an error >> when one operand is NULL (or other type that doesn't make sense)? This is >> a different case than a zero-length operand of a legitimate type. E.g.,

Prior to the mid-1990s, S did "length-0 OP length-n -> rep(NA, n)" and it was changed to "length-0 OP length-n -> length-0" to avoid lots of problems like any(x<0) being NA when length(x)==0. Yes, people could code defensively by putting lots of if(length(x)==0)... in their code, but that is tedious and error-prone and creates really ugly code. Is your suggestion to

Thank you, Gabe and Bill, for taking up the discussion. >>>>> William Dunlap <wdunlap at tibco.com> >>>>> on Thu, 8 Sep 2016 10:45:07 -0700 writes: > Prior to the mid-1990s, S did "length-0 OP length-n -> rep(NA, n)" and it > was changed > to "length-0 OP length-n -> length-0" to avoid lots of problems like

>>>>> Radford Neal <radford at cs.toronto.edu> >>>>> on Fri, 9 Sep 2016 10:29:14 -0400 writes: >> Radford Nea: >> > So it may make more sense to move towards consistency in the >> > permissive direction, rather than the restrictive direction. >> >> > That would mean allowing matrix(1,1,1) <

>>>>> Radford Neal <radford at cs.toronto.edu> >>>>> on Thu, 8 Sep 2016 17:11:18 -0400 writes: > Regarding Martin Maechler's proposal: > Arithmetic between length-1 arrays and longer non-arrays had > silently dropped the array attributes and recycled. This now gives > a warning and will signal an error in the future, as it

Could we take a cue from min() and max()? > x <- 1:10 > min(x[x>7]) [1] 8 > min(x[x>11]) [1] Inf Warning message: In min(x[x > 11]) : no non-missing arguments to min; returning Inf > As ?min says, this is implemented to preserve transitivity, and this makes a lot of sense. I think the issuing of a warning here is a good compromise; I can always turn off warnings if I

Martin I'd like to make a comment; I think that R's behaviour on 'edge' cases like this is an important thing and it's great that you are working on it. I make heavy use of zero-extent arrays, chiefly because the dimnames are an efficient and logical way to keep track of certain types of information. If I have, for example, a <- array(0,c(2,0,2)) dimnames(a) <-

Martin, Like Robin and Oliver I think this type of edge-case consistency is important and that it's fantastic that R-core - and you personally - are willing to tackle some of these "gotcha" behaviors. "Little" stuff like this really does combine to go a long way to making R better and better. I do wonder a bit about the x = 1:2 y = NULL x < y case. Returning a

Yesterday, changes to R's development version were committed, relating to arithmetic, logic ('&' and '|') and comparison/relational ('<', '==') binary operators which in NEWS are described as SIGNIFICANT USER-VISIBLE CHANGES: [.............] ? Arithmetic, logic (?&?, ?|?) and comparison (aka ?relational?, e.g.,

Regarding Martin Maechler's proposal: Arithmetic between length-1 arrays and longer non-arrays had silently dropped the array attributes and recycled. This now gives a warning and will signal an error in the future, as it has always for logic and comparison operations For example, matrix(1,1,1) + (1:2) would give a warning/error. I think this might be a mistake. The potential

> > But isn't the intent to make it an error later? So I assume we're > > debating making it an error, not just a warning. > > Yes, that's correct. > But if we have a longish deprecation period (i.e. where there's > only a warning) all important code should have been adapted > before it turns to an error That might be true for

> Radford Nea: > > So it may make more sense to move towards consistency in the > > permissive direction, rather than the restrictive direction. > > > That would mean allowing matrix(1,1,1) < (1:2), and maybe also things > > like matrix(1,2,2)+(1:8). > > Martin Maechler: > That is an interesting idea. Yes, in my view that would >

On Thu, Sep 8, 2016 at 10:05 AM, William Dunlap <wdunlap at tibco.com> wrote: > Shouldn't binary operators (arithmetic and logical) should throw an error > when one operand is NULL (or other type that doesn't make sense)? This is > a different case than a zero-length operand of a legitimate type. E.g., > any(x < 0) > should return FALSE if x is number-like

When attempting to merge 3 data frames, one of which has fewer columns than the others, rbind.data.frame correctly refuses to perform the bind. However, the error message given is a bit obscure due to a logical bug in the match.names() internal function to rbind.data.frame. Illustration: ## Three data frames with same column variable names: > foo <- data.frame(v1 = c('a',

Dear Thomas & Dear List, the fitting function `coxph.fit' called by `coxph' may fail to estimate the regression coefficients when some values of the design matrix are very large. For example library(survival) ### load example data load(url("http://www.imbe.med.uni-erlangen.de/~hothorn/coxph_fit.Rda")) method <- "efron" ### copied from `coxph.fit' coxfit

Background: I administer a cluster of RedHat EWS 3U4 Linux workstations at a university. I built R 2.1.0 from source: ./configure \ --prefix=/sscc/opt/R-2.1.0 \ --with-blas=no \ 2>&1 \ | tee NUInstall.configure R is now configured for i686-pc-linux-gnu Source directory: . Installation directory: /sscc/opt/R-2.1.0 C compiler:

A number of users have spotted a terminal problem with the 'debug' package under R2.4.0, along the lines of > mtrace(x) > x() Error in attr(value, "row.names") <- rlabs : row names must be 'character' or 'integer', not 'double' This arose from a bug in 'rbind.data.frame' in R2.4.0 itself. The bug is fixed in R2.4.0 patched, so the