[ regression in 1.14.3

Good result:

> n  <-  4; k  <- 2
> mm <- data.table( a=  rep(1:k,n), b = seq_len(n*k) , d= rep(1:n,k))
> mm[ a == 2, e := sum(b),d][]
   a b d  e
1: 1 1 1 NA
2: 2 2 2  8
3: 1 3 3 NA
4: 2 4 4 12
5: 1 5 1 NA
6: 2 6 2  8
7: 1 7 3 NA
8: 2 8 4 12
> packageVersion("data.table")
[1] '1.14.2'

Bad result:

> n  <-  4 ; k  <- 2
> mm <- data.table( a=  rep(1:k,n), b = seq_len(n*k) , d= rep(1:n,k))
> mm[ a == 2, e := sum(b),d][]
Index: <a>
       a     b     d     e
   <int> <int> <int> <int>
1:     1     1     1     8
2:     2     2     2    12
3:     1     3     3     8
4:     2     4     4    12
5:     1     5     1    NA
6:     2     6     2    NA
7:     1     7     3    NA
8:     2     8     4    NA
> packageVersion("data.table")
[1] ‘1.14.3’

Bisection shows that this bug was introduced in c3df3bc

Yup, just wanted to write that this looks like #5307

@ben-schwen

@ben-schwen Thanks. One general question about the release process: I wish to rebase my fork on 1.14.2, and I see no branch or tag marking it - only a milestone. Do you guys upload to CRAN directly from the dev branch once a milestone is declared complete? Would the CRAN release tests have caught this bug? (my guess is not)

@OfekShilon

@OfekShilon
Normally, there is a tag for each release. AFAIK 1.14.2 is special on this point since it had to be submitted rather fast for data.table not be archived on CRAN. See also comment here

Whether, #5307, #5326 or this issue #5337 (which are all due to the same underlying sorting issue) would have been caught by release tests, I honestly do not know. Our internal tests did not. For a release on CRAN also revdeps are carried out, which might or might not have caught it.

you can see .dev/revdeps.R for the script to check revdeps. historically revdeps has done a good job of identifying regressions like this. hard to say for sure in a given case without running it of course.

@mattdowle

@mattdowle would you mind adding the 1.14.2 tag to the relevant commit?

As for the finding commit that will have a tag 1.14.2, the easiest way is to check history of DESCRIPTION file and take the parent commit of a commit which incremented version to 1.14.3.

@MichaelChirico

@MichaelChirico 1.14.2 was a minimal hotfix/patch/backport of one PR (#5172) applied manually to v1.14.0 at a time when master had a significant number of merges in dev since v1.14.0. So there is no appropriate commit that exists that can be tagged with v1.14.2 as far as I know. #5172 (comment).

@mattdowle

@mattdowle we could just push that particular state (1.14.2) into own branch.

added test from #5337

Navigation Menu

Repository navigation

`[` regression in 1.14.3 #5337

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[ regression in 1.14.3 #5337

Description

Activity

OfekShilon commented on Feb 17, 2022

ben-schwen commented on Feb 17, 2022

OfekShilon commented on Feb 17, 2022

ben-schwen commented on Feb 17, 2022

MichaelChirico commented on Feb 17, 2022

MichaelChirico commented on Feb 17, 2022

jangorecki commented on Feb 17, 2022

mattdowle commented on Mar 11, 2022

jangorecki commented on Mar 13, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`[` regression in 1.14.3 #5337