-
-
Notifications
You must be signed in to change notification settings - Fork 565
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
Avoid a coercion when computing an element to the power of 0 #11257
Comments
comment:1
With the patch applied, same tests give:
And
We will see what the builbot will say. What pass, what crash .... |
comment:2
Three parents does not have the method one and don't pass the change. |
comment:3
I looked at the three parents for which elements didn't pass the tests. Every times, it seems clear to me that they deserve to have a method one. I had some. I also fixed some typos on the way and ran a 'delete-trailing-whitespace' which make the patch a little bit more long... I hope all will be fix now with this one. |
Author: Nicolas Borie |
comment:4
Bonjour Nicolas! Thanks for your work on that. Please investigate the test failure reported by the patchbot, and double check that TestSuite is run on every parent that you modified. While we are at it, we probably want to implement Ah, and do we want to do the same for .zero()? Amitiés, |
comment:5
Hi Nicolas, Replying to @nthiery:
I suspect that question is partially addressed to me, as it may relate with #11115? I didn't look at the patch. But if you mean to make .zero() and .one() a cached method of the parent class of a category, then in fact #11115 is needed in order to make the cache work on those parent structures that do not allow attribute assignment. |
comment:6
Replying to @simon-king-jena:
Yup. And to detect potential conflicts with the ongoing changes in rings and such.
+1 |
comment:7
Hello you both, For the failures from the buildbot, I can't reproduce them.
For the TestSuite, there is some work to be done. A new version is on the way... Cheers, |
comment:8
I tried to do the best... Fix the TestSuite on old parents is not a simple job. Especially when one doesn't know enough about old category system... I fix properly the categories of affected parents, but I do not know how to do for the elements (especially when there is some facade with a separate implementation of the elements). ((( I think I passed already a lot of time on these parents (major part of today of trying to understand what they represent mathematically speaking...). Especially for the FreeMonoid feature. In the new category framework, the example of monoid (i.e. "Monoids().example()") is the free monoid. And the one coming from the category framework inherit of a LOT of top level methods. I try to fix FreeMonoidElement in sage/monoid with categories but if the choice was mine, I would just overwrite the 2005 version with these coming from category... Hoping the patchbot will be happy this time! The patch does already much more than the ticket! |
comment:9
Replying to @sagetrac-nborie:
Oops, this is going far beyond what I expected! I just meant to add Cheers, |
This comment has been minimized.
This comment has been minimized.
comment:11
Sorry for spamming, but I don't know how to tell the builbot that dependencies have change otherwise than change the status of the ticket. |
comment:13
Replying to @nthiery:
I don't have the time to verify whether there is an overlap. But: If there is an overlap then it is with #9944 or #9138. These two tickets try to make all rings use the category framework properly, and in some cases it also provides them with the new coercion model. If what you do is about something else but rings, then it is very likely that there is no overlap. Best regards, Simon |
This comment has been minimized.
This comment has been minimized.
comment:14
There going to have a little conflict with #9138 and its second patch trac9138_categories_for_more_rings.patch. As Simon make a better categorifycation than me, I will place this patch after. I will also begin the review of #9138, I won't probably review everything (It is not a small patch), but I will give a list of what I review (according my skills). Thanks very very much for #9138 (not an amazing task but it has to be done!) Cheers, |
Changed keywords from element, power, zero to element, power, zero, Cernay2012 |
Dependencies: #11900 |
comment:17
Attachment: trac_11257_avoid_coercion_power_zero-nb.patch.gz I just added a one method for EtaGroup... With the categories for all(more) ring from Simon, all tests should pass... |
comment:18
I tested it again, and it is good to go Nathann |
Reviewer: Nathann Cohen |
Merged: sage-5.0.beta4 |
In the generic structure of element, a coercion is called to compute an element z to the power of 0 : z^0
The goal of this ticket is trying to replace all call of Parent(1) by Parent.one() to avoid the coercion. (and hope Sage is ready for a such change...)
Before :
And for the speed :
depends on #9065
depends on #9138
Depends on #11900
CC: @sagetrac-sage-combinat @simon-king-jena
Component: performance
Keywords: element, power, zero, Cernay2012
Author: Nicolas Borie
Reviewer: Nathann Cohen
Merged: sage-5.0.beta4
Issue created by migration from https://trac.sagemath.org/ticket/11257
The text was updated successfully, but these errors were encountered: