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

New linear solving interface + more upstream changes #3350

Merged
merged 10 commits into from
Feb 16, 2024

Conversation

joschmitt
Copy link
Member

@joschmitt joschmitt commented Feb 10, 2024

The functions solve, can_solve, can_solve_with_solution, can_solve_with_solution_and_kernel and kernel (for matrices) now use the "new" interface from AbstractAlgebra.
This is a breaking change and needs a Hecke update.

I put everything on top of #3366 so that OSCAR works with the newest Nemo/AbstractAlgebra. Will rebase once #3366 is merged.

Closes #1062 🥳 🎉

@joschmitt joschmitt marked this pull request as draft February 10, 2024 16:20
@thofma thofma force-pushed the js/solve branch 2 times, most recently from cf21ff8 to 79d9755 Compare February 11, 2024 23:28
Copy link

codecov bot commented Feb 12, 2024

Codecov Report

Merging #3350 (d0af366) into master (82f6440) will decrease coverage by 0.03%.
Report is 2 commits behind head on master.
The diff coverage is 84.33%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #3350      +/-   ##
==========================================
- Coverage   82.08%   82.06%   -0.03%     
==========================================
  Files         556      556              
  Lines       74072    74075       +3     
==========================================
- Hits        60805    60792      -13     
- Misses      13267    13283      +16     
Files Coverage Δ
...ntal/FTheoryTools/src/FamilyOfSpaces/attributes.jl 100.00% <100.00%> (ø)
.../FTheoryTools/src/LiteratureModels/constructors.jl 92.64% <100.00%> (ø)
...rimental/FTheoryTools/src/TateModels/attributes.jl 93.84% <100.00%> (ø)
...mental/FTheoryTools/src/TateModels/constructors.jl 97.43% <100.00%> (ø)
...FTheoryTools/src/WeierstrassModels/constructors.jl 95.58% <100.00%> (ø)
experimental/FTheoryTools/src/auxiliary.jl 94.87% <100.00%> (ø)
experimental/GITFans/src/GITFans.jl 94.22% <100.00%> (ø)
experimental/GModule/Brueckner.jl 87.96% <100.00%> (ø)
experimental/GModule/Cohomology.jl 67.46% <100.00%> (ø)
experimental/GaloisGrp/src/Solve.jl 74.20% <100.00%> (ø)
... and 49 more

... and 2 files with indirect coverage changes

@@ -75,7 +75,7 @@ end
=#

function rank(phi::FreeModuleHom{FreeMod{T}, FreeMod{T}, Nothing}) where {T<:FieldElem}
return ngens(domain(phi)) - left_kernel(sparse_matrix(phi))[1]
return ngens(domain(phi)) - nrows(kernel(sparse_matrix(phi), side = :left))
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we need a function nullity - to return the rank of the kernel only...

Copy link
Member Author

Choose a reason for hiding this comment

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

I add it to the list of future improvements.

@joschmitt joschmitt force-pushed the js/solve branch 3 times, most recently from 13052aa to d0af366 Compare February 16, 2024 10:55
@joschmitt
Copy link
Member Author

There is a type inference problem on nightly. It already happens only with Hecke (but not only with Nemo):

julia> function foo(R::MPolyRing)
           return [ x for x in gens(R) ]
       end
foo (generic function with 1 method)

julia> K, a = cyclotomic_field(3, "a");

julia> Kx, (x, y) = K["x", "y"];

julia> @code_warntype foo(Kx)
MethodInstance for foo(::AbstractAlgebra.Generic.MPolyRing{AbsSimpleNumFieldElem})
  from foo(R::MPolyRing) @ Main REPL[2]:1
Arguments
  #self#::Core.Const(foo)
  R::AbstractAlgebra.Generic.MPolyRing{AbsSimpleNumFieldElem}
