You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now every matrix type has it's own set of classes; CommonOps_DDRM, CommonOps_ZDRM, CommonOps_DSCC, ... etc. Then if you want to call concurrent implementations you have to call another variant, i.e. CommonOps_MT_DDRM. Currently the only way to hide this complexity is to use SimpleMatrix. However, that only supports a few functions and you lose control over memory management.
To make people's lives easier, I'm proposing CommonOps (and other similar named classes) that will support most of the Procedural API for all matrix types in a single location. It will also handle automatic switching to concurrent implementations when the matrix size is large enough and handle workspace variables using ThreadLocal.
That's the working branch for this work. One issue that has become apparent is that an automated procedure for either checking that all functions have been brought over or to generate CommonOps itself. The goal for the next release is to have just enough functionality to run in JavaMatrixBenchmark. Threaded implementations have yet to be run in that public benchmark because there was no easy way to use them.
The text was updated successfully, but these errors were encountered:
The main motivation for me is that when I want to use concurrent implementations but still have the ability to turn it off in downstream libraries there is no way to do that without manually coding it up yourself. This will solve that problem. Plus needing to handle workspace is annoying.
While no one has complained, I think having the Procedural API require knowing all these suffixes makes it difficult for people to get started.
I can also say, that when first looking at EJML, the suffixes also got me confused.
AFAIK, you also explained the suffixes in the docs, so after a first confusion, it is straight-forward to navigate.
My main concern would be that this will lead to large files which are harder to navigate.
But in general, I think this would be a good improvement :)
Right now every matrix type has it's own set of classes; CommonOps_DDRM, CommonOps_ZDRM, CommonOps_DSCC, ... etc. Then if you want to call concurrent implementations you have to call another variant, i.e. CommonOps_MT_DDRM. Currently the only way to hide this complexity is to use SimpleMatrix. However, that only supports a few functions and you lose control over memory management.
To make people's lives easier, I'm proposing CommonOps (and other similar named classes) that will support most of the Procedural API for all matrix types in a single location. It will also handle automatic switching to concurrent implementations when the matrix size is large enough and handle workspace variables using ThreadLocal.
https://github.com/lessthanoptimal/ejml/tree/feature/fancy_ops
That's the working branch for this work. One issue that has become apparent is that an automated procedure for either checking that all functions have been brought over or to generate CommonOps itself. The goal for the next release is to have just enough functionality to run in JavaMatrixBenchmark. Threaded implementations have yet to be run in that public benchmark because there was no easy way to use them.
The text was updated successfully, but these errors were encountered: