#11935: Make parent/element classes independent of base rings
------------------------------------------------------------------+---------
Reporter: SimonKing |
Owner:
Type: enhancement |
Status: needs_work
Priority: major |
Milestone: sage-5.10
Component: categories |
Resolution:
Keywords: parent class, element class, category | Work
issues:
Report Upstream: N/A |
Reviewers: Nicolas Thiery, Travis Scrimshaw
Authors: Simon King | Merged
in:
Dependencies: #9138, #11900, #11943, #12875, #12876, #12877 |
Stopgaps:
------------------------------------------------------------------+---------
Comment (by nthiery):
Hi Simon!
Thanks for your work on this patch!
Replying to [comment:104 SimonKing]:
> Earlier today, I wrote a long reply, but my laptop's battery seems to be
damaged, and without a warning the computer shut down and the whole text
was lost. Bad.
Ouch. I got struck by this as well, and this is very annoying. I am
now protecting myself from such loss by using the cool "It's all text"
extension to firefox to edit the trac fields in my favorite editor,
and making sure that the temporary file used for that actually lives
in my home directory and not /tmp.
> Replying to [comment:100 nthiery]:
> OK. But at some point, we want to mix the abstract class with a concrete
class. For example, if P is a parent, we have `P.element_class`, which
mixes an abstract class `P.category().element_class` with a concrete class
`P.Element`.
Indeed, P.element_class and C.element_class have different status. The
former is a concrete class, while the later is an abstract class. I
guess I should have been more specific: the hierarchy of *category*
classes for parents (i.e. all the C.parent_class's) is perfectly
parallel to that of categories (all the C's).
> But the first problem arises if the base class of H is an extension
> class. Then, `H.__class__` can't be overridden, and thus inheritance
> from the abstract class is by the custom `__getattr__` of Parent,
> which is slow compared with proper inheritance.
Right, but that's no different than for other parents and element. We
have lived with it so far, and as long as Cython won't allow multiple
inheritance from purely abstract classes we will have to. But there is
hope: Robert mentioned several times that there is no theoretical
barrier and that it just needs to be implemented :-)
> The second problem is in `Hom(X,Y,category)`. First
> `X._Hom_(Y,category)` is attempted, but if this doesn't return
> anything useful, the ''abstract'' class
> `C.hom_category().parent_class` is instantiated.
> {{{
> H = category.hom_category().parent_class(X, Y, category = category)
> }}}
Not anymore! Line 306 of homset.py, with the patch applied, if no
_Hom_ method is provided by the parent or the parent class, then Hom
resorts to:
{{{
H = Homset(X, Y, category = category)
}}}
which creates H as an instance of the concrete base class Homset with
the appropriate category.
> And even worse things happen in
`sage.categories.rings.Rings.HomCategory.ParentMethods.__new__`, which is
a very ugly hack that should be avoided IMHO.
You mean in sage.categories.schemes, right?
Yikes. I had forgotten about this old hacky workaround I had
introduced at the beginning of categories. I am pretty sure we can now
get rid of it using an appropriate _Hom_ method in
Schemes.ParentMethods. And indeed, this ticket would be a good time to
get rid of it. I'll have a look!
> If you don't like bases, what do you think of the following alternative
model?
> ...
I agree that all _Hom_ methods are basically doing the same thing:
specifying what concrete homset class to do. So your approach could
remove a bit of duplication. On the other hand, the _Hom_ approach is
flexible and has already been used for a while in Sage. And it's
already implemented :-)
As for the homset class: we had indeed discussed this in Orsay, and
the plan is described in #10668. Basically, as you point out,
super_categories for Hom categories should be fixed so that
C.HomCategory() is a super category of S.HomCategory() only if C is a
full subcategory of S. Then nothing special needs to be done for
abstract homset classes in categories; they are just regular abstract
parent classes. On the other hand something needs to be done for
morphisms, so that a morphism in C gets code for morphisms of S. To
implement this, we want to have C.morphism_class and associated
MorphismMethods, with inheritance done properly.
That's actually partially implemented in the (disabled):
http://combinat.sagemath.org/patches/file/tip/category-hom_methods-
nt.patch
and looked like it was going to work smoothly.
> So, question: Do you think that this model is the way to go? It
> keeps abstract and concrete classes neatly apart, it will reduce the
> need to have custom `X._Hom_(...)`, and we could get rid of the hack
> with `__new__`.
>
> If you agree, then I'd say we try to finalise the patch here in the
> way you suggested, namely without allowing base classes. And in a
> second step (I think I have opened an according ticket 2 or 3 years
> ago) we could implement the model I sketched.
I'd say: as you suggest, let's finish the patch as is (hopefully with
the __new__ removed). Then let's move on to the other functorial
construction patch. Then cythonization of homsets / #10668 / ... Then,
with the experience, if we find ourselves implementing _Hom_ methods
too often, we can introduce a nicer protocol like the one you propose
to only provide a class.
I guess one point of it is that I don't have a good view on whether we
will have so many concrete classes for homsets (for morphism that's a
different story!).
> > Could you point me to the exact problem that arised when you worked on
it?
> No. It has been a while ago, and I lost track, I am afraid.
Ok. Let me know if you stumble again on it!
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11935#comment:106>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
