-
-
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
The default call method of maps does not do as promised by the documentation #10496
Comments
Author: Simon King |
Reviewer: David Roe |
comment:2
I approve of the design and goals, but I'm worried about the implementation speed. The current implementation does not introduce much overhead over
are both pretty costly calls. I think you need to add some fast pathways for common cases, such as Similarly, use |
comment:3
Replying to @roed314:
Right, I'll do so. Note that I use What common cases, apart from
My patch introduces only one "isinstance", namely in the call method of A propos: I was not aware of that Cython alternative to I also found another way to speed the generic call method up: The current implementation does
Using
So, I'll change the patch accordingly. |
comment:4
I updated my patch. Here are some timings for different situations. With the patch:
The same examples without my patch:
Hence:
So, I do think that overall it is a progress. I am now starting doctests, but I think it is ready for review again. |
comment:5
I think there is yet another way to speed things slightly up. If there is coercion then there is a coerce map. Hence, rather than testing "self._domain.has_coerce_map_from(P)", one could directly request "caller=self._domain.coerce_map_from(P)", and then do "caller(x)" if it is not None. That should be faster than doing "self._domain(x)", because the call method of "self._domain" would request a coerce map as well! I'll test a bit later. So, it will be "needs work" for two hours or so. |
Work Issues: speed things up |
Attachment: 10496default_call.patch.gz |
comment:6
Here are the same tests again, with the updated patch:
I think that are acceptable timings: No significant slowdown, but a significant speedup in one case, and some bug fixes. Back to "needs review", modulo passing doctests... |
comment:7
Doctests do pass for me. |
comment:8
Looks good in general. I'm traveling today, but once I have a bit of time I'll take a look at your changes. |
comment:9
Looks good to me. You asked about documentation for PY_TYPE_CHECK earlier; I'm not sure where to find documentation, but the functions are included in Anyway, positive review. |
Changed work issues from speed things up to none |
Merged: sage-4.6.2.alpha1 |
The documentation of
sage.categories.map.Map.__call__
states:However, in the code, we had
Hence, there is a typo in the documentation (it is pushforward, not pushout):
If the argument is no element, one should expect that
pushforward
rather than_call_
is called. This is a problem if the argument happens to be a sub-module. Sub-modules are no elements (this is incontrast to ideals). Hence, currently, module morphisms have to implement a custom__call__
method.In contrast to the statement of the documentation, the code is only about conversion, but not about coercion. I think this is a problem, as in the following example. There is no coercion from the abstract number field to the embedded number field, but no error is raised when calling the coerce embedding of the embedded field with an element of the abstract field:
_call_
(single underscore) and_call_with_args
methods one can assume that the argument belongs to the domain of the map. This is, however, not the case, since an argument that is not an element (like a python int, for example!) will not be converted into the domain before passing it to_call_
.I propose the following:
parent(x)
does not coerce into the map's domain,pushforward
is called onx
together with the additional arguments. If it is not implemented or produces aTypeError
, proceed with the next step.x
into the domain; this is now either a coercion, or it is a back-up solution for the failing pushfoward. If the conversion fails, raise an error that mentions the pushforward method._call_
resp._call_with_args
.There is a new doc test, demonstrating
_call_
,_call_with_args
andpushforward
. Apart from that, only small changes were needed in the doctests: Some error messages have changed.I have no idea about the proper component. I hope "coercion" is fine.
Component: coercion
Keywords: generic call map
Author: Simon King
Reviewer: David Roe
Merged: sage-4.6.2.alpha1
Issue created by migration from https://trac.sagemath.org/ticket/10496
The text was updated successfully, but these errors were encountered: