Bump dependencies

[lgoettgens]

cc @thofma @fingolfin

Closes Nemocas/Nemo.jl#1722.

Waiting for:

• Merge hom and Generic.hom Nemocas/AbstractAlgebra.jl#1699
• Try to sort out the homs Nemocas/AbstractAlgebra.jl#1700
• Try to sort out the homs thofma/Hecke.jl#1488
• Fix docs thofma/Hecke.jl#1491

[lgoettgens]

I now added base_ring_type methods for many of the already existing base_ring methods. In algebraic geometry, I got a bit lost and skipped some. So let's hope that CI passes anyway.

[lgoettgens]

I know of some other stuff that needs to be adjusted here. Possibly getting to it tomorrow

[fingolfin]

Needs a rebase anyway

[fingolfin]

It seems this does not yet have the QQBarField disambiguation method for Polymake code

[fingolfin]

I merged master (hopefully resolved the conflicts in src/aliases.jl correctly) and added a QQBarFieldElem disambiguation.

However there is still a precompilation "warning" / error:

WARNING: Method definition hom(Hecke.FinGenAbGroup, Hecke.FinGenAbGroup, Array{var"#s685", 1} where var"#s685"<:(AbstractAlgebra.Map{Hecke.FinGenAbGroup, Hecke.FinGenAbGroup, S, T} where T where S)) in module Hecke at /Users/mhorn/.julia/packages/Hecke/56bDu/src/GrpAb/GrpAbFinGen.jl:990 overwritten in module Misc at /Users/mhorn/Projekte/OSCAR/Oscar.jl/experimental/GModule/Misc.jl:257.

Looking at the two methods, they indeed have identical signature but one implements a tensor produce and one a direct product?!

[fingolfin]

(CC @ThomasBreuer and @fieker as they may know best what to do about the hom method in experimental/GModule/Misc.jl vs. that in Hecke)

[lgoettgens]

(CC @ThomasBreuer and @fieker as they may know best what to do about the hom method in experimental/GModule/Misc.jl vs. that in Hecke)

This error is due to me renaming this from direct_sum to hom in spite of Nemocas/AbstractAlgebra.jl#1675 (comment). We could just merge both of these functions to a single one that decides which construction to use depending on the if G is a direct sum or tensor product.

See thofma/Hecke.jl#1483 for the proposal.

[thofma]

I think it is problematic that we now have to write methods for objects of some T and then we have to distinguish between how they were constructed. It is rather error prone.

This will only get worse, since there are also hom(G, H, vector), where H is a direct product and vector homomorphisms of G into the single components of H (aka universal property).

Clearly if I intend to do hom(G, H, vector_of_morphisms), I just constructed G and H as say tensor products, and then hom_tensor_product(G, H, vector_of_morphisms) makes more sense I would say. (Or some name containing the word "tensor").

[lgoettgens]

I think it is problematic that we now have to write methods for objects of some T and then we have to distinguish between how they were constructed. It is rather error prone.

This will only get worse, since there are also hom(G, H, vector), where H is a direct product and vector homomorphisms of G into the single components of H (aka universal property).

Clearly if I intend to do hom(G, H, vector_of_morphisms), I just constructed G and H as say tensor products, and then hom_tensor_product(G, H, vector_of_morphisms) makes more sense I would say. (Or some name containing the word "tensor").

That was exactly my point in Nemocas/AbstractAlgebra.jl#1675 (comment). Let's wait for @ThomasBreuer and @fieker to comment on this. In any way, the functions for FinGenAbGrp and FPModule should be named the same, so in the worst case we need to rename the thing in AA again.

[fieker]

On Thu, May 02, 2024 at 06:29:12AM -0700, Lars Göttgens wrote: @lgoettgens commented on this pull request. > @@ -53,8 +53,8 @@ julia> R, (x, y) = polynomial_ring(K, ["x", "y"]); julia> F = hom(R, R, z -> z^2, [y, x]) Ring homomorphism - from multivariate polynomial ring in 2 variables over GF(2, 2) - to multivariate polynomial ring in 2 variables over GF(2, 2) + from multivariate polynomial ring in 2 variables over K + to multivariate polynomial ring in 2 variables over K This is one case where I don't like the name printing. Could/should we make an exception for finite fields (as we already do for the singletons like `QQ`)?

Why? You named the ring K? Or is it about not just printing Ring homomorphism from R to R? Which is what I'd like to see here... Mind you, GF(2,3) is not neccessarily the same as GF(2, 3), they can come with different polynomials, and cached or not. You're taste (not you as in you, but in general) is always very local. For this output on this day, I really like (or not) this printing. If we want to be consistent, then either all parent need to support named printing - or none. Here it looks like: (some) people really like ti (mostly when dealing with complicated rings), while some have always hated it... We can also choose to be not consistent... (I was bitten today by groups: the output basically was I am a group of type bla - very informative. To see more I need to ask for what I want to see....)

…

-- Reply to this email directly or view it on GitHub: #3667 (review) You are receiving this because you were mentioned. Message ID: ***@***.***>

[thofma]

@lgoettgens did you disable the tests with the problematic hom things?

[lgoettgens]

@lgoettgens did you disable the tests with the problematic hom things?

Yes, the GModule tests (exercising the "wrong" hom function) and the Aqua tests (failing because of method overwriting) are currently disabled to find everything else that needs to be adapted

[codecov]

Codecov Report

Attention: Patch coverage is 33.33333% with 24 lines in your changes are missing coverage. Please review.

Project coverage is 83.12%. Comparing base (2df8126) to head (cd10f0a).
Report is 7 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3667      +/-   ##
==========================================
- Coverage   83.13%   83.12%   -0.01%     
==========================================
  Files         577      577              
  Lines       78347    78306      -41     
==========================================
- Hits        65130    65091      -39     
+ Misses      13217    13215       -2     

Files	Coverage Δ
experimental/GModule/GModule.jl	59.36% <ø> (ø)
experimental/GModule/Misc.jl	44.69% <ø> (-6.19%)	⬇️
experimental/LieAlgebras/src/LieAlgebras.jl	100.00% <ø> (ø)
experimental/ModStd/src/ModStdQt.jl	57.29% <ø> (ø)
experimental/Schemes/CoveredProjectiveSchemes.jl	88.40% <ø> (ø)
experimental/Schemes/duValSing.jl	100.00% <ø> (ø)
src/Combinatorics/SimplicialComplexes.jl	94.95% <ø> (ø)
src/Modules/ModuleTypes.jl	78.90% <ø> (ø)
src/Modules/UngradedModules/FreeMod.jl	84.00% <ø> (ø)
src/Modules/UngradedModules/FreeModElem.jl	95.74% <ø> (ø)
... and 31 more

... and 7 files with indirect coverage changes