Drake: Combine the *StateVector hierarchy and the VectorBase hierarchy.

[amcastro-tri]

LeafSystemSateVector should be the last class in the hierarchy of state vectors. All the additional functionality from BasicStateVector can safely be moved up into LeafSystemStateVector.

This will allow us to access for instance to safely access the contiguous in memory Eigen representation for LeafSystems without unsafe dynamic_cast's.

[amcastro-tri]

cc'in @david-german-tri and @sherm1

[sherm1]

@amcastro-tri, see discussion in #3151. I would like to see VectorInterface extended to support "chunked" non-contiguous vectors and subvectors thereof. Then we can use that one abstraction exclusively for output ports, states, continuous state derivatives, etc. allowing us to get rid of the separate StateVector abstraction. That would also make it very straightforward to pump state variables (or some of them) out an output port.

[amcastro-tri]

I studied the code and it seems that the change we'd be suggesting would be:

1. VectorInterface would replace StateVector.
2. BasicVector would replace BasicStateVector and LeafStateVector (effectively merging them as suggested in this issue).
3. Make StateSupervector inherit the VectorInterface and rename it to something like SlicedVector.

After those changes we would have:

• BasicVector implementing VectorInterface for contiguous in memory vectors and SlicedVector for non-contiguous in memory vectors.
• We would get rid of all the State classes including: StateVector, StateSupervector, BasicStateVector and LeafStateVector greatly reducing the number of abstractions and hopefully simplifying our framework.

@david-german-tri and @sherm1 what do you think? should I execute?

[david-german-tri]

That (much larger!) set of changes would mean we can't provide get_value or get_mutable_value on VectorInterface anymore, because there wouldn't necessarily be an underlying Eigen type. That might actually be fine, though. The lack of those methods hasn't been a pain point for StateVector.

Nit: I think we should say Subvector and Supervector, not "SlicedVector" which sounds like it could mean either one.

[david-german-tri]

Reassigned to me based on off-thread discussion.

[sherm1]

I think we should say Subvector and Supervector, not "SlicedVector" which sounds like it could mean either one.

I was just going to say that -- :+1:. And those would both derive from VectorInterface, right? Would the hierarchy then be:

VectorInterface
  BasicVector // a single chunk, can have `get_[mutable_]eigen()` (or whatever)
  SuperVector // assembles multiple VectorInterfaces? 
  SubVector   // selects a subrange of a VectorInterface (so might be non-contiguous)

?

[david-german-tri]

Yes.

[david-german-tri]

Also, having gotten partway into this, it is clearly far too messy to do in one PR. There will be several pieces.

[sherm1]

Yes.

Awesome! I love that we can focus all our vector abstraction & performance attention on that one class family.

[david-german-tri]

3296 is the next phase of this migration. After that PR, we will have a single hierarchy:

  StateSupervector
  StateSubvector
  VectorBase
    BasicVector
      BasicStateVector
        BasicStateAndOutputVector

The next PR will delete BasicStateVector and BasicStateAndOutputVector. The PR after that will make Supervector and Subvector children of VectorBase. The final PR will fold StateVector into VectorBase.

[amcastro-tri]

The next PR will delete BasicStateVector and BasicStateAndOutputVector. The PR after that will make Supervector and Subvector children of VectorBase. The final PR will fold StateVector into VectorBase.

Just to be clear. Could you provide as you did above for #3296 how the hierarchy will look after that sequence of PR's is complete? Thanks!

[david-german-tri]

Could you provide as you did above for #3296 how the hierarchy will look after that sequence of PR's is complete?

Sure, it's what @sherm1 said above:

  BasicVector // contiguous, can have `get_[mutable_]eigen()` (or whatever)
  Supervector // assembles multiple VectorBases (so might be non-contiguous)
  Subvector   // selects a subrange of a VectorBase (so might be non-contiguous)

[david-german-tri]

3393 didn't get linked to this PR, and so I forgot I had done it. This issue is actually complete! 🎉