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
Recog is using ConvertToMatrixRep all over the place. I think it would make more sense to call it on the input (maybe after copying it first) of RecogniseGroup and similar functions and avoid it after that.
The text was updated successfully, but these errors were encountered:
I am not sure why that should be a goal in itself. What problem does it solve?
Note that these operations are very fast if the matrix is already in compressed form, but accidentally working with a non-compressed matrix can seriously wreck performance. At the same time, all kinds of matrix manipulations can (accidentally) cause the matrix to revert to uncompressed form, or to being a list-of-compressed-vectors. So at the very least, one would want to replace those calls with assertions that verify the matrix is still compressed.
That said, of course ideally the MatrixObj project would progress and we'd change recog to work with arbitrary MatrixObj implementations, and to use all the relevant MatrixObj APIs (resp. to add such APIs as we need them); and then during the progress on this, these ConvertToMatrixRep would indeed become dedundant...
Recog is using
ConvertToMatrixRep
all over the place. I think it would make more sense to call it on the input (maybe after copying it first) ofRecogniseGroup
and similar functions and avoid it after that.The text was updated successfully, but these errors were encountered: