-
-
Notifications
You must be signed in to change notification settings - Fork 556
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
Hom: introduce a check argument to simplify the unpickling detection logic #16275
Comments
Branch pushed to git repo; I updated commit sha1. New commits:
|
Commit: |
comment:3
I agree with these changes, although I don't understand pickling well enough to answer those issues. Simon, could you render judgement on this or clarify the issue? |
comment:4
Just in case this helps, here is an extract of how quotients of
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:7
With the latest commit, all tests pass. Running the long tests now. |
Replying to @nthiery:
I agree that this is a good approach.
I would prefer if we could preserve these potential pickles. Perhaps it is possible to have a "try-except" block somewhere, and unpickle the old way only if the new way fails. This would be without a noticeable speed regression, I hope. Note, in any case, that post-#14793 pickles that can not be unpickled with your changes could not be unpickled pre-#14793 either.
+1 I will try to review it after lunch. Certainly there has to be a review patch, e.g., in order to remove the old |
comment:9
Replying to @tscrim:
Let's try... The problem occurs if Python's default way of pickling/copying is used: Assume that you have an object When pickling The problem: It could be that you need The obvious approach towards a solution: When we have a pickle, then the assertions need not be made, as we know that the to-be-unpickled object belongs to the category of the to-be-unpickled homset. In #14793, it was suggested to skip the assertion if the category of domain or codomain is not initialised, since this indicates that we are in the process of unpickling domain and/or codomain. Here, it is suggested to be more explicit and have an optional argument for skipping the assertion. I think explicit is better than implicit. Moreover, it has another use case (as demonstrated by Nicolas) and should also be faster than the old solution. Hence, I am all in favour of the new solution. The only problem is: (How) Do we care about old pickles whose unpickling requires to skip the assertion, but which are unaware of the "check=False" argument? I suggest the following scheme:
Hence, the assertion is skipped if this is explicitly requested, and before raising an actual error it is verified if we need to skip the assertion implicitly. |
comment:10
With the current branch,
Hopefully this is just a trivial typo (2 instead of 1). I'll try to fix that in my review patch. |
A failing pickle |
comment:11
Attachment: broken_pickle.sobj.gz I have attached a pickle that can't be unpickled with the current branch. I suggest that we make it so that it can still be unpickled (as I have sketched in comment:9) and add it to the pickle jar. Can you tell me how to add stuff to the pickle jar? |
comment:12
I have added it to the picklejar, but now I don't know how to post the change. It seems that the picklejar is not under version control. Anyway, I think we need to catch errors properly, and raise a more informative error. What happens with the pickle is this:
So, Nicolas' nicely formatted error is not seen, and a rather mysterious error about a missing attribute appears. Again, my suggestion is to catch this error and see if it comes from incomplete initialisation. |
comment:13
Argh, it is even funnier: The attribute error is raised when trying to format the error message! So, for a nicer error message, we need to have a try-except around the creation of a string representation. |
comment:14
Even stranger, I see the following:
I think a Bug in ipython?? |
comment:15
Replying to @simon-king-jena:
Oops, yes, just a typo. When moving around the example, I changed the J0(31) to E=J0(11), and forgot to update the doctest. Thanks. |
comment:16
Replying to @simon-king-jena:
Glad we are on the same line :-) And thanks for checking and investigating further!
One thing: As to how important it is to actually do something about this: what's Cheers, |
comment:17
For the record, up to the trivial failing test noted in [comment:10], all long tests passed. |
comment:18
Replying to @nthiery:
Indeed, that's part of the problem with the broken pickle :attachment:broken_pickle.sobj
No idea. But if we find a way to unpickle the broken pickle without slowing down the mainline, then I'd say we should provide it. |
comment:19
Replying to @simon-king-jena:
No, it isn't. The caveat was that calling In any case, when we only raise an error if the category does not match and So, question: How can I post the updated picklejar? |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:35
Let me see how difficult it will be to fix. |
comment:36
I suggest that Doing so makes |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:38
It seems to work. At least: Tests of So, see if you like the changes (and promote yourself to a "Reviewer"...). Provided that the full test suite passes, which I will be testing later. |
Changed author from Nicolas M. Thiéry to Nicolas M. Thiéry, Simon King |
comment:39
Replying to @simon-king-jena:
It will inform us indeed. But if as a developer I wonder why all this But I don't have a strong opinion about that either. But yes, I agree, it's a bit cryptic. And it's not (yet?) common usage even though it's not unprecedented either (see
There was a race condition; I still was on the previous commit :-) Cheers, |
Changed reviewer from Simon King to Simon King, Nicolas M. Thiéry |
comment:40
I am happy with the change making SimplicialComplex a CategoryObject. So I guess this is positive review once the pickle jar thing is settled and it's confirmed that all tests pass. |
comment:41
This is with the (locally) updated pickle jar. Concerning pickle jar, I asked on sage-devel how to add to the pickle jar (in the sense of "how to post changes to a trac ticket, as the pickle jar is not under version control"). There has been no answer yet. |
comment:42
Cool! Coming back to the idea of putting the pickle as a doctest; there is a Hmm, ok, maybe that's a bit too long in this case :-)
Cheers, |
comment:43
I think the update of the pickle jar is not sooooo urgent. #11720 asks for a regular update of the pickle jar, though. One could argue that we did care of the potential problem, and (as you said before) the probability of finding important pickles that would now be broken is relatively slim. So, I'd say it is a positive review. |
Changed branch from u/SimonKing/ticket/16275 to |
comment:46
Could you please justify your use of |
Changed commit from |
comment:47
Replying to @jdemeyer:
I have no specific insight there: the previous code was using BaseException at this point (or rather the analogue thereof) and I just carried it over. Indeed |
comment:48
In one of the commits, I see
This pretty much explains it. I have never seen such error. However, if for some silly reason the test " |
comment:49
If I am not mistaken, |
comment:50
Replying to @simon-king-jena:
You are mistaken.
|
comment:51
Oops, it is a |
comment:52
The bottom line is: if you want to catch every "normal" exception, use The only use cases for |
comment:53
Replying to @jdemeyer:
OK. I agree it ought to be changed, and if it can wait till tomorrow then I'll change it myself. |
comment:54
I will fix it on #17076. |
As was noticed in #14793, some sanity checks need to be disabled in Hom when called upon unpickling because the input may include an unitialized parent. Since #14793, this is achieved by looking at the parent to detect if it is unitilialized.
As an alternative, this ticket proposes to add a
check=True/False
optional argument to Hom, and to use it upon unpickling. The advantages are:
The logic is quite simpler, slightly faster, and more robust.
This check argument is of general purpose, and indeed immediately
put to use when Hom calls itself recursively.
It made it easier for the first feature below
A potential caveat: pickles created since #14793 might not unpickle
properly. This was very recent; do we care?
Other changes in this ticket:
Hom now uses
X in category
as sanity check rather thanX.category().is_subcategory(category)
. This is more expressive,and indeed a necessary preliminary step for Categories over a base ring category #15801 which makes those
two idioms not always equivalent (example:
X
is aQQ
-module,X.category()
isModules(Rings)
andcategory
isModules(QQ)
)A bug fix for Homsets between simplicial complexes over some higher
category (Hom was not checking its input).
CC: @simon-king-jena @tscrim
Component: categories
Keywords: homset
Author: Nicolas M. Thiéry, Simon King
Branch:
e1e916c
Reviewer: Simon King, Nicolas M. Thiéry
Issue created by migration from https://trac.sagemath.org/ticket/16275
The text was updated successfully, but these errors were encountered: