Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
make.index.unique() can create unsorted index #241
options(digits.secs = 6) (x <- .xts(1:5, c(rep(0, 4), 2) / 1e6)) # [,1] # 1969-12-31 18:00:00.000000 1 # 1969-12-31 18:00:00.000000 2 # 1969-12-31 18:00:00.000000 3 # 1969-12-31 18:00:00.000000 4 # 1969-12-31 18:00:00.000002 5 (y <- make.index.unique(x)) # [,1] # 1969-12-31 18:00:00.000000 1 # 1969-12-31 18:00:00.000001 2 # 1969-12-31 18:00:00.000002 3 # 1969-12-31 18:00:00.000003 4 # 1969-12-31 18:00:00.000002 5
It would be nice if this could be fixed, but floating point rounding error is likely to be a problem in the cases this may occur. A warning should be raised, at minimum.
R version 3.4.3 (2017-11-30) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 17.10 Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 locale:  LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C  LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8  LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8  LC_PAPER=en_US.UTF-8 LC_NAME=C  LC_ADDRESS=C LC_TELEPHONE=C  LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages:  stats graphics grDevices utils datasets methods base other attached packages:  xts_0.10-2.1 zoo_1.8-1 loaded via a namespace (and not attached):  compiler_3.4.3 tools_3.4.3 grid_3.4.3 lattice_0.20-35
added a commit
May 9, 2018
Main consideration here is if
I would like nanosecond resolution in xts, but that will take a bit of work. This problem could theoretically exist even with higher resolution index timestamps, but it would be less probable.
The current solution in this branch works around the issue by always checking and ensuring that the value of
This sounds correct to me.
It has always been possible that make.index.unique could push things past the next observed index, and that problem only got worse as reported data moved beyond millisecond precision.
Until xts supports nano-scale indexes, checking and warning the user that they may be doing something unintended with make.index.unique seems the best solution.
I showed a possible solution to this problem (#190 (comment)) and yes, it is a lot of work, but in my opinion it is worth taking up this effort. The key is to not break xts R API for external packages.
If you decide on the proposed solution, then of course I will be very committed to help as much as possible (especially in the case of C code).