Closed krcools closed 8 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
4c95579
) 99.68% compared to head (010ca9c
) 99.68%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
LGTM. Do you have a quick test case at hand? I believe we have BlockArrays.jl in our test dependencies anyway.
I have added a test with a triple product of LinearMaps over BlockArrays in nontradaxes.jl
It turns out that it requires four maps to hit that _resize
path. 😄
Thanks! That's a clear improvement, since otherwise there was no way to get this to work, right?
It turns out that it requires four maps to hit that
_resize
path. 😄
Thank you, I missed that the triple product would return before _resize
got hit.
Thanks! That's a clear improvement, since otherwise there was no way to get this to work, right?
I think so, that was my motivation to submit the PR. A better solution is probably to implement _resize
only for Vector
, as I understand from the Julia coding recommendations that exception handling is rather expensive...
When using subtypes of
AbstractVector
that do not supportresize!
(such asBlockArrays.PseudoBlockVector
), the memory optimisation in the_unsafe_mul!
for composite maps result in errors.I have changed
_resize
to allways fall back to memory allocation viasimilar
, whereas previously this only happened when the argument was aSharedArrays.SharedVector
.