Always use similar as fallback when resize throws in applying composite maps

[krcools]

When using subtypes of AbstractVector that do not support resize! (such as BlockArrays.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 via similar, whereas previously this only happened when the argument was a SharedArrays.SharedVector.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (4c95579) 99.68% compared to head (010ca9c) 99.68%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #221      +/-   ##
==========================================
- Coverage   99.68%   99.68%   -0.01%     
==========================================
  Files          22       22              
  Lines        1591     1589       -2     
==========================================
- Hits         1586     1584       -2     
  Misses          5        5              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dkarrasch]

LGTM. Do you have a quick test case at hand? I believe we have BlockArrays.jl in our test dependencies anyway.

[krcools]

I have added a test with a triple product of LinearMaps over BlockArrays in nontradaxes.jl

[dkarrasch]

It turns out that it requires four maps to hit that _resize path. 😄

[dkarrasch]

Thanks! That's a clear improvement, since otherwise there was no way to get this to work, right?

[krcools]

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...