#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.1
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 | 3e2003ded77192465cc3e99fec7fa64dae998950
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Changes (by nthiery):
* changetime: 01/30/14 07:01:36 => 01/30/14 07:01:36
Comment:
Replying to [comment:486 vbraun]:
> Must not, should not, need not?
Eh, eh, right, I indulged myself with a bit of pedantic picky-ness :-)
I certainly agree about being pragmatic. As I said before, if a small
abuse gives nice notations, while remaining safe and unambiguous,
that's ok for me.
> I agree, of course, that the category-
> relationship is unrelated to the object-relationship. But if its
> convenient to define your category by object-inheriting from another
> category, then why not?
>
> I would prefer to treat axioms as independent from categories (i.e.
they
> don't inherit from Category). That then also gives you a non-category
> object that you can use to represent the axiom. Now, since you always
have
> to create (manually or dynamically) a new class for a category-with-
axiom
> it might just as well inherit from the axiom class(es). Though if you
> think its confusing then I'm also open to using a special class
attribute
> and composition.
For specifying the super/base category, I vote for using
composition. The number of mathematical methods on categories (like
is_abelian) that are incompatible with taking subcategories is bound
to grow with time, together with the risk of obtaining mathematically
incorrect results.
For the axiom side, that's probably ok, as I don't foresee much
features in the axiom classes (though I might be wrong). A variant
would be to use something like:
{{{
class Finite(axioms.Finite.Category):
...
}}}
and then there would be no issue.
> Now for something different. For the super categories, is the following
> what we really want? Its good enough for figuring out the methods, but
> does contradict the `super_category` documentation:
> ...
Ah yes, good point, the documentation must be made explicit about this
behavior: it's not really new, but is being pushed to the next level
by axioms. I'll work on that.
Given that the number of categories that can be constructed in Sage is
potentially exponential we really want to focus on the hierarchy of
those categories that are actually implemented (i.e. that are not
constructed as JoinCategory's). That's roughly the usual trick of
representing a lattice by the poset of its atoms.
In particular, the super_categories method is meant to return the
direct super categories in the hierarchy of *implemented* categories.
Note that is_subcategory works as desired.
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:493>
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.
