Multiplication in local fields spends most of the time in multiplying ramification index with the valuation

[simonbrandhorst]

might be worth investigating at some point
@joschmitt

     ╎    ╎    ╎    ╎    ╎    ╎   118   @Hecke/src/LocalField/Elem.jl:648; mul!(c::Hecke.LocalFieldElem{QadicFieldElem, Hecke.EisensteinLocalField}, a::Hecke.LocalFieldElem{Qadi…
     ╎    ╎    ╎    ╎    ╎    ╎    118   @AbstractAlgebra/src/Fraction.jl:337; *(a::Int64, b::QQFieldElem)
     ╎    ╎    ╎    ╎    ╎    ╎     118   @Nemo/src/flint/fmpz.jl:349; divexact
     ╎    ╎    ╎    ╎    ╎    ╎    ╎ 118   @Nemo/src/flint/fmpz.jl:353; divexact(x::ZZRingElem, y::ZZRingElem; check::Bool)
   97╎    ╎    ╎    ╎    ╎    ╎    ╎  118   @Nemo/src/flint/FlintTypes.jl:47; ZZRingElem

[joschmitt]

This should be a bit better with Nemocas/Nemo.jl#1776 .
We could probably improve it more depending on the type of the field by providing a normalization (or whatever the name will be) keyword for valuation that already does the scaling by the ramification index; and then saves the multiplication for an unramified extension.
If we have this, we could add a type parameter like valuation(Int, ...) that computes the valuation as an Int (or throws an error if it is to big / a fraction). Currently, a lot of time in mul! is spent converting to Int, so that might save a bit for some field types.
However, I don't think we can do something useful in both cases for generic LocalField types where the valuation is computed as "valuation of norm divided by degree":

Hecke.jl/src/LocalField/Elem.jl

Line 343 in 32b8b74

return valuation(norm(a))//degree(parent(a))

Thoughts?

[fieker]

On Thu, Jun 06, 2024 at 12:55:07AM -0700, Johannes Schmitt wrote: This should be a bit better with Nemocas/Nemo.jl#1776 . We could probably improve it more depending on the type of the field by providing a `normalization` (or whatever the name will be) keyword for `valuation` that already does the scaling by the ramification index; and then saves the multiplication for an unramified extension. If we have this, we could add a type parameter like `valuation(Int, ...)` that computes the valuation as an `Int` (or throws an error if it is to big / a fraction). Currently, a lot of time in `mul!` is spent converting to `Int`, so that might save a bit for some field types. However, I don't think we can do something useful in both cases for generic `LocalField` types where the valuation is computed as "valuation of norm divided by degree": https://github.com/thofma/Hecke.jl/blob/32b8b74fbd235693924cba5bfd521f1398dc65bf/src/LocalField/Elem.jl#L343 Thoughts?

Its a fundamental problem in local stuff: the valuation is "unique", but how depends on the context. There are two canonical choices for the unique valuation - surject onto Z - extend the p-adic one Both are canonical, well defined and useful. We (Carlo) chose the 2nd, while precision is following the 1st. I don't know if the problem is the choice of valuation or the different approach for precision...

…

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