-
Notifications
You must be signed in to change notification settings - Fork 992
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
IDate storage mode not preserved in data frames #2008
Comments
Interesting. Somehow this line in
So as expected. And
Prior to running that line,
However, after running that line,
|
Even stranger, on a fresh R session without
|
I have encountered an issue that may be related.
However, this changes the storage mode:
Numerically are the same but in the second case the storage mode changes to
|
I ran into @lbilli 's case today:
I guess this means IDate vectors can only be safely edited with In case you're wondering why I'm doing this: I have a function that takes a length-2 idate vector representing a range. If the upper bound is missing, it is filled in by taking the max date observed in some other vectors. Another related case:
|
The whackiness continues:
So you apparently can't put any old class into a But if you make it also inherit a
No error, and |
Potential lead in
|
Adding However, in desperation I tried to catch any time any
Then ran Really have no idea why that's being called, but that would certainly run Anyway, if we eliminate Would still like to know the root cause of why |
Hi,
To save space, I've been using IDate within my data frames (not data tables) to save space. Maybe this is a user bug right here, if IDate isn't meant to be used outside of data.tables, but I'll continue.
Seems that rbind() does not preserve the integer storage mode of IDate inside of data.frames, which causes problems when using IDate arithmetic. Instead, rbind coerces IDate into storage.mode double. My code has worked perfectly for a while. I only started seeing errors after updating to the latest data.table 1.10.0 and R 3.3.2. However, I'm not sure if the coercion to double didn't happen in the earlier versions, or just that it wasn't checked before.
Here's an example:
The text was updated successfully, but these errors were encountered: