Unexpected behavior of "by=group" in combination with chron()

Open
#5,488 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
r
Domain
data

Research direction

Start by running the reproducible data.table and chron example from the issue and compare the grouped chron results with paste(). Trace the grouped evaluation path implicated by the verbose output. Done means each yyyy group produces chron timestamps using its own year, with a regression test covering the reported case.

Written by the indexing model from the issue text.

Description

non-atomic column

First off, thank you so very much for the amazing data.table package, which I have been using almost daily for many years.

I searched data.table NEWS and stack overflow [data.table] for previous mentions of this issue and did not find any.

There appears to be a data.table bug related to the use of "by=group" in combination with chron() from the chron package. In the following reproducible example, data.table with "by=group" seems to call chron() in such a way that information from the first group is leaked to and used by subsequent groups, unlike the way it works for other functions (I used paste() in the example). I do not think this is a chron bug, because data from the first "by=group" should not be available to subsequent groups, correct?

Notes: The data.table foo contains time/date information encoded as seconds since the beginning of the year (time.s) and year (yyyy). Chron can assemble this information into a timestamp via chron(time.s/60/60/24,origin=c(1,1,yyyy[1])). With "group=yyyy", the chron origin and resulting timestamp should vary by yyyy group, but they do not. The desired behavior is for each timestamp to use the correct year, e.g.: (01/01/19 00:01:01) instead of (01/01/17 00:01:01).

I have tried many variants of this code (e.g., re-ordering the groups, grouping by a third variable, or omitting a subset of lines). In all cases, all chron timestamps wound up using the year from the first group, as if "by=yyyy" had been omitted, whereas paste(yyyy[1],time.s) works as desired and expected.

I got the same behavior on three different machines and R versions as far back as 3.6.1. The example session info is from an instance of RStudio Cloud.

Thanks for your help,

-Klaus Huebert

library(data.table)
library(chron)
options(datatable.verbose=TRUE)

foo<-data.table(time.s=59:62, yyyy=c(2017,2019,2018,2017))

foo
#    time.s yyyy
# 1:     59 2017
# 2:     60 2019
# 3:     61 2018
# 4:     62 2017

foo[,.(paste=paste(yyyy[1], time.s), chron=chron(time.s/60/60/24, origin=c(1, 1, yyyy[1]))), by=yyyy]
# Detected that j uses these columns: time.s 
# Finding groups using forderv ... forder.c received 4 rows and 1 columns
# 0.000s elapsed (0.000s cpu) 
# Finding group sizes from the positions (can be avoided to save RAM) ... 0.000s elapsed (0.000s cpu) 
# Getting back original order ... forder.c received a vector type 'integer' length 3
# 0.000s elapsed (0.000s cpu) 
# lapply optimization is on, j unchanged as 'list(paste(yyyy[1], time.s), chron(time.s/60/60/24, origin = c(1, 1, yyyy[1])))'
# GForce is on, left j unchanged
# Old mean optimization is on, left j unchanged.
# Making each group and running j (GForce FALSE) ... 
#   collecting discontiguous groups took 0.000s for 3 groups
#   eval(j) took 0.000s for 3 calls
# 0.000s elapsed (0.000s cpu) 
#    yyyy   paste               chron
# 1: 2017 2017 59 (01/01/17 00:00:59)
# 2: 2017 2017 62 (01/01/17 00:01:02)
# 3: 2019 2019 60 (01/01/17 00:01:00)
# 4: 2018 2018 61 (01/01/17 00:01:01)

sessionInfo()
# R version 4.2.1 (2022-06-23)
# Platform: x86_64-pc-linux-gnu (64-bit)
# Running under: Ubuntu 20.04.5 LTS
# 
# Matrix products: default
# BLAS:   /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3
# LAPACK: /usr/lib/x86_64-linux-gnu/atlas/liblapack.so.3.10.3
# 
# locale:
#  [1] LC_CTYPE=C.UTF-8       LC_NUMERIC=C           LC_TIME=C.UTF-8        LC_COLLATE=C.UTF-8    
#  [5] LC_MONETARY=C.UTF-8    LC_MESSAGES=C.UTF-8    LC_PAPER=C.UTF-8       LC_NAME=C             
#  [9] LC_ADDRESS=C           LC_TELEPHONE=C         LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C   
# 
# attached base packages:
# [1] stats     graphics  grDevices utils     datasets  methods   base     
# 
# other attached packages:
# [1] chron_2.3-58      data.table_1.14.2
# 
# loaded via a namespace (and not attached):
# [1] compiler_4.2.1 tools_4.2.1 
Dominant language
R
Stars
3.9k
Forks
1.1k
Avg merge
14h 4m
Merged PRs (30d)
4

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Rdatatable/data.table

All issues in Rdatatable/data.table

Similar issues

More R issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.