#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
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 | Commit:
Dependencies: #11224, #8327, | 8045aa4a4b7ada735b3eb6055382f9b341a39f1e
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:378 nthiery]:
> ``base_category`` is used in a few spots for computing stuff
> recursively. This is includes _without_axioms (a trivial recursion),
Is that even a well-defined operation? Given that
{{{
DivisionRings().Finite().base_category()
}}}
is not `DivisionRings`, it's not clear to me that this process is
guaranteed to
undo the application of "axioms". In this case it works because both
`DivisionRings()` and `Fields()` are obtained via axioms from a common
category.
But that also means that we didn't have to recurse up via a marked "base
category". We could have taken any supercategory that is of type
`CategoryWithAxiom`. There's a theorem to be proved that such a greedy
approach
works, but the commutativity of applying axioms should take care of that.
> and more importantly the calculations of the super categories (a
> tricky recursion).
Yup, this bit:
{{{
base_category = self._base_category
axiom = self._axiom
extra = self.extra_super_categories()
return Category.join((self._base_category,) +
tuple(base_category.super_categories()) +
tuple(extra),
axioms = (axiom,),
uniq=False,
ignore_axioms = ((base_category, axiom),),
as_list = True)
}}}
This code just needs some supercategories that tie this thing into the
category hierarchy. Apparently `(base,)+base.super_categories+extra` is
enough,
for some base that is present upon initialization. Why bother keeping the
base
special if it's not inherently special.
From:
{{{
sage: V=Fields().Finite().super_categories()
sage: V=flatten([v.super_categories() for v in V])
sage: V=flatten([v.super_categories() for v in V])
sage: V
[Category of principal ideal domains,
Category of domains,
Category of semigroups,
Category of unital magmas,
Category of semigroups,
Category of finite enumerated sets]
}}}
you can already see that the supercategories as returned now lead to
multiple
paths to the same thing any way, so (as always when walking up a tree) you
need
to keep track of already visited nodes any way. Limiting recursion to just
"base" isn't going to alleviate that.
> I agree that this is mostly for internal use. But it's consistent with
> functorial constructions and the like to have the .base_category()
method.
Since it has no meaning here, I don't see why this consistency is
desirable. I'd
say it's misleading.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:400>
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.
