Last November I reached out about a speed issue regarding the colsums and rowsums functions, noting that parallel performance over integer matrices wasn't nearly as efficient as it should have been. It turned out this was because there wasn't a proper case defined for integers in the parallel functions, and the issue was quickly resolved by adding proper support for integers for these functions.
That said, the solution to this issue begs the question - was this an isolated issue with this function alone, or is this a systematic issue with the functions in this package? This question's been on my mind since then, and after finally getting around to perusing this package's source code and running some benchmarks it does appear to have been the latter. In short, while I haven't reviewed the source code for nor benchmarked every function, lack of integer type support appears to be an issue with most functions in this package, and while not as pressing, it's also worth noting that there currently doesn't appear to be any complex type support implemented at all for any of these functions.
In light of this, I'm inclined to request a systematic review of all functions in this package, with the goal of adding proper integer and complex type support for all relevant package functions (ideally / preferably starting with the column / row-wise functions - i.e. colMedians / rowMedians, colmeans / rowmeans, colMads / rowMads, etc.). Adding proper integer support for all package functions should improve performance of all functions over integer vectors / matrices just as it did for the parallelized versions of colsums / rowsums, and adding proper complex type support seems sensible as well, as it would allow these functions to be used on all relevant vector / matrix types.
Last November I reached out about a speed issue regarding the colsums and rowsums functions, noting that parallel performance over integer matrices wasn't nearly as efficient as it should have been. It turned out this was because there wasn't a proper case defined for integers in the parallel functions, and the issue was quickly resolved by adding proper support for integers for these functions.
That said, the solution to this issue begs the question - was this an isolated issue with this function alone, or is this a systematic issue with the functions in this package? This question's been on my mind since then, and after finally getting around to perusing this package's source code and running some benchmarks it does appear to have been the latter. In short, while I haven't reviewed the source code for nor benchmarked every function, lack of integer type support appears to be an issue with most functions in this package, and while not as pressing, it's also worth noting that there currently doesn't appear to be any complex type support implemented at all for any of these functions.
In light of this, I'm inclined to request a systematic review of all functions in this package, with the goal of adding proper integer and complex type support for all relevant package functions (ideally / preferably starting with the column / row-wise functions - i.e. colMedians / rowMedians, colmeans / rowmeans, colMads / rowMads, etc.). Adding proper integer support for all package functions should improve performance of all functions over integer vectors / matrices just as it did for the parallelized versions of colsums / rowsums, and adding proper complex type support seems sensible as well, as it would allow these functions to be used on all relevant vector / matrix types.