search

oscar-system / Oscar.jl

A comprehensive open source computer algebra system for computations in algebra, geometry, and number theory.
https://www.oscar-system.org
Other
339 stars 120 forks source link

meaning of `iso_oscar_gap` (in particular for number fields) #2534

Closed ThomasBreuer closed 7 months ago

ThomasBreuer commented 1 year ago

Pull request #2511 has solved the problem that translating matrix groups over number fields from Oscar to GAP must be aware of recursive constructions of the number field on the Oscar side. Currently the same recursive construction is done on the GAP side. However, it would be more efficient for computations in GAP if the matrices would be defined over an extension of the Rationals.

If we agree that iso_oscar_gap promises an isomorphic object (in this situation, an isomorphic field) but that this function is not required to produce an object with compatible internal structure (in this situation, a field such that the base fields on the Oscar side and on the GAP side correspond to each other) then it is better to change the implementation such that iso_oscar_gap creates a (simple) absolute field on the GAP side.

If we do not agree on this point of view in general then we could still change the implementation of matrix groups over number fields such that a matrix group over an absolute simple number field is chosen on the GAP side.

What do you think?

thofma commented 1 year ago

We will have the same problem for the (new) finite fields, which can be arbitrary towers. How do you handle it there?

I am not quite sure what iso_oscar_gap(::NumField) will be used for in the future. Maybe at some point, on the GAP side it could call something like degree, and then things would go wrong (silently)?

ThomasBreuer commented 1 year ago

@thofma Yes, if the objects in Oscar and GAP are not "strongly isomorphic" in the sense that applying functions such as degree on both sides yields the same results then one is in trouble if one silently assumes such a correspondence. Because of this, we must document what one can expect from iso_oscar_gap. Already now, we cannot guarantee a full correspondence w.r.t. all functions; for example, GAP knows only simple field extensions.

micjoswig commented 7 months ago

I am going through everything marked "decision". That's why I comment on this only now.

The purpose of OSCAR is to create a system which is strictly more powerful than the cornerstones. So it does not make sense to insist on backward compatibility all the way. Make things fit between OSCAR and, e.g., GAP, if they fit. And keep them separate if they don't.

@ThomasBreuer If you agree, please close this ticket. Otherwise please ask specific question to proceed.

ThomasBreuer commented 7 months ago

O.k., I will just extend the warning that is already present in the documentation of iso_oscar_gap, essentially saying that one should better avoid iso_oscat_gap(R) for objects R whose recursive structure is not fully supported in GAP (for example non-simple field extensions), since their handling likely causes overhead at runtime.