-
-
Notifications
You must be signed in to change notification settings - Fork 572
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
Problems with contains for Tableau, TableauTuples and PartitionTuples #14145
Comments
Changed keywords from sage45 to days45 |
Author: Travis Scrimshaw |
Dependencies: #13605 |
comment:2
I've gone through and also caught all Best, Travis |
Reviewer: Andrew Mathas |
comment:4
I will upload a "review" patch shortly which tests containment without creating an object in the element class. |
comment:5
Hey Andrew, Just wondering what the status of the review patch is. Thanks, Travis |
comment:6
Hi Travis, I had it almost finished -- one class left to do -- and then teaching started and some other urgent projects got in the way. Will try and finalise soon, although it is going to be more of a replacement patch than a review patch I'm afraid... Andrew |
comment:7
Hey Andrew, No worries on both accounts, I completely understand and there's not any rush on this. Hope everything is going well. Best, Travis |
Changed reviewer from Andrew Mathas to Andrew Mathas, Travis Scrimshaw |
Changed author from Travis Scrimshaw to Travis Scrimshaw, Andrew Mathas |
comment:8
Hi Travis, I finally got back to this. I looked more closely at the changes in timing before and after the patch and I think that they are not in fact due to element creation but instead are caused by the lazy imports. For example, the biggest slowdown (from 0s to 6.51s) occurs with the lines G = SymmetricGroup(8)
g = G([(1,2,3,4,5),(6,7,8)]) I have just pushed a slight modification to the patch to the combinat queue which changes the sanity checking in Partition.init. I ran a few tests and the new code is slightly faster than the old code. Finally, as my first review patch was more 4 times bigger than your patch I have made us both authors and reviewers. If you are happy with it then let's make this a positive review. Andrew |
comment:9
Thanks for checking on the timings Andrew (I ended up forgetting about looking deeper into it, sorry). I've uploaded the patch from the queue. Looks good to me. Thanks, Travis |
comment:10
Why the change from
to
|
comment:11
Sorry missed that one. |
comment:13
|
comment:14
Attachment: trac_14145-fix_contains_tableau-ts.patch.gz Fixed. Sorry about that Jeroen. |
Merged: sage-5.10.beta2 |
The following three commands all lead to errors:
In all cases, sage reports
The place where sage is failing is in CombinatorialObject.init where we have:
The error arises because l==1 is not a list. The discussion on sage combinat concluded that this was more a bug in the
__contains__
methods of these classes rather than in CombinatorialObject.init -- although, I do think that CombinatorialObject should trap this error and print a more informative error message.Anyway, contains should never give rise to an error, so the contains methods of these classes need to be fixed.
Depends on #13605
CC: @AndrewAtLarge
Component: combinatorics
Keywords: days45
Author: Travis Scrimshaw, Andrew Mathas
Reviewer: Andrew Mathas, Travis Scrimshaw
Merged: sage-5.10.beta2
Issue created by migration from https://trac.sagemath.org/ticket/14145
The text was updated successfully, but these errors were encountered: