Sage: Ticket #12877: Categories for padics, schemes, and some more rings
https://trac.sagemath.org/ticket/12877
<p>
This patch fixes the following classes to use categories:
</p>
<ul><li>padics
</li><li><a class="missing wiki">RealLazyField?</a>, <a class="missing wiki">ComplexLazyField?</a>
</li><li><a class="missing wiki">AlgebraicScheme?</a>'s and subclasses
</li></ul><p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/11935" title="#11935: enhancement: Make parent/element classes independent of base rings (closed: fixed)">#11935</a> depends on this one
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/12877
Trac 1.2Nicolas M. ThiéryTue, 24 Apr 2012 22:02:43 GMTstatus changed
https://trac.sagemath.org/ticket/12877#comment:1
https://trac.sagemath.org/ticket/12877#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketNicolas M. ThiéryTue, 24 Apr 2012 22:06:52 GMTattachment set
https://trac.sagemath.org/ticket/12877
https://trac.sagemath.org/ticket/12877
<ul>
<li><strong>attachment</strong>
set to <em>trac_12877-category-for_more_rings_and_schemes-nt.patch</em>
</li>
</ul>
TicketSimon KingThu, 26 Apr 2012 08:19:56 GMT
https://trac.sagemath.org/ticket/12877#comment:2
https://trac.sagemath.org/ticket/12877#comment:2
<p>
Hooray, finally the category of schemes is used in Sage! Question: Are there morphisms of schemes, yet? I am first reviewing <a class="closed ticket" href="https://trac.sagemath.org/ticket/12875" title="#12875: defect: Fix the homset category initialization for ModularAbelianVariety's ... (closed: fixed)">#12875</a> and will then also look at the ticket here.
</p>
TicketNicolas M. ThiéryThu, 26 Apr 2012 09:32:08 GMT
https://trac.sagemath.org/ticket/12877#comment:3
https://trac.sagemath.org/ticket/12877#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12877#comment:2" title="Comment 2">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Hooray, finally the category of schemes is used in Sage! Question: Are there morphisms of schemes, yet? I am first reviewing <a class="closed ticket" href="https://trac.sagemath.org/ticket/12875" title="#12875: defect: Fix the homset category initialization for ModularAbelianVariety's ... (closed: fixed)">#12875</a> and will then also look at the ticket here.
</p>
</blockquote>
<p>
Apparently yes :-)
</p>
<pre class="wiki">sage: sage: k = GF(11)
sage: E = EllipticCurve(k,[1,1])
sage: Q = E(6,5)
sage: phi = E.isogeny(Q)
sage: phi.parent()
Set of Morphisms from Abelian group of points on Elliptic Curve defined by y^2 = x^3 + x + 1 over Finite Field of size 11 to Abelian group of points on Elliptic Curve defined by y^2 = x^3 + 7*x + 8 over Finite Field of size 11 in Category of hom sets in Category of Schemes
sage: phi.parent().homset_category()
Category of hom sets in Category of Schemes
</pre><p>
(which by the way should really be Category of Schemes; see <a class="closed ticket" href="https://trac.sagemath.org/ticket/12880" title="#12880: defect: Inconsistent domain, codomain and parent in EllipticCurveIsogeny (closed: fixed)">#12880</a>)
</p>
TicketSimon KingThu, 26 Apr 2012 10:46:46 GMT
https://trac.sagemath.org/ticket/12877#comment:4
https://trac.sagemath.org/ticket/12877#comment:4
<p>
As you point out in a comment, due to the custom <code>__getattr__</code> method, subclasses of <code>LazyField</code> can not be extension classes (because <code>Parent.__getattr__</code> is only needed when the class of the parent can not be turned into a subclass of the category's parent_class).
</p>
<p>
I am sure that you did try something like <code>getattr(super(self,LazyField),name)</code>. Did that not work? Why?
</p>
<p>
By consequence, you (have to) turn <code>cdef class ComplexLazyField_class(LazyField)</code> into <code>class ComplexLazyField_class(LazyField)</code>. Did you investigate potential speed penalties?
</p>
<p>
In the initialisation of <code>LocalGeneric</code>, which inherits from <code>CommutativeRing</code>, you still call <code>Parent.__init__</code> (with category support added), but not <code>CommutativeRing.__init__</code>, which would automatically grant category support. Why?
</p>
TicketSimon KingThu, 26 Apr 2012 11:04:03 GMTowner deleted
https://trac.sagemath.org/ticket/12877#comment:5
https://trac.sagemath.org/ticket/12877#comment:5
<ul>
<li><strong>owner</strong>
<em>Nicolas M. Thiéry</em> deleted
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12877#comment:4" title="Comment 4">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
I am sure that you did try something like <code>getattr(super(self,LazyField),name)</code>. Did that not work? Why?
</p>
</blockquote>
<p>
I tested (it should be <code>super(LazyField,self)</code>), and indeed it does not work. But still, one could add the stuff from the custom <code>Parent.__getattr__</code> into the custom <code>LazyField.__getattr__</code>:
</p>
<pre class="wiki">sage: cython("""
....: from sage.structure.parent cimport Parent
....: from sage.structure.parent import getattr_from_other_class
....: cdef class MyParent(Parent):
....: def __getattr__(self, name):
....: print "here is the custom getattr with", name
....: return getattr_from_other_class(self, self.category().parent_class, name)
....: """)
sage: P = MyParent(category=CommutativeAdditiveSemigroups())
here is the custom getattr with _element_constructor_
here is the custom getattr with Element
here is the custom getattr with element_class
sage: P.addition_table
here is the custom getattr with addition_table
here is the custom getattr with __custom_name
here is the custom getattr with _repr_
<bound method CommutativeAdditiveSemigroups.parent_class.addition_table of <type '_mnt_local_king__sage_temp_mpc622_12258_tmp_4_spyx_0.MyParent'>>
</pre><p>
There is also some more stuff in <code>Parent.__getattr__</code>, that was written for cached methods.
</p>
<p>
The question is whether the code duplication would be worth the effort.
</p>
TicketSimon KingThu, 26 Apr 2012 11:08:07 GMT
https://trac.sagemath.org/ticket/12877#comment:6
https://trac.sagemath.org/ticket/12877#comment:6
<p>
But it is really strange:
</p>
<pre class="wiki">sage: MyParent.__getattr__
<method '__getattr__' of '_mnt_local_king__sage_temp_mpc622_12258_tmp_4_spyx_0.MyParent' objects>
sage: Parent.__getattr__
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
/mnt/local/king/SAGE/experiment/notebook/sage-5.1.notebook/devel/sage-main/<ipython console> in <module>()
AttributeError: type object 'sage.structure.parent.Parent' has no attribute '__getattr__'
</pre><p>
So, why is <code>Parent.__getattr__</code> seemingly unavailable, although it is frequently used?
</p>
TicketNicolas M. ThiéryThu, 26 Apr 2012 11:25:20 GMT
https://trac.sagemath.org/ticket/12877#comment:7
https://trac.sagemath.org/ticket/12877#comment:7
<p>
Thanks for reproducing here my unsuccessful attempts :-)
</p>
<p>
Now is it worth the trouble? It's about the parent, not the elements. In the similar situation for QQ we decided for QQ not to be an extension type. It would be surprising if there would be methods on RLF that would be more critical than on QQ, wouldn't it?
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
TicketSimon KingThu, 26 Apr 2012 12:00:23 GMT
https://trac.sagemath.org/ticket/12877#comment:8
https://trac.sagemath.org/ticket/12877#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12877#comment:7" title="Comment 7">nthiery</a>:
</p>
<blockquote class="citation">
<p>
Thanks for reproducing here my unsuccessful attempts :-)
</p>
</blockquote>
<p>
You're welcome; but still I'd like to understand why one can see <code>__getattr__</code> of a custom cdef class that is derived from Parent, but can not see <code>__getattr__</code> of Parent.
</p>
TicketSimon KingThu, 26 Apr 2012 12:05:40 GMT
https://trac.sagemath.org/ticket/12877#comment:9
https://trac.sagemath.org/ticket/12877#comment:9
<p>
There only remains one question: Why is <code>Parent.__init__</code> and not <code>CommutativeRing.__init__</code> called in <code>LocalGeneric</code>? Well, I'll test it, and will submit a reviewer patch if it works. With your patch, all doctests pass...
</p>
TicketSimon KingThu, 26 Apr 2012 12:17:26 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/12877#comment:10
https://trac.sagemath.org/ticket/12877#comment:10
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Simon King</em>
</li>
</ul>
<p>
I see. Keywords such as element_constructor aren't accepted by <code>CommutativeRing.__init__</code>. So, no reviewer patch.
</p>
<p>
I accept your argument about <code>RLF</code> not being of extension type. Since the doctests pass and the patch looks fine, I give it a positive review.
</p>
<p>
However, I'd like to understand how Parent differs from other classes with a custom <code>__getattr__</code>.
</p>
TicketNicolas M. ThiéryThu, 26 Apr 2012 15:47:51 GMT
https://trac.sagemath.org/ticket/12877#comment:11
https://trac.sagemath.org/ticket/12877#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12877#comment:10" title="Comment 10">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
I accept your argument about <code>RLF</code> not being of extension type. Since the doctests pass and the patch looks fine, I give it a positive review.
</p>
</blockquote>
<p>
Thanks for the quick review!
</p>
<blockquote class="citation">
<p>
However, I'd like to understand how Parent differs from other classes with a custom <code>__getattr__</code>.
</p>
</blockquote>
<p>
I guess it's a question of extension types versus non extension types.
</p>
TicketSimon KingThu, 26 Apr 2012 16:21:20 GMT
https://trac.sagemath.org/ticket/12877#comment:12
https://trac.sagemath.org/ticket/12877#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12877#comment:11" title="Comment 11">nthiery</a>:
</p>
<blockquote class="citation">
<p>
I guess it's a question of extension types versus non extension types.
</p>
</blockquote>
<p>
No, it isn't.
</p>
<pre class="wiki">sage: cython("""
....: cdef class MyParent(object):
....: def __getattr__(self, str name):
....: raise AttributeError,name
....: """)
sage: MyParent.__getattr__
<method '__getattr__' of '_mnt_local_king__sage_temp_mpc622_20365_tmp_0_spyx_0.MyParent' objects>
</pre><p>
At least that is what I find with sage-5.1.notebook. I do get an error in an old version of Sage that still uses the old Cython spkg.
</p>
TicketNicolas M. ThiéryThu, 26 Apr 2012 17:10:39 GMT
https://trac.sagemath.org/ticket/12877#comment:13
https://trac.sagemath.org/ticket/12877#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12877#comment:12" title="Comment 12">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12877#comment:11" title="Comment 11">nthiery</a>:
</p>
<blockquote class="citation">
<p>
I guess it's a question of extension types versus non extension types.
</p>
</blockquote>
<p>
No, it isn't.
</p>
</blockquote>
<p>
Ouch, that's weird ...
</p>
TicketJeroen DemeyerWed, 23 May 2012 21:36:27 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/12877#comment:14
https://trac.sagemath.org/ticket/12877#comment:14
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-5.1.beta1</em>
</li>
</ul>
Ticket