Body::Any
1 ─ %1 = Main.gens::Core.Const(AbstractAlgebra.gens)
│   %2 = (%1)(R)::AbstractVector{<:AbstractAlgebra.Generic.MPoly{AbsSimpleNumFieldElem}}
│   %3 = Base.Generator(Base.identity, %2)::Base.Generator{I, typeof(identity)} where I<:(AbstractVector{<:AbstractAlgebra.Generic.MPoly{AbsSimpleNumFieldElem}})
│   %4 = Base.collect(%3)::Any
└──      return %4

@thofma can/should we do something about this?

@joschmitt joschmitt changed the title Redirect to the new linear solving interface New linear solving interface + more upstream changes Feb 16, 2024
@fingolfin
Copy link
Member

Regarding the new invalidation: open an issue with the details (we can look at it with help of JET at some point), but otherwise move on.

@thofma
Copy link
Collaborator

thofma commented Feb 16, 2024

Not clear if this is about invalidations.

julia> @inferred gens(Kx)
ERROR: return type Vector{AbstractAlgebra.Generic.MPoly{AbsSimpleNumFieldElem}} does not match inferred return type AbstractVector{<:AbstractAlgebra.Generic.MPoly{AbsSimpleNumFieldElem}}
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:35
 [2] top-level scope
   @ REPL[11]:1

julia> @code_warntype gens(Kx)
[...]
Body::Vector{AbstractAlgebra.Generic.MPoly{AbsSimpleNumFieldElem}}
[...]

This is inconsistent and one of them is lying.

@thofma
Copy link
Collaborator

thofma commented Feb 16, 2024

There is something dodgy in AA, where we rely on some compiler heuristic. Not sure what exactly broke it. I think I have a fix in Nemocas/AbstractAlgebra.jl#1611. Can you confirm that this fixes the issue @joschmitt?

@joschmitt
Copy link
Member Author

There is something dodgy in AA, where we rely on some compiler heuristic. Not sure what exactly broke it. I think I have a fix in Nemocas/AbstractAlgebra.jl#1611. Can you confirm that this fixes the issue @joschmitt?

Yes, this also solves the original failure in the nightly tests here.

@thofma thofma enabled auto-merge (squash) February 16, 2024 13:39
@thofma thofma merged commit 597398c into oscar-system:master Feb 16, 2024
16 of 20 checks passed
@lgoettgens
Copy link
Member

This should get backported, right?

@thofma thofma added the backport 1.0.x Should be backported to the release 1.0 branch label Feb 16, 2024
@thofma
Copy link
Collaborator

thofma commented Feb 16, 2024

This should be backported. It includes two breaking changes to the linear algebra, which are long overdue. Clean up kernel and clean up indexing.

I adjusted the book two weeks ago for the indexing changes (#3276) is the corresponding OSCAR PR) and the book does not use kernel of matrices.

CC: @fieker

@aaruni96 aaruni96 mentioned this pull request Feb 16, 2024
33 tasks
@joschmitt joschmitt deleted the js/solve branch February 16, 2024 18:43
benlorenz pushed a commit that referenced this pull request Feb 19, 2024
* feat: Use new linear algebra functionality

* Adjust to deleted deprecations/aliases Hecke edition
@benlorenz benlorenz removed the backport 1.0.x Should be backported to the release 1.0 branch label Feb 19, 2024
benlorenz added a commit that referenced this pull request Feb 23, 2024
### Backported PRs

- [x] #3367
- [x] #3379 
- [x] #3369
- [x] #3291
- [x] #3325
- [x] #3350 
- [x] #3351
- [x] #3365 
- [x] #3366
- [x] #3382
- [x] #3373
- [x] #3341
- [x] #3346
- [x] #3381
- [x] #3385
- [x] #3387 
- [x] #3398 
- [x] #3399 
- [x] #3374 
- [x] #3406 
- [x] #2823
- [x] #3298
- [x] #3386 
- [x] #3412 
- [x] #3392 
- [x] #3415 
- [x] #3394
- [x] #3391
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.

Inconsistent behaviour of kernel
6 participants