Joshua Ulrich
Joshua Ulrich
Please create an issue and wait for feedback before you spend time working on a patch for a pull request. You don't know if I consider this a bug, and...
I'm not convinced this is a bug. If you look at the output of `endpoints`, you will see why `to.period` is returning the first row unchanged. ``` r head(endpoints(GBPUSD, 'minutes',...
`endpoints` does not produce output based on first observed time in the data passed to it. The first element of `endpoints`' output is always zero, and in your example the...
`endpoints` finds the first element the same way it finds all the elements. It doesn't actively "choose" any time from the input data as a baseline. The baseline is determined...
No, the cutoff for `on = "minutes"` would be XX:XX:59.999. I.e. the end of every minute (assuming `k = 1`).
Every 2 minutes. So, xx:x1:59.999, xx:x3:59.999, etc. The first 2 minutes of every hour are from xx:00:00.000-xx:01:59.999. The next two minutes are xx:02:00.000-xx:03:59.999... and the last 2 minutes are xx:58:00.000-xx:59:59.999.
`period.apply()` is essentially a convenience wrapper around `sapply()`, so it's not particularly performant. There's a faster unexported C-based version that needs some testing before I'm comfortable exporting it and/or replacing...
I appreciate your comment and desire to make xts even faster. However, your code is over-optimized to this specific example. Here are the issues that are immediately clear to me:...
Thanks for the notes about `period.sum()` and others. That slowdown was due to an unnecessary `as.matrix()` call. The timings are more in xts' favor once those are removed: ```r >...
@AndreMikulec `d` is the first 4 rows of `x`. Sorry for the confusion. ```r d