#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963-doc- | Commit:
distributive | c718f218fbc726bf3cf7f4c3f20638c9b0c7eea7
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Hi Volker!
Replying to [comment:499 vbraun]:
> The metaclass approach for inner categories as subcategories works now.
I've switched it to attributes
> {{{#!python
> class FiniteCommutativeTest1(CategoryWithAxioms):
> __base_category_class__ = Test1
> __axiom_classes__ = frozenset([axioms.Commutative, axioms.Finite])
> }}}
> but inheritance from axioms works, too
> {{{#!python
> class Test2(Category):
> class FiniteCommutative2(InnerCategory, axioms.Finite,
axioms.Commutative):
> pass
> }}}
> see
http://git.sagemath.org/sage.git/tree/src/sage/categories/category_with_axioms.py?h=c520eb0bddcf6543d037dad3c7f0b808ae29b160
Cool. Just 2 cents: a potential close variant could be:
> {{{#!python
> class FiniteCommutativeTest1(axioms.Finite.Category,
axioms.Commutative.Category):
> __base_category_class__ = Test1
>
> class Test2(Category):
> class FiniteCommutative2(axioms.Finite.Category,
axioms.Commutative.Category):
> pass
> }}}
where {{{axioms.Finite.Category}}} (or some better name) would be a
class for the categories implementing the axiom Finite (and possibly
other axioms) for some base category. Ah, maybe
{{{_base_category_class_}}} since it's a Sage special attribute, not a
Python one; but that's just a detail.
> I haven't implemented relations in the category manager, though one
could keep that simple and leave more complicated things for later.
If we support Wedderburn's like relations right now, and are
reasonably convinced that we can eventually support everything that
the current infrastructure supports, sure.
> One thing that I think is tricky is to derive rules from implications A
=> B => C => A, especially if `all_super_categories` is actually missing
some super categories.
Ok. We agree that the current infrastructure has no problem with that,
right?
> To answer your timeline question, I'd say less than a month.
Ok.
Thanks for your work on exploring alternative implementation and
syntax! I still personally believe this belongs to a follow up ticket,
but this is an open debate. To substantiate this debate, it would be
useful that we clarify the scope of your proposal and implementation
in progress, in particular about which issues / further features it's
aiming to address, and what could be the inconveniences. Feel free to
save time and just answer yes/no for now if you are convinced about
the answer; your prototype will be the proof :-)
- The main point is that it removes the current limitation that we can
add only a single axiom at a time, right? How many spots in the
current category code will be improved by this?
- Will it allow for completely getting rid of the couple remaining
"placeholder categories", both statically and dynamically?
- Will the proposal make for a cleaner implementation of axioms like
Distributive?
{{{
sage: (CommutativeAdditiveGroups() & Monoids()).Distributive()
Category of rings
}}}
- Is it going to reuse the current join implementation, for example by
delegating the work to it by building the required arborescence
behind the scene? Or will the manager replace this piece too? If
it's not using an arborescence of some kind, what kind of complexity
can we roughly expect to have?
- Is it compatible with lazy importing categories with axioms? (I am
ready to believe that this can be made to work, but one has to be a
bit careful in the join implementation).
- Will the proposal allow for getting rid of the global list of
axioms/axiom names? If yes, how will the printing out be handled?
- The proposal requires to get through the dictionary of the category
classes, right? At first sight this is making me nervous (though not
as much as if this was on instances). Is it guaranteed that this
won't trigger accidently, say, lazy imports that might be there for
other features (like functorial constructions)?
- Will some class binding with {{{__classget__}}} be still needed? If
yes, how will the idiom {{{__base_category_class__ = Test1}}} work
if {{{Test1}}} is itself a {{{CategoryWithAxiom/InnerCategory}}}?
- Where will the idiom {{{XXX.Finite()}}} be implemented? In particular,
will introspection on {{{XXX.Finite?}}} work as it currently does?
- Where would be the natural place to put the axioms? If it's under
{{{axioms.*}}}, how will potential name clashes be handled?
Thanks!
Something that will be harder to evaluate without some large examples
(e.g. refactoring a non trivial part of the current categories; say
everything above {{{Fields()}}}), is whether the new infrastructure
will altogether be more practical as the current one. My current
impression is that it will require more imports, which can be
annoying, and that defining new axioms will take a bit more work.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:500>
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.
For more options, visit https://groups.google.com/groups/opt_out.
