Add a vector class to GridKit

[pelesh]

Description

Add vector class to GridKit to replace std::vector and provide portable data management.

Proposed changes

The LinearAlgebra::Vector class was ported from Re::Solve. It has basic initialization and data management functionality. I can be use as a vector, multivector or vector view class.

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• I have updated CHANGELOG.md to reflect the changes in this PR. If this is a minor PR that is part of a larger fix already included in the file, state so.

Further comments

The multivector capability in this class should replace DenseMatrix object in GridKit.

[PhilipFackler]

For an all-in-one solution like this, I would prefer some revisions as explained in my line comments. None of those is a deal-breaker if this is meant only for "advanced" use-cases, but I still think it would be helpful.

[PhilipFackler]

This would need a default constructor for use in the phasor dynamics initialization.

[pelesh]

With default constructor, we would need allocate and/or reallocate methods, as well.

[PhilipFackler]

It doesn't make sense for allocating to be part of the semantics of this function. It certainly wouldn't be obvious to me as a user that this might happen. I'm used to having no implicit memory operations, only explicit (the user has to say so). This should at least be documented if not reconsidered.

[pelesh]

Yes, you are right, this should be removed.

[PhilipFackler]

This would make more sense as part of a constructor. An instance should be constructed with ownership and data (if non-owning) for host and device respectively. Ownership should not be allowed to change. And I think the data you're wrapping in the non-owning case shouldn't be allowed to change either. This function wouldn't exist in that case.

[pelesh]

I agree, changing ownership after construction is looking for trouble.

This method was experimental and should not be a part of the vector class.

[pelesh]

This method was used to get a vector from a multivector. Better solution is to construct non-data-owning vector object instead, or create a separate VectorView object as @lukelowry suggested.

[PhilipFackler]

This ignores the case where we're already non-owning. See my comment above. If ownership was settled at construction there could be tighter invariants for the rest of these functions.

[pelesh]

I think it would be good to have allocate and reallocate methods, both refusing to operate on data if not owned by the vector object.

• allocate should return error message and do nothing if data pointer is not null.
• reallocate should check if the new size is larger than capacity and if so delete previous and allocate new data.

[pelesh]

For an all-in-one solution like this, I would prefer some revisions as explained in my line comments. None of those is a deal-breaker if this is meant only for "advanced" use-cases, but I still think it would be helpful.

All of your suggestions are spot on and should be incorporated before this PR is merged.