Make use of new Nemo method `mul!(a::ZZMPolyRingElem, b::QQMPolyRingElem, c::IntegerUnion)` once available

[fingolfin]

Once Nemocas/Nemo.jl#1994 is merged and in a Nemo release and that Nemo release is in Oscar, we should make use of the mul!(a::ZZMPolyRingElem, b::QQMPolyRingElem, c::IntegerUnion)

[lgoettgens]

Nemocas/Nemo.jl#1994 has been released as part of Nemo 0.49.0, which is available starting with Oscar 1.3.0

[SoongNoonien]

Currently, we have something like change_base_ring(ZZ, f) in place. But to be able to use mul! we would need to construct a compatible ZZMPolyRing first. Is there a standard way to do this?

[lgoettgens]

There is AbstractAlgebra._change_mpoly_ring(ZZ, parent(f), cached) which does exactly that. I wouldn't call it "a standard way", but this is what functions like change_base_ring use to construct the parent themselves.

Of course, you should only construct the parent once and re-use it for all f of the same parent.

[fingolfin]

in practice something like polynomial_ring(ZZ, symbols(parent(f)) should also work (possibly with cached kwarg provided as well)

[lgoettgens]

in practice something like polynomial_ring(ZZ, symbols(parent(f)) should also work (possibly with cached kwarg provided as well)

But this may have a different internal ordering

[fingolfin]

sure but you can also pass the ordering one. Alas in our case we use the default ordering anyway, so this is not a problem for us. We control all our inputs after all

[lgoettgens]

True. I think this then corresponds to just copying the body of AA._change_mpoly_ring

…

On March 21, 2025 10:05:32 AM GMT+01:00, Max Horn ***@***.***> wrote: fingolfin left a comment (oscar-system/GenericCharacterTables.jl#249) sure but you can also pass the ordering one. Alas in our case we use the default ordering anyway, so this is not a problem for us. We control all our inputs after all -- Reply to this email directly or view it on GitHub: #249 (comment) You are receiving this because you commented. Message ID: ***@***.***>