MechanismState(mechanism, q, v) should accept AbstractVector q and v

[rdeits]

No description provided.

[tkoolen]

Hmm, so an issue with this is that currently, the q and v that are passed in are not copied, but instead become the backing arrays of SegmentedVectors stored in MechanismState. While SegmentedVector is parameterized on the type of its backing array, I don't want to parameterize MechanismState on the type of q and v.

In your specific use case, you were passing SegmentedVectors into the MechanismState constructor, which could be supported (just use the SegmentedVector straight away after checking that the ranges match the Mechanism), but I think support for general AbstractVectors would result in confusing behavior, as in some cases modifying the q and v inputs after creating the MechanismState would modify the state (the current behavior), while in other cases the MechanismState constructors would have to create a Vector copy of q and v, thus losing the connection between the q and v input and the state.

So the three options are:

1. only support Vector, i.e. leave things as they are now
2. add support for SegmentedVector only
3. add support for AbstractVector, but always make a copy of the input arguments.

Which one do you prefer?

[rdeits]

Makes sense. I agree that having ambiguity about whether a copy is made is undesirable. What about having the constructors that take q, v, and s just be simple wrappers that do:

m = MechanismState(mech)
set_configuratuon!(m, q)

so that we can accept any abstract vector with no ambiguity about whether a copy is made?

I guess the only question is whether it is ever useful to construct a mechanism state whose q and v are shared with some other struct? I think it's not, and it would screw up the caching anyway.

[rdeits]

So I think I prefer option 3