Open ThomasBreuer opened 1 year ago
Concerning the mutability of the results of Vector( v, w )
and Matrix( v, w )
,
currently my favourite definition is that the result is immutable if and only if v
is immutable.
That is, the (mutability of the) first argument determines the mutability of the result, and the second argument determines the BaseDomain
and internal representation of the result.
This way, Vector
is not forced to make a mutable or immutable copy of v
in those cases where v
gets wrapped in some vector object; note that the documentation of Vector
states already that it is not guaranteed that a given list of entries will be copied.
For Matrix
, the situation is a bit different, the documentation says
It is guaranteed that the given list list is copied in the sense of ShallowCopy (12.7-1). If list is a nested list then it is not guaranteed that also the entries of list are copied.
I think that this statement makes sense only if the input list is mutable (or if the result has to be mutable on the outer level).
Currently
ImmutableVector
is used in situations where one wants to replace a given vector by a better one, from the viewpoint of the internal representation. In the context of vector objects, this is not exactly what one wants to achieve. One of the ideas behind vector objects is that one wants to create new vectors in a representation that fits to the one of a given vector. For that, the syntaxVector( v, w )
is intended, wherew
is a sample vector of the nice type, andv
is the input vector for which the conversion to the type ofw
is returned.The
ImmutableVector
calls in GAP library code belong to two different situations: Those (few!) cases where initial vectors get created can remain as they are, for the moment. And those where one wants to get a vector that fits to a known one should be replaced byVector( v, w )
calls. For that, it would be useful to admit theVector( v, w )
syntax also for the case thatw
is a plain list.For example, the code that deals with the coefficient vectors stored in elements of fields created with
AlgebraicExtension
needsImmutableVector
only in one place, where the first element gets constructed and stored in the elements family of the field; all coefficient vectors created later on can/should be constructed w.r.t. this first vector.If nobody objects then I will create a pull request that implements these changes.
An open question: Currently it is not specified whether the return value of
Vector( v, w )
is mutable or not, perhaps depending on the mutability ofv
and/orw
. In many places in the library, one wants immutable results,w
is immutable, andv
has just been created and is usually mutable (but can be made immutable in place without much overhead). What shall we define?(
ImmutableMatrix
should be handled analogously.) (See also issues #5030 and #5181)