New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify VectorArray implementations #1584
Conversation
e27832a
to
cf4e6bd
Compare
Codecov Report
|
:class:`BlockVectorArray` can be used in conjunction with | ||
:class:`~pymor.operators.block.BlockOperator`. | ||
""" | ||
class BlockVectorArrayImpl(VectorArrayImpl): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this class referenced elsewhere in a docstring? Should it get one that maybe just refers to the VectorArrayImpl
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it isn't. I don't think that adding a docstring here is necessary since a regular user should not be exposed to this class. I'd rather require docstrings also for internal classes.
:class:`~pymor.bindings.ngsolve.NGSolveVector` and | ||
:class:`~pymor.bindings.ngsolve.NGSolveVectorSpace`. | ||
""" | ||
class ListVectorArrayImpl(VectorArrayImpl): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as BlockVectorArrayImpl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my response above.
return self.__class__([v.conj() for v in self._list], self.space) | ||
|
||
class ListVectorArray(VectorArray): | ||
"""|VectorArray| implemented as a Python list of vectors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refer to the Impl
here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For similar reasons as above, I'd prefer to not do it.
Same comments for the MPI and numpy arrays too. |
Looks good. However, could you give a brief motivation for this change? Do I understand it correctly that more work is done in the base classes and less work needs to be done in the actual implementations (bluntly speaking)? |
The main reason is that the current implementations are quite complicated and it seems daunting to implement a new |
This refactors
VectorArray
to defer all interface methods to operations on an internalVectorArrayImpl
object.VectorArray
itselfs manages copy-on-write semantics, the handling ofproduct
arguments, error checking and the handling of views.Additionally the following changes have been made:
VectorObjects
stored in aListVectorArrays
is now provided via thevectors
property. The old name_list
is deprecated.BlockVectorArray
can be accessed via theblocks
property. No copy is made. Theblocks
method and thenum_blocks
property have been deprecated. To ensure that the user does not append to/delete from blocks they have accessed viaU.blocks
each method ofBlockVectorArrayImpl
now asserts_blocks_are_valid
which produces a helpful error message.