Feat: change internal handling of Zero in hstack/vstack

[mrava87]

Motivation

PyLops' stacking operators allow one to pass PyLops multiple LinearOperators or numpy/scipy matrices. However, in many practical scenarios, especially for the Block Operator, one may have some zero blocks (either many small ones or few large ones). Currently, one must rely on pylops.Zero to fill those zero blocks. However the inner working of pylops.Zero is such that every time matvec/rmatvec is called a zero array is instantiated. For stacking operators, this is actually redundant as one could simply skip filling part of the output vector. The current approach is particularly problematic when using the CuPy backend as instantiating new arrays on GPU memory is tremendously slow and unefficient (compared to performing arithmetic operations).

To solve this issue, this PR proposes to add a check prior to calling the matvec/rmatvec of an operator and skip it if the operator is of instance Zero

Definition of Done

• Modify HStack
• Modify VStack
• Add tests

⏰ This is a much simpler solution to the one initially proposed in #699

[cako]

LGTM! I will leave it as approved but I suggest including this behavior in the class documentation and/or the gallery examples. It is important for people to know that if they use the proper operators (Zero as opposed to e.g., MatrixMult) they will get performance benefits.

Also, seems like no need for me to review #699?

[mrava87]

Thanks!

Sure, let me add something to the example like I had done inhttps://github.com//pull/699

And yes, no need to look at #699... after I implemented that way I started to feel it was an overkill given the minimal overhead of Zero at initialization time, what we want to avoid is calling the matvec/rmatvec.