Change or split `==`, `isequal` and `prmote` taking `MatrixElem` arguments by JohnAAbbott · Pull Request #2280 · Nemocas/AbstractAlgebra.jl

JohnAAbbott · 2026-01-09T12:22:00Z

First phase of splitting functions which take MatrixElem

fieker · 2026-01-09T15:24:10Z

On Fri, Jan 09, 2026 at 07:18:02AM -0800, Max Horn wrote: @fingolfin commented on this pull request. > +function canonical_unit(a::MatElem{T}) where T <: NCRingElement + @Req (nrows(a) > 0 && ncols(a) > 0) "Matrix must contain at least one entry" + return canonical_unit(a[1, 1]) +end ```suggestion canonical_unit(a::MatElem) = canonical_unit(matrix(a)) ```

a[1,1] was wrong anyway, it should be the 1st (in some fixed ordering) non-zero entry of a

…

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

JohnAAbbott · 2026-01-12T12:41:45Z

I marked several of @fingolfin suggestions as resolved because I already had some of the changes in my local copy. The latest push should resolve all of them.

fingolfin · 2026-01-12T13:02:22Z

Test fails:

Matrix.conversion: Test Failed at /Users/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/test/Matrix-test.jl:136
  Expression: matrix(U, Ra) == Ra
   Evaluated: [1 2; t^2 t-1] == [1 2; t^2 t-1]

I think it is comparing a MatRingElem and a MatElem and getting an unexpected result. I assume (but have not checked) that it used to get true; and it now gets false. That's bad: it really should be either true (so a missing == would have to be (re-)added), or an exception (then the test needs to be adjusted).

I'd be OK with either, but false is not acceptable

JohnAAbbott · 2026-01-12T13:04:02Z

One failing test: in test/Matrix-test.jl near line 136 there is the test matrix(U,Ra) == Ra where Ra is a MatRingElem and U is its base ring. The test fails because we are comparing a MatElem with a MatRingElem, and this gives false.
What is the preferred course of action?

Remove the failing test
Modify the code so that comparison of a MatElem with a MatRingElem compares the sizes and the entries
Other?

JohnAAbbott · 2026-01-12T13:20:40Z

Test fails:
Matrix.conversion: Test Failed at /Users/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/test/Matrix-test.jl:136
  Expression: matrix(U, Ra) == Ra
   Evaluated: [1 2; t^2 t-1] == [1 2; t^2 t-1]
I think it is comparing a MatRingElem and a MatElem and getting an unexpected result. I assume (but have not checked) that it used to get true; and it now gets false. That's bad: it really should be either true (so a missing == would have to be (re-)added), or an exception (then the test needs to be adjusted).

I'd be OK with either, but false is not acceptable

The equality test being called is likely unintentional:

==(x::MatElem, y::NCRingElem)
     @ AbstractAlgebra ~/OSCAR/GIT/AbstractAlgebra.jl/src/Matrix.jl:1252

It calls promote which changes the entries of the MatElem into MatRingElem values; that is surely unintentional!

codecov · 2026-01-12T13:59:17Z

Codecov Report

❌ Patch coverage is 91.80328% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.11%. Comparing base (032b699) to head (b0bfdaa).

Files with missing lines	Patch %	Lines
src/Matrix.jl	76.19%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2280      +/-   ##
==========================================
- Coverage   88.15%   88.11%   -0.05%     
==========================================
  Files         126      126              
  Lines       31999    32038      +39     
==========================================
+ Hits        28210    28231      +21     
- Misses       3789     3807      +18

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

JohnAAbbott · 2026-01-12T15:12:12Z

I have added new equality test functions (just the == version, not isequal) to cover comparison of a MatElem and a MatRingElem; currently the implementation just compares the underlying matrix value, but it could easily generate an error instead.
There's a catch: the new functions have introduced an ambiguity:

  Test threw exception
  Expression: S(m) == m
  MethodError: ==(::AbstractAlgebra.Generic.MatSpaceElem{AbstractAlgebra.Generic.MatRingElem{BigInt}}, ::AbstractAlgebra.Generic.MatRingElem{BigInt}) is ambiguous.
  
  Candidates:
    ==(x::MatElem{S}, y::MatRingElem{T}) where {S<:NCRingElement, T<:NCRingElement}
      @ AbstractAlgebra ~/OSCAR/GIT/AbstractAlgebra.jl/src/MatRing.jl:266
    ==(x::MatrixElem{T}, y::T) where T<:NCRingElem
      @ AbstractAlgebra ~/OSCAR/GIT/AbstractAlgebra.jl/src/Matrix.jl:1386
  
  Possible fix, define
    ==(::MatElem{T}, ::MatRingElem{T}) where {T<:NCRingElem, T<:NCRingElement}

I had wanted to use NCRingElem rather than NCRingElement, but that does not work with matrices over ZZ running in an AbstractAlgebra context (rather than Oscar). Frankly, I find it questionable to have a function with signature:

  ==(x::MatrixElem{T}, y::T) where T<:NCRingElem
      @ AbstractAlgebra ~/OSCAR/GIT/AbstractAlgebra.jl/src/Matrix.jl:1386

How often does it arise that one wants to know if a matrix is a scalar multiple of a truncated identity matrix? We already have tests for is_zero and is_identity which presumably cover the common cases.

fingolfin · 2026-01-13T08:45:01Z

How often does it arise that one wants to know if a matrix is a scalar multiple of a truncated identity matrix? We already have tests for is_zero and is_identity which presumably cover the common cases.

Personally I agree, and I'd be supportive of efforts trying to change that, but:

it may be more wide spread than you think, e.g. people doing bla == 0 instead of is_zero(bla) is done in a lot of places (I am not happy about it, but it's a fact)
if we remove this, we must be careful to make sure the result in affected code is an error (that we then fix) and not a silently wrong comparison
it should not be done in this PR, but in a separate one; perhaps open an issue for now as a reminder to look again into it later on

JohnAAbbott · 2026-01-13T09:56:29Z

1. it may be more wide spread than you think, e.g. people doing `bla == 0` instead of `is_zero(bla)` is done in a lot of places (I am not happy about it, but it's a fact)

Ahhh! That's a fair point.

JohnAAbbott · 2026-01-13T09:58:07Z

To make the tests pass I disabled two checks because they triggered the ambiguity error. Shall I leave them commented out?

JohnAAbbott · 2026-01-13T10:06:02Z

Here's another surprise. I wanted to increase code coverage (to keep GitHub happy), and discovered that when M is a AbstractAlgebra.Generic.MatSpaceElem{BigInt} then the call mul!(M,M,M) does not call function mul!(c::T, a::T, b::T) where T <: MatElem which is defined in src/Matrix.jl but instead calls another function...
Indeed there are the following functions in src/generic/Matrix.jl near lines 114--128

function AbstractAlgebra.add!(A::Mat{T}, B::Mat{T}, C::Mat{T}) where T
  A.entries .= B.entries .+ C.entries
  return A
end

function AbstractAlgebra.sub!(A::Mat{T}, B::Mat{T}, C::Mat{T}) where T
  A.entries .= B.entries .- C.entries
  return A
end

function AbstractAlgebra.mul!(A::Mat{T}, B::Mat{T}, C::Mat{T}) where T
  A.entries .= (B * C).entries
  return A
end

To clarify: in src/generic/GenericTypes.jl there is the definition: abstract type Mat{T} <: MatElem{T} end
Please advise!

lgoettgens · 2026-01-13T13:23:33Z

Here's another surprise. I wanted to increase code coverage (to keep GitHub happy), and discovered that when M is a AbstractAlgebra.Generic.MatSpaceElem{BigInt} then the call mul!(M,M,M) does not call function mul!(c::T, a::T, b::T) where T <: MatElem which is defined in src/Matrix.jl but instead calls another function... Indeed there are the following functions in src/generic/Matrix.jl near lines 114--128
function AbstractAlgebra.add!(A::Mat{T}, B::Mat{T}, C::Mat{T}) where T
  A.entries .= B.entries .+ C.entries
  return A
end

function AbstractAlgebra.sub!(A::Mat{T}, B::Mat{T}, C::Mat{T}) where T
  A.entries .= B.entries .- C.entries
  return A
end

function AbstractAlgebra.mul!(A::Mat{T}, B::Mat{T}, C::Mat{T}) where T
  A.entries .= (B * C).entries
  return A
end
To clarify: in src/generic/GenericTypes.jl there is the definition: abstract type Mat{T} <: MatElem{T} end Please advise!

The functions in src/Matrix.jl may not be testable in AA alone, but may need Nemo to be loaded (which we don't do in the CI here). Thus, I would say there is nothing you can do here

lgoettgens · 2026-01-13T13:25:03Z

-   @test S(m) == m
-   @test m == S(m)
+#   @test S(m) == m
+#   @test m == S(m)


These should either work or (if they are logical nonsense) be removed. Just commenting out is bad.

They do currently work, but the point I wanted to make earlier is whether we really want to guarantee that they will work evermore. I think we should not make this guarantee, and @fingolfin wrote Personally I agree. So based on that comment I shall delete these tests since they do not represent behaviour that we wish to guarantee in the future.

@JohnAAbbott I think you misunderstood me here: I agree that we should work on removing this feature. But that's not done by just removing the test, or the code. Rather, we have to carefully do this, to avoid breaking people's code badly. To be explicitly:

such a thing should never be done as an aside in PR that is focused on something else (where it will slip by the attention of people)

rather, deprecating a feature should be done in its own dedicated PR, so that people can be aware of it

it should be made sure that it is mentioned as a breaking change in the release notes (another reason why having it in its own PR is useful: we can then use our existing tooling and edit the PR title to be directly suitable for inclusion in the release notes)

the change should be done in a way that minimizes "hidden" breakage. In the case at hand, this means that it would be OK from "comparison works in a sensible way" to "comparison raises an helpful error. It would not be OK to go to "comparison suddenly always returns false" or "comparison raises an unhelpful error".

this change then of course would have to be reflected in the tests -- but not by just removing a test, but by replacing it with a test that verifies the new property (e.g. "always raises helpful error") actually holds

My points 1+2 also apply to other "unrelated" changes. This is why e.g. I said the change to how empty matrices are printed should not be discussed via a code comment inserted here, but in a separate issue; and be resolved in a separate PR, dedicated to that.

If juggling multiple git branches is a hold-up factor here, I'd be happy to sit with you to discuss some ways how you can manage multiple active git branches with low friction.

JohnAAbbott · 2026-01-15T10:59:41Z

I have marked this as Ready for review because the CI checks all pass. Note that passing was achieved by disabling a whole test-set in generic/Matrix-test.jl which was testing behaviour which we now doubt that we should guarantee (e.g. see @fingolfin comment above containing Personally I agree)
A tricky point was equality testing of a MatElem with a MatRingElem: this could be "ambiguous" if the MatElem has entries from a MatRing. However, some people may have written code such as M == 0 instead of is_zero(M) because there is an == operator which accepts a matrix and an element of a ring... Discussion about this will be held in a separate issue (yet to be created).

JohnAAbbott · 2026-01-15T13:20:18Z

I have just created issue #2299 to discuss the issue related to equality testing. If the change there is approved then the implementation will be in a separate PR.

lgoettgens · 2026-01-15T16:46:29Z

I have found a minimal diff that preserves the current behavior (which I'll commit here in a minute). This does not intend to force a decision on #2299, but it allows for this PR to continue on in a non-breaking way.
Depending on the outcome of #2299, we might remove the touched methods in a future (breaking) PR again.

…ctAlgebra.jl into JAA/split-MatrixElem1

fingolfin · 2026-01-16T09:51:02Z

The tests are failing, though:

Generic.MatAlg.equality: Error During Test at /home/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/test/generic/MatRing-test.jl:1649
  Test threw exception
  Expression: M == matrix(QQ, M)
  Cannot promote to common type
  Stacktrace:
   [1] error(s::String)
     @ Base ./error.jl:35
   [2] promote(x::AbstractAlgebra.Generic.MatSpaceElem{Rational{BigInt}}, y::AbstractAlgebra.Generic.MatRingElem{BigInt})

Co-authored-by: Max Horn <max@quendi.de>

JohnAAbbott · 2026-01-16T10:40:13Z

The tests are failing, though:

@lgoettgens reinstated a block of tests which I had deleted (because I believe they no longer represent behaviour that we wish to guarantee). Shall I wait for @lgoettgens to fix this?

lgoettgens · 2026-01-16T10:40:55Z

The tests are failing, though:

Generic.MatAlg.equality: Error During Test at /home/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/test/generic/MatRing-test.jl:1649
  Test threw exception
  Expression: M == matrix(QQ, M)
  Cannot promote to common type
  Stacktrace:
   [1] error(s::String)
     @ Base ./error.jl:35
   [2] promote(x::AbstractAlgebra.Generic.MatSpaceElem{Rational{BigInt}}, y::AbstractAlgebra.Generic.MatRingElem{BigInt})

Indeed, but this is a newly added test that's failing now (rather than removing an already existing test). And this new test does not work on current master as well (although with a different error)

lgoettgens · 2026-01-16T10:42:27Z

I would prefer if this rather large PR would only do rather mechanical changes that don't change any behavior. The behavior change should IMO be in a smaller follow-up PR once #2299 is decided on

JohnAAbbott · 2026-01-16T13:26:54Z

The tests are failing, though:
Generic.MatAlg.equality: Error During Test at /home/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/test/generic/MatRing-test.jl:1649
  Test threw exception
  Expression: M == matrix(QQ, M)
  Cannot promote to common type
Indeed, but this is a newly added test that's failing now (rather than removing an already existing test). And this new test does not work on current master as well (although with a different error)

But why reinstate the test?

lgoettgens · 2026-01-16T13:29:14Z

The tests are failing, though:
Generic.MatAlg.equality: Error During Test at /home/runner/work/AbstractAlgebra.jl/AbstractAlgebra.jl/test/generic/MatRing-test.jl:1649
  Test threw exception
  Expression: M == matrix(QQ, M)
  Cannot promote to common type
Indeed, but this is a newly added test that's failing now (rather than removing an already existing test). And this new test does not work on current master as well (although with a different error)
But why reinstate the test?

I don't see it as "reinstating" but as "not removing in the first place". Since this PR here is supposed to be non-breaking (assuming we move the breaking parts to a follow-up after #2299), it should not remove any tests. As in that case, we cannot be sure that it indeed is non-breaking.

JohnAAbbott · 2026-01-16T13:33:43Z

But why reinstate the test?

I don't see it as "reinstating" but as "not removing in the first place". Since this PR here is supposed to be non-breaking (assuming we move the breaking parts to a follow-up after #2299), it should not remove any tests. As in that case, we cannot be sure that it indeed is non-breaking.

Most irritating! Have a good weekend

JohnAAbbott · 2026-01-16T13:35:14Z

I shall let @lgoettgens take over this PR from now on.

lgoettgens · 2026-01-16T14:05:22Z

I shall let @lgoettgens take over this PR from now on.

As a first step, I cherry-picked the (in my opinion) uncontroversial changes into the new PR #2302. Once that is in, I'll rebase this one here to then have something smaller to reason about. If I am not mistaken, there should be only promote and == left then.

fingolfin · 2026-01-26T01:36:39Z

+    one(a::MatElem{T}) where T <: NCRingElement
+    one(a::MatRingElem{T}) where T <: NCRingElement


I've thought about this back and forth: should we list both MatElem and MatRingElem in these docstrings, or just MatElem?

Right now I tend towards "only list MatElem": these are matrix APIs, and they should be documented as such.

All the MatRingElem ones should be handled by a catch-all section in the MatRing documentation, i.e., in docs/src/matrix_algebras.md. Indeed, we already say this:

Almost all of the functionality specified for generic matrices is available for matrix
algebras. The exceptions are functions such as solve and nullspace which may
return non-square matrices, or which don't accept square matrices.

Thus:

Suggested change

one(a::MatElem{T}) where T <: NCRingElement

one(a::MatRingElem{T}) where T <: NCRingElement

one(a::MatElem{T}) where T <: NCRingElement

fingolfin · 2026-01-26T01:37:20Z

+    one(a::MatRingElem{T}) where T <: NCRingElement

-Return the identity matrix in the same matrix space as $a$.
+Return the identity matrix in the same matrix space or matrix ring as $a$.


Suggested change

Return the identity matrix in the same matrix space or matrix ring as $a$.

Return the identity matrix in the same matrix space as $a$.

fingolfin · 2026-03-04T13:37:07Z


 @doc raw"""
-    one(a::MatrixElem{T}) where T <: NCRingElement
+    one(a::MatElem{T}) where T <: NCRingElement


This line could be merged right away

fingolfin · 2026-03-04T13:37:25Z


 """
-    is_symmetric(M::MatrixElem)
+    is_symmetric(M::MatElem)


Could be merged right away

fingolfin · 2026-03-04T13:37:32Z


 Return whether the form corresponding to the matrix `M` is alternating,
-i.e. `M = -transpose(M)` and `M` has zeros on the diagonal.
+i.e. `M == -transpose(M)` and `M` has zeros on the diagonal.


Could be merged right away

fingolfin reviewed Jan 9, 2026

View reviewed changes

Comment thread src/MatRing.jl Outdated

fingolfin reviewed Jan 9, 2026

View reviewed changes

Comment thread src/Matrix.jl Outdated

fingolfin reviewed Jan 9, 2026

View reviewed changes

Comment thread src/Matrix.jl Outdated

fingolfin reviewed Jan 9, 2026

View reviewed changes

Comment thread src/Matrix.jl Outdated

Comment thread src/Matrix.jl Outdated

Comment thread src/Matrix.jl Outdated

Comment thread src/Matrix.jl Outdated

Comment thread src/Matrix.jl

Comment thread src/generic/MatRing.jl Outdated

fingolfin changed the title ~~Jaa/split matrix elem1~~ Split functions taking a MatrixElem argument Jan 13, 2026

JohnAAbbott mentioned this pull request Jan 13, 2026

Document why is_zero_entry, is_zero_row etc. exist (for efficiency reasons!) #2290

Closed

lgoettgens reviewed Jan 13, 2026

View reviewed changes

lgoettgens linked an issue Jan 13, 2026 that may be closed by this pull request

Document why is_zero_entry, is_zero_row etc. exist (for efficiency reasons!) #2290

Closed

fingolfin added 2 commits January 14, 2026 14:47

staged some stuff

f933d0d

Split functions taking a MatrixElem argument

b0bfdaa

fingolfin force-pushed the JAA/split-MatrixElem1 branch from 817d71c to b0bfdaa Compare January 14, 2026 13:54

JohnAAbbott marked this pull request as ready for review January 15, 2026 10:52

lgoettgens added 3 commits January 15, 2026 17:47

Fix ==(::MatElem, ::MatRingElem)

0d2b7b0

Fix ==(::MatElem, ::MatRingElem)

43f5aa6

Merge branch 'JAA/split-MatrixElem1' of github.com:JohnAAbbott/Abstra…

93084d7

…ctAlgebra.jl into JAA/split-MatrixElem1

fingolfin reviewed Jan 16, 2026

View reviewed changes

Comment thread test/generic/MatRing-test.jl Outdated

Update test/generic/MatRing-test.jl

2af64d7

Co-authored-by: Max Horn <max@quendi.de>

lgoettgens mentioned this pull request Jan 16, 2026

Split functions taking a MatrixElem argument (easy cases) #2302

Merged

lgoettgens removed a link to an issue Jan 16, 2026

Document why is_zero_entry, is_zero_row etc. exist (for efficiency reasons!) #2290

Closed

lgoettgens mentioned this pull request Jan 16, 2026

Improve documentation for is_zero_entry and friends #2303

Merged

fingolfin added 3 commits January 26, 2026 02:26

Merge branch 'master' into JAA/split-MatrixElem1

a9fdda5

whitespace

46e762a

Apply suggestions from code review

f1595fe

fingolfin reviewed Jan 26, 2026

View reviewed changes

drop mentions of MatRingElem in docstrings

c7744e1

fingolfin reviewed Mar 4, 2026

View reviewed changes

Comment thread src/Matrix.jl

"""

is_symmetric(M::MatrixElem)

is_symmetric(M::MatElem)

Copy link
Copy Markdown

Member

fingolfin Mar 4, 2026

Choose a reason for hiding this comment

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

Could be merged right away

fingolfin reviewed Mar 4, 2026

View reviewed changes

fingolfin changed the title ~~Split functions taking a MatrixElem argument~~ Change or split ==, isequal and prmote taking MatrixElem arguments Mar 4, 2026

fingolfin marked this pull request as draft March 4, 2026 13:39

fingolfin added the breaking label Mar 4, 2026

		one(a::MatElem{T}) where T <: NCRingElement
		one(a::MatRingElem{T}) where T <: NCRingElement

	Return the identity matrix in the same matrix space or matrix ring as $a$.
	Return the identity matrix in the same matrix space as $a$.

Conversation

JohnAAbbott commented Jan 9, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fieker commented Jan 9, 2026 via email

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JohnAAbbott commented Jan 12, 2026

Uh oh!

fingolfin commented Jan 12, 2026

Uh oh!

JohnAAbbott commented Jan 12, 2026

Uh oh!

JohnAAbbott commented Jan 12, 2026

Uh oh!

codecov Bot commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

JohnAAbbott commented Jan 12, 2026

Uh oh!

fingolfin commented Jan 13, 2026

Uh oh!

JohnAAbbott commented Jan 13, 2026

Uh oh!

JohnAAbbott commented Jan 13, 2026

Uh oh!

JohnAAbbott commented Jan 13, 2026

Uh oh!

lgoettgens commented Jan 13, 2026

Uh oh!

lgoettgens Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

JohnAAbbott Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

fingolfin Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

JohnAAbbott commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JohnAAbbott commented Jan 15, 2026

Uh oh!

lgoettgens commented Jan 15, 2026

Uh oh!

fingolfin commented Jan 16, 2026

Uh oh!

Uh oh!

JohnAAbbott commented Jan 16, 2026

Uh oh!

lgoettgens commented Jan 16, 2026

Uh oh!

lgoettgens commented Jan 16, 2026

Uh oh!

JohnAAbbott commented Jan 16, 2026

Uh oh!

lgoettgens commented Jan 16, 2026

Uh oh!

JohnAAbbott commented Jan 16, 2026

Uh oh!

JohnAAbbott commented Jan 16, 2026

Uh oh!

lgoettgens commented Jan 16, 2026

Uh oh!

fingolfin Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fingolfin Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

codecov Bot commented Jan 12, 2026 •

edited

Loading

JohnAAbbott commented Jan 15, 2026 •

edited

Loading

fingolfin Jan 26, 2026 •

edited

Loading