-
-
Notifications
You must be signed in to change notification settings - Fork 546
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 coercion to Element #20767
Comments
This comment has been minimized.
This comment has been minimized.
New commits:
|
Commit: |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
comment:47
Nicolas, I took care of your comments. If you are missing something, feel free to notify me or to make the change yourself. |
Changed branch from u/jdemeyer/move_coercion_to_element to u/nthiery/move_coercion_to_element |
comment:49
I read your new documentation; that's a very nice addition to the Sage documentation. I have done some changes here and there, and added a draft of explanation of the Other than this, I believe this is good to go. Thanks a lot Jeroen! New commits:
|
Changed branch from u/nthiery/move_coercion_to_element to u/jdemeyer/move_coercion_to_element |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:52
Done, needs review. |
comment:53
Thanks; I checked your commits and am happy with them. Two small questions:
Once you have made up your mind on the above, you can set a positive review on my behalf (assuming of course all tests keep passing). Thanks! Cheers, |
Reviewer: Nicolas M. Thiéry |
comment:54
Replying to @nthiery:
Yes, it's a
It would work for Maybe one could argue that |
comment:55
This ticket is suffering also from #21441 (see patchbot) |
comment:56
Replying to @nthiery:
A more complete answer: yes, they really should be |
comment:57
Ah, yes, That's a good point indeed. Thanks! |
Changed branch from u/jdemeyer/move_coercion_to_element to |
This ticket has 2 main changes:
RingElement
,ModuleElement
and the like toElement
.Because of this, it matters a lot less whether a class inherits from
Element
or fromModuleElement
/RingElement
/FieldElement
...One difference remains: the more specialized classes have some default implementations for arithmetic. For example,
ModuleElement
implements unary negation as multiplication by -1. The base classElement
has no such default implementations.This patch also affects lookup in categories: with this patch, double-underscore methods like
__add__
are never taken from the category. TheElement
classes take precedence over the category, so the default implementations of arithmetic operations will override whatever is in the category (this is existing behaviour, not affected by this patch). For the base classElement
, this is not an issue since there are no default implementations.__add__
to returnNotImplemented
(rather than raise an error) if one argument is not a SageElement
and coercion fails.This will cause Python to try the reversed operation (
__radd__
or__add__
in Cython). This way, Sage has improved support for operations with non-Sage types.Depends on #21126
Depends on #20686
Depends on #21139
Depends on #21140
Depends on #21152
Depends on #21153
Depends on #21154
Depends on #21441
CC: @nthiery @videlec @simon-king-jena
Component: coercion
Author: Jeroen Demeyer
Branch/Commit:
25c9d7d
Reviewer: Nicolas M. Thiéry
Issue created by migration from https://trac.sagemath.org/ticket/20767
The text was updated successfully, but these errors were encountered: