Add something like GAP'sExtRepOfObj + ObjByExtRep or Magma's Eltseq to Oscar?

[fingolfin]

In GAP there is a function ExtRepOfObj which can be applied to many kinds of objects: words of fp groups, elements of f.d. algebras or Lie algebra, polynomials¹ etc.) and which turns that into a "basic" object (consisting of just "basic" types like lists, integers, dictionaries, ...) which is easy to process and transform. This can then be turned back into an object with a function ObjByExtRep.

In Magma there is a similar concept via Eltseq and parent(data).

The main thing interesting about these functions is that due to their uniform name, it is really easy to "find" them. In contrast, in OSCAR you'll need a bit to figure out syllables and letters exist to turn a free group element into such a "basic" obejct, and afterwards you still might have a hard time figuring out how to turn them back into group elements.

So we were wondering if we should think about adding something in this vein to OSCAR. For the sake of discussion, let's suppose they are called as data = ext_rep(x) and obj_by_ext_rep(parent(x), data) (or maybe we can just require the converse to be parent(x)(data) resp. someParentObject(data) )

We could implement this with just a few types to start, but the list could grow if the concept is useful. This wouldn't replace existing functions like letters or coefficients but rather complement them. E.g. we could even have

"""
    ext_rep(x::FPGroupElem)

Alias for `syllables`, see there for information about the format it returns.
"""
ext_rep(x::FPGroupElem) = syllables(x)

• footnote 1: actually for polynomials in GAP one has to use ExtRepPolynomialRatFun / ExtRepNumeratorRatFun / ExtRepDenominatorRatFun but that's for a reason that doesn't apply to us: GAP, univariate and multivariate polynomials and rational functions all have the same type. So you have to convey in the function name that you want to regard an object "as a polynomial".

[lgoettgens]

stupid question: coefficients usually returns a vector of base_ring elements. Do we already consider this "a "basic" object (consisting of just "basic" types like lists, integers, dictionaries, ...) ", or would this be called recursively?

[thofma]

another stupid question: this sound like reinventing serialization/deserialization without all the safety guarantees?

Edit: I heavily use Eltseq in Magma, because I find the "Serialization" in Magma lacking and to communicate with other systems. I hope this explains my stupid question.

[fieker]

On Thu, Sep 26, 2024 at 05:42:34AM -0700, Tommy Hofmann wrote: another stupid question: this sound like reinventing serialization/deserialization without all the safety guarantees?

Yes/no/maybe. In many situations that allows for easy manipulation within a session. Starting point here really was my "quest" to deal with group extensions. Here fundamentally I have two free groups and I need the map, efficiently, that maps G[i] -> H[i+N] Thus enter sylables, word, letters and the reverse Thus the question of putting as many of them as useful under the "same" name, think Eltseq in magma...

…

-- Reply to this email directly or view it on GitHub: #4151 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[ThomasBreuer]

Concerning the relation between serialization and the proposed new concept:

The main aims of defining an "external representation" of an object are to create an object of the type in question from simpler ingredients and to map an object to these ingredients.
Contrary to the situation with serialization, the simpler ingredients can still be complicated objects having parents etc., for example coefficients which are finite field elements or elements in some number field;
one can also use Julia objects such as tuples in order to describe the ingredients.

Claus' example shows this nicely: Take a group element that is essentially given by some word, extract this word-like information, perhaps modify the data, and finally turn the result again into a group element, perhaps of a different group of a perhaps different type.
(In this particular case, it is not clear to me whether this approach is actually what one wants. In the situation of last week, the objects are Oscar group elements given by words in the GAP world, and a lot of intermediate objects get created by first unpacking them into some GAP list, then converting this to the external representation in Julia, modifying this in Julia, converting the result back to a GAP list, creating a new GAP word, and finally wrapping this into a new Oscar group element.)

If the external representation of an object corresponds to the defining fields of the object then creating the object is cheap (use a keyword argument check = false), provided that one need not make a copy of the input data. That is, it should be left to the user to create copies if necessary before calling the function that creates the object from its external representation.

[ThomasBreuer]

One more thought:
Creating an object from an "external representation" is not expected to perform normalizations of its input, such as dealing with cancellation or overflow that arise from the manipulations in the "external representation".
Thus the function that creates an object from "external representation" data must check whether the input is really valid (i.e., can occur as an "external representation"), except if a check = false argument is given.