WIP: Adds operator Base.:*(::ToeplitzFactorization, ::StridedVector) #103
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For performing many Toeplitz-vector products using the same matrix, it is efficient to reuse the factorization of the Toeplitz matrix. The README suggests that this is intended, however it's not documented how to do it. I found out (1, 2) that this works:
The method facilitating this is
Besides being undocumented, it modifies the
temp
buffer inside the factorizationA
. This doesn't invalidate the factorization object (because the buffer is "temporary", I guess) but the method is not thread-safe. I think the way to make it thread-safe is to make a copy of thetmp
buffer and thus not changing it. However, this obviously has an unwanted performance overhead and I don't know if thread-safety of the method (is it internal? is exporting it intented) is desired. I also didn't look at other similar methods.I suggest possible measures including
mul!
method thread safe, perhaps controlled by a parameter making it thread-safe by default but avoiding the copy when the factorization is not being reusedBase.:*(::ToeplitzFactorization, ::StridedVector)
that is thread-safe.I implemented a suggestion for measure 2. I added comments indicating how one may approach measure 1. What do you think?
The code is not ready to merge, it has a lot of comments that should be removed and additional unit tests that illustrate my points, rather than properly testing functionality.