-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
as.Date can result in different underlying types #6602
Comments
Could you link the data.table code since you found it? Id say yes it's likely related to that Bugzilla report + associated fix. Seems R-core want to move more towards greedily allowing Date type to have underlying integer storage sometimes, not sure what exactly we should do in light of that. |
It is test case 1848.1 As you mentioned, with R-devel r87285 on Windows we have The strange part is that |
Update: Turning on
Minimal reprex: date_int = seq(as.Date('2015-01-01'), as.Date('2015-01-01'), by="day")
x = data.table(a=date_int, b=1)
y = data.table(c=date_int, d=as.Date('2015-01-01'))
y[x, on=.(c == a, d == a)] |
I can reproduce using R-devel
|
This now also errors on all devel versions on the CRAN checks |
Unless something changed, CRAN reached out a few weeks ago and suggested it was a bug on devel regarding coercion of dates. They said they weren't planning on making an actual change here. Not sure if it's the same issue tho, can look into it. |
Could you lay out why that's an issue? Maybe coercion is ignored for the first time the column is used, but then done the second time, which would require also having coerced the first time? |
Suppose you have the tables, A: i1 and B: i2, d1. |
Hmm, that makes some sense, but then why are Dates involved? It sounds like we could reproduce with only atomic columns, which I tried without success: DT1 = data.table(i = 1:10)
DT2 = data.table(d1 = c(-1, 5, 11), i2 = c(3L, -2L, 12L))
dim(DT1[DT2, on = .(i >= d1, i <= i2), verbose=TRUE])
Coercing double column i.i1 (which contains no fractions) to type integer to match type of x.i.
# ...
# [1] 5 2
dim(DT1[DT2, on = .(i <= i2, i >= d1), verbose=TRUE])
# i.i2 has same type (integer) as x.i. No coercion needed.
# Coercing double column i.i1 (which contains no fractions) to type integer to match type of x.i.
# ...
# [1] 5 2 |
Good point and indeed the error also appears when swapping right for left join DT1 = data.table(i = 1:10)
DT2 = data.table(d1 = c(-1, 5, 11), i2 = c(3L, -2L, 12L))
DT2[DT1, on = .(i2 <= i, d1 >= i), verbose=TRUE]
# i.i has same type (integer) as x.i2. No coercion needed.
# Coercing integer column i.i to type double for join to match type of x.d1.
# Assigning to all 10 rows
# RHS_list_of_columns == false
# Direct plonk of unnamed RHS, no copy. MAYBE_REFERENCED==1, MAYBE_SHARED==0
# Non-equi join operators detected ...
# forder took ... forder.c received 3 rows and 2 columns
# forderReuseSorting: opt=-1, took 0.000s
# 0.000s elapsed (0.000s cpu)
# Generating non-equi group ids ... done in 0.005s elapsed (0.006s cpu)
# Recomputing forder with non-equi ids ... Assigning to all 3 rows
# RHS_list_of_columns == false
# RHS for item 1 has been duplicated because MAYBE_REFERENCED==1 MAYBE_SHARED==1, but then is being plonked. length(values)==3; length(cols)==1)
# forder.c received 3 rows and 3 columns
# forderReuseSorting: opt=-1, took 0.000s
# done in 0.005s elapsed (0.006s cpu)
# Found 2 non-equi groups ...
# Starting bmerge ...
# Error in bmerge(i, x, leftcols, rightcols, roll, rollends, nomatch, mult, :
# typeof x.i2 (integer) != typeof i.i (double) |
Nice... that points to a more fundamental issue about joins involving the same column in multiple conditions that we should fix regardless of the r-devel behavior |
@TysonStanley this is fixed in a patch branch & ready to be shipped I believe: https://github.com/Rdatatable/data.table/tree/patch-1.16.4 Thank you! |
Thanks all. Submitted the patch to CRAN today, awaiting review. |
R CMD check is currently failing on windows-devel with
typeof x.START_DATE (integer) != typeof i.DATE (double)
The responsible code is explicitly casting to
as.Date
, so I guess this a bug inR-devel
?Seems related to this recent change in R-devel:
https://bugs.r-project.org/show_bug.cgi?id=18782
The text was updated successfully, but these errors were encountered: