Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move code from Oscar.jl/experimental/GModule/Misc.jl here #1456

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ThomasBreuer
Copy link
Contributor

The idea is to add this code to Hecke.jl,
and then to remove it from Oscar.jl.

Once we agree what shall be really added here,
tests and documentation has to be added.
(I am quite sure that I have put certain parts into the wrong files, and that some functions have to be changed.
For example:

  • The function dual belongs to Hecke.jl, but the method in question deals with objects from AbstractAlgebra.jl; should dual better get defined in AbstractAlgebra.jl?
  • pseudo_inv is defined in AbstractAlgebra.jl, the method in question uses MapFromFunc, which belongs to Hecke.jl; what is the relation between Hecke.jl's MapFromFunc and AbstractAlgebra.jl's FunctionalMap?)

The idea is to add this code to Hecke.jl,
and then to remove it from Oscar.jl.

Once we agree what shall be really added here,
tests and documentation has to be added.
(I am quite sure that I have put certain parts into the wrong files,
and that some functions have to be changed.
For example:
- The function `dual` belongs to Hecke.jl, but the method in question deals with objects from AbstractAlgebra.jl; should `dual` better get defined in AbstractAlgebra.jl?
- `pseudo_inv` is defined in AbstractAlgebra.jl, the method in question uses `MapFromFunc`, which belongs to Hecke.jl; what is the relation between Hecke.jl's `MapFromFunc` and AbstractAlgebra.jl's `FunctionalMap`?)
@thofma thofma closed this Apr 30, 2024
@thofma thofma reopened this Apr 30, 2024
Copy link

codecov bot commented Apr 30, 2024

Codecov Report

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

Project coverage is 75.07%. Comparing base (1efdecf) to head (0fc7061).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1456      +/-   ##
==========================================
- Coverage   75.21%   75.07%   -0.14%     
==========================================
  Files         354      354              
  Lines      112712   112844     +132     
==========================================
- Hits        84771    84720      -51     
- Misses      27941    28124     +183     
Files Coverage Δ
src/GrpAb/Map.jl 77.70% <0.00%> (-0.28%) ⬇️
src/LocalField/map.jl 80.22% <0.00%> (-0.31%) ⬇️
src/Map/NumberField.jl 72.34% <0.00%> (-0.20%) ⬇️
src/NumField/ComplexEmbeddings/Generic.jl 98.97% <0.00%> (+1.04%) ⬆️
src/NumField/ComplexEmbeddings/QQ.jl 88.46% <0.00%> (-3.54%) ⬇️
src/NumFieldOrd/NfOrd/Ideal/Relative.jl 89.87% <0.00%> (-0.58%) ⬇️
src/Map/Map.jl 41.17% <0.00%> (-1.25%) ⬇️
src/GrpAb/Elem.jl 94.15% <0.00%> (-2.26%) ⬇️
src/NumField/NfAbs/Elem.jl 68.28% <0.00%> (-1.57%) ⬇️
src/Misc/RatRecon.jl 17.94% <0.00%> (-0.86%) ⬇️
... and 3 more

... and 31 files with indirect coverage changes

@lgoettgens lgoettgens mentioned this pull request May 1, 2024
@fingolfin
Copy link
Contributor

Can we get this merged? Or is there any serious blocker (perhaps dual should be moved to AA -- or not. But surely we can decide that later? In the meantime having it here is already better than having it only in Oscar).

@thofma @fieker @lgoettgens any thoughts on this?

@lgoettgens
Copy link
Contributor

It is not in a form to get merged

(in #1482 (comment) by @thofma)

For groups `G = prod G_i` and `H = prod H_i` as well as maps `V_i: G_i -> H_i`,
build the induced map from `G -> H`.
"""
function direct_sum(G::FinGenAbGroup, H::FinGenAbGroup, V::Vector{<:Map{FinGenAbGroup, FinGenAbGroup}})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is already added in #1488 under the name hom_direct_sum. Once #1488 gets merged, this should get removed here.

@thofma
Copy link
Owner

thofma commented May 3, 2024

Can we get this merged? Or is there any serious blocker (perhaps dual should be moved to AA -- or not. But surely we can decide that later? In the meantime having it here is already better than having it only in Oscar).

@thofma @fieker @lgoettgens any thoughts on this?

If the things do not belong in Oscar, and they do not belong here, I don't understand why it is better to have them here.

If there is an urgency to move this, at least remove the one export statement that is added.

@fingolfin
Copy link
Contributor

There is no urgency in this from my POV, it just seems prudent to move it along eventually... But I think @ThomasBreuer is busy working on other things right now, and hopefully can back to this once those other things are done.

@@ -293,6 +293,12 @@ function (A::FinGenAbGroup)(x::ZZMatrix)
return z
end

function (A::FinGenAbGroup)(x::FinGenAbGroupElem)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ThomasBreuer @fieker so this is the function we talked about this morning, which is the reason (or at least a reason) why the GModule tests are run in Oscar even when "exclude experimental" is active...

But this PR here is waiting for @ThomasBreuer to finish it up -- then we can make a Hecke release, adjust Oscar, and perhaps get rid of that hack in Oscar....

@lgoettgens
Copy link
Contributor

As a first step, the code could be moved from experimental/GModule/ to https://github.com/oscar-system/Oscar.jl/blob/master/src/Misc/MoveToHecke.jl. Then we can have the discussion about the contents elsewhere, and without the pressure of doing a breaking Hecke release right after the merge

@ThomasBreuer
Copy link
Contributor Author

@lgoettgens I can move the code, but I do not catch the point.
If the code gets moved inside Oscar first then still there is the problem that we get warnings about duplicate names after a release of Hecke.jl.

@lgoettgens
Copy link
Contributor

@lgoettgens I can move the code, but I do not catch the point. If the code gets moved inside Oscar first then still there is the problem that we get warnings about duplicate names after a release of Hecke.jl.

The benefit of first moving everything in Oscar to a central place and do discussions there is that the moving itself is a trivial action that does not need to involve that many people to cooperate, but it is just a simple copy-paste that e.g. Tommy can just do when the next breaking Hecke release is planned

@ThomasBreuer
Copy link
Contributor Author

@lgoettgens O.k.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants