-
-
Notifications
You must be signed in to change notification settings - Fork 487
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
sage.groups.generic
: Fix incorrect identity testing
#37257
Conversation
src/sage/groups/generic.py
Outdated
# Should this be replaced with .zero()? With an extra AttributeError handler? | ||
identity = a.parent()(0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think .zero()
should be faster, but indeed not all additive groups have a .zero()
method...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took the violent approach of replacing it with .zero()
and fixing the errors. I only found a few use cases of sage.groups.generic
in the entire Sage, so I fixed those (only required fixing homset::zero
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks promising! Just double-checking: The change from .codomain()
to .extended_codomain()
in src/sage/schemes/generic/homset.py
is an essentially unrelated bugfix, right? And this is what causes the point (a : a)
in that doctest in src/sage/schemes/projective/projective_morphism.py
to be normalized properly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes they're two unrelated fixes (sorry!!), the extended_codomain
is to imitate what schemes/projective/projective_homset.py
does (and makes more sense). The normalisation is a separate problem.
It is caused by the following stripped code:
sage: F.<a> = GF(4)
....: ProjectiveSpace(ZZ, 1)._point(S(F), [a, a])
....: ProjectiveSpace(F, 1)._point(S(F), [a, a])
(a : a)
(1 : 1)
(This caller difference is introduced by the extended_codomain
to codomain
change.) This is because the two lines call different constructors
sage/src/sage/schemes/projective/projective_space.py
Lines 823 to 836 in 0c390a0
def _point(self, *args, **kwds): | |
""" | |
Construct a point. | |
For internal use only. See :mod:`morphism` for details. | |
TESTS:: | |
sage: P2.<x,y,z> = ProjectiveSpace(2, GF(3)) | |
sage: point_homset = P2._point_homset(Spec(GF(3)), P2) | |
sage: P2._point(point_homset, [1,2,3]) | |
(2 : 1 : 0) | |
""" | |
return SchemeMorphism_point_projective_ring(*args, **kwds) |
SchemeMorphism_point_projective_ring
.
sage/src/sage/schemes/projective/projective_space.py
Lines 2271 to 2284 in 0c390a0
def _point(self, *args, **kwds): | |
""" | |
Construct a point. | |
For internal use only. See :mod:`morphism` for details. | |
TESTS:: | |
sage: P2.<x,y,z> = ProjectiveSpace(2, GF(3)) | |
sage: point_homset = P2._point_homset(Spec(GF(3)), P2) | |
sage: P2._point(point_homset, [1,2,3]) | |
(2 : 1 : 0) | |
""" | |
return SchemeMorphism_point_projective_finite_field(*args, **kwds) |
SchemeMorphism_point_projective_finite_field
which allows division.
I think this is a separate problem, where ._point
shouldn't care about the caller's type but rather the argument (homset)'s type, but again it's a separate problem. It's a separate problem.
Co-authored-by: Lorenz Panny <84067835+yyyyx4@users.noreply.github.com>
Documentation preview for this PR (built with commit e9ce5c1; changes) is ready! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
The
bsgs
function used to checkis_zero
, when it should check== identity
(which is given). It also allows me to use the method for "ad-hoc classes":Also fixed styling, that's why there are some random edits