I needed these two features, and thought they might be useful in general, so I spent some extra time implementing them on top xts, see the attachments. Not sure whether I managed to cover all cases, but it should be a solid start if you decide adding them to the package. Note: Only the Unix form of parallelism (mclapply from parallel) is supported, but that's mainly for expedience. Adding support for parSapply is feasible, but it usually leads to more cumbersome interfaces. Regards, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20141220/ab879a5d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: rollapply.xts.R Type: text/x-r-source Size: 6536 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20141220/ab879a5d/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: rollapply.xts.R.orig Type: application/octet-stream Size: 6539 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-sig-finance/attachments/20141220/ab879a5d/attachment.obj>
Prototyped support for "partial" and parallelism to rollapply.xts
3 messages · Ivan Popivanov, Joshua Ulrich
1 day later
Hi Ivan, Thanks for the contributions! Did you happen to test the partial=TRUE output versus rollapply.zoo? Also, can you share your use case for running rollapply in parallel? Best, Josh On Fri, Dec 19, 2014 at 11:05 PM, Ivan Popivanov
<ivan.popivanov at gmail.com> wrote:
I needed these two features, and thought they might be useful in general, so I spent some extra time implementing them on top xts, see the attachments. Not sure whether I managed to cover all cases, but it should be a solid start if you decide adding them to the package. Note: Only the Unix form of parallelism (mclapply from parallel) is supported, but that's mainly for expedience. Adding support for parSapply is feasible, but it usually leads to more cumbersome interfaces. Regards, Ivan
Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com
Hi Joshua, I did test some basic scenarios (mean) and compared against the results from runMean. Tested by.column=T/F, partial=T/F, cores=1/4. I didn't create test cases though. Certainly more testing is needed. As for the usage scenario, I was coding non-trivial filter on an indicator and first got tired converting forth and back to zoo. The parallelism came later, when I noticed my filter taking quite a while (minutes at this stage, but that will grow later) to compute. The filter takes all history at each step (partial=T, width=NROW(data)), then does some sampling (using one of the data columns decides which points are of interest) and then passes the sample to some logic, which is also expensive to compute (ML). Regards, Ivan On Sun Dec 21 2014 at 16:22:06 Joshua Ulrich <josh.m.ulrich at gmail.com> wrote:
Hi Ivan, Thanks for the contributions! Did you happen to test the partial=TRUE output versus rollapply.zoo? Also, can you share your use case for running rollapply in parallel? Best, Josh On Fri, Dec 19, 2014 at 11:05 PM, Ivan Popivanov <ivan.popivanov at gmail.com> wrote:
I needed these two features, and thought they might be useful in
general, so
I spent some extra time implementing them on top xts, see the
attachments.
Not sure whether I managed to cover all cases, but it should be a solid start if you decide adding them to the package. Note: Only the Unix form of parallelism (mclapply from parallel) is supported, but that's mainly for expedience. Adding support for
parSapply is
feasible, but it usually leads to more cumbersome interfaces. Regards, Ivan
-- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com