Sebastian Krantz
Sebastian Krantz
Perhaps let me add that the issue is – as you can verify – that coercing to double using `as.double()` doesn't give the original number back, so the problem here...
Thanks. But let me ask then what is the expected behavior? ```r fmutate(mtcars[1:5,], wt = bit64::as.integer64(wt)) |> with(as.character(wt)) [1] "2" "2" "2" "3" "3" mtcars[1:5, "wt"] [1] 2.620 2.875 2.320...
`as.double()` also works here and would be more efficient. I can see if that can be done internally. But possily it will not work as `as.double.integer64` is an externally defined...
FYI, `fmatch()` and `join()` now support *integer64*.
Thanks, I’ll consider it, but can’t promise at this point.
Please use v2.1.2 - there was some missing garbage collection in earlier versions which may have led to memory overconsumption.
Thanks. I think though this is something that needs to be solved in R. In C adding 0 to every numeric number or checking for 0 would have noticeable performance...
I added a branch "zero_dups" with this feature implemented in C `remotes::install_github("SebKrantz/collapse", ref = "zero_dups")`. Seems to work. You can help me benchmark it. I think it's like a 10%...
Perhaps as an addition (for other functions like `qF()` etc.), you can add a zero by reference `out %+=% 0`, which is much more efficient than `out
Actually I just tested, using an integer 0 is pretty fast! @NicChr can you confirm that adding an integer 0 (0 instead of 0.0) gives much less performance cost?