search

gap-system / gap

Main development repository for GAP - Groups, Algorithms, Programming, a System for Computational Discrete Algebra
https://www.gap-system.org
GNU General Public License v2.0
810 stars 160 forks source link

change the way how `ImmutableVector` and `ImmutableMatrix` are used #5231

Open ThomasBreuer opened 1 year ago

ThomasBreuer commented 1 year ago

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 syntax Vector( v, w ) is intended, where w is a sample vector of the nice type, and v is the input vector for which the conversion to the type of w 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 by Vector( v, w ) calls. For that, it would be useful to admit the Vector( v, w ) syntax also for the case that w is a plain list.

For example, the code that deals with the coefficient vectors stored in elements of fields created with AlgebraicExtension needs ImmutableVector 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 of v and/or w. In many places in the library, one wants immutable results, w is immutable, and v 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)

ThomasBreuer commented 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).