Should categories have a category?
Simon King
I just noticed
sage: C = Semigroups()
sage: C.category()
Category of objects
I guess the notion "category of all categories" would be a self-
contradiction similar to "set of all sets". But I think "category of
objects" doesn't really make sense either.
Is there a veto against removing Category.category()?
Cheers,
Simon
Nicolas M. Thiery
I don't have an opinion. It could still be eventually useful to have a
top category (Objects), to provide generic code to all Sage objects
(it does not quite yet).
Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
David R. Kohel
My original view for introducing categories was to have a mechanism
for certifying morphisms (within a given category) [useful in input
verification in programming, etc.], and eventually being able to
implement functors. Essentially constructors like FreeModule(K,-) are
functors where an integer n is interpretted as the set {0,..,n-1};
this could be extended to send morphisms of sets to morphisms of
K-modules. Such a formalism doesn't exist.
To avoid Russell's paradox, one usually considers the "category of
small categories". This would be the correct structure to return,
but lacking any real implementation of functors, it doesn't make
much sense to implement such a category.
I doubt if this is used anywhere. If it is, since the category
itself is not that which I would define as mathematically correct,
it is likely to lead to contradictions.
I would vote for removal, but someone familier with the design
intent of this:
sage: SG = Semigroups()
sage: C = SG.category()
sage: SG in C
True
sage: ZZ in C
True
sage: Hom(SG,ZZ)
Set of Morphisms from Category of semigroups to Integer Ring in Category of objects
sage: type(SG)
<class 'sage.categories.semigroups.Semigroups'>
sage: type(C)
<class 'sage.categories.objects.Objects'>
sage: isinstance(C,SageObject)
True
sage: isinstance(SG,SageObject)
should comment.
--David
Simon King
On 4 Jan., 11:14, "David R. Kohel" <ko...@iml.univ-mrs.fr> wrote:
> Essentially constructors like FreeModule(K,-) are
> functors where an integer n is interpretted as the set {0,..,n-1};
> this could be extended to send morphisms of sets to morphisms of
> K-modules. Such a formalism doesn't exist.
introduces a framework for implementing application of a functor to a
morphism, and in many cases (e.g., for most construction functors) the
ticket also provides an actual implementation (not only the
framework).
> To avoid Russell's paradox, one usually considers the "category of
> small categories". This would be the correct structure to return,
small categories" would not be the right thing to return for
"Sets().category()".
> but lacking any real implementation of functors, it doesn't make
> much sense to implement such a category.
@Nicolas:
> > top category (Objects), to provide generic code to all Sage objects
> > (it does not quite yet).
code to all Sage objects?
And is the idea of a "top category" mathematically rigid?
I heard that one can define a "pseudo-category" of categories,
including big categories. I am not sure what the mathematical
difference between a category and a pseudo-category is. But how could
one implement it?
Certainly a pseudo-category is very similar to a category; there is at
least one exception, namely that a pseudo-category should definitely
not have a method "category".
The following might be a half-baked brain storm, but perhaps it works
like this:
* Have a class PseudoCategory that is essentially formed by most of
the current implementation of ``Category``, but not inheriting from
anything (i.e., not inheriting from CategoryObject or SageObject), and
whose parent class is what is now CategoryObject and whose element
class is what is now SageObject. In particular, generic stuff should
be provided there.
* Have a unique instance Categories of PseudoCategory (we don't want
to have any other pseudo-categories, because we don't want to end up
with the pseudo-pseudo-category of pseudo-categories).
* ``Category`` shall be derived from both PseudoCategory and
PseudoCategory.ParentClass (which is essentially CategoryObject).
Would that be technically possible? ``Category`` would inherit the
parent and element classes (CategoryObject and SageObject) from
PseudoCategory.
* The generic category() method of CategoryObject returns
``Categories`` (the unique instance of ``PseudoCategory``), and the
class ``Category`` simply inherits it. But of course, all other
CategoryObjects should override categories().
Cheers,
Simon
Nicolas M. Thiery
On Tue, Jan 04, 2011 at 04:27:22AM -0800, Simon King wrote:
> Note that #8807 (which has a positive review but isn't merged, yet)
> introduces a framework for implementing application of a functor to a
> morphism, and in many cases (e.g., for most construction functors) the
> ticket also provides an actual implementation (not only the
> framework).
Cool!
> > To avoid Russell's paradox, one usually considers the "category of
> > small categories". �This would be the correct structure to return,
>
> Am I mistaken, or is Sets() not a small category? Then, "category of
> small categories" would not be the right thing to return for
> "Sets().category()".
We can just make Sets() into a small category, by amending its
specification appropriately. E.g. define Sets() as the category of all
sets that can be modelled in Sage at any given point (there are only
countably many of those!).
> @Nicolas:
> > > I don't have an opinion. It could still be eventually useful to have a
> > > top category (Objects), to provide generic code to all Sage objects
> > > (it does not quite yet).
>
> Wouldn't the class SageObject be the right place to provide generic
> code to all Sage objects?
I don't know at this point. In basically all our use cases so far, our
categories are subcategories of Sets and are used to provide code to
parents and elements. That might evolve; I would not worry too much
about it in the mean time.
> And is the idea of a "top category" mathematically rigid?
That's probably subject to paradoxes. But I doubt it will hurt us
inadvertently (very much like Russel's paradox never goes in the way
in everyday's mathematics unless, one explicitly looks for trouble).
> I heard that one can define a "pseudo-category" of categories,
> including big categories. I am not sure what the mathematical
> difference between a category and a pseudo-category is. But how
> could one implement it?
> ...
My 2 cents: There sure must be a lot of fun maths and design to do in
this direction. Yet, I'd rather leave that area as blank as possible:
either we will never wander in those troubled water, and then there is
no reason to introduce new concepts; or we will, and then I'd rather
have serious use cases under hand before taking any design decision.
So at this point, I vote for either removing the category methods when
we don't have a good view of what the result should be, or just to
leave things as is, just adding notes that this is not necessarily
meaningful and thus subject to change at any point.
Pragmatically yours :-)
Nicolas M. Thiery
> I would vote for removal, but someone familier with the design
> intent of this:
>
> sage: SG = Semigroups()
> sage: C = SG.category()
> sage: SG in C
> True
> sage: ZZ in C
> True
> sage: Hom(SG,ZZ)
> Set of Morphisms from Category of semigroups to Integer Ring in Category of objects
> sage: type(SG)
> <class 'sage.categories.semigroups.Semigroups'>
> sage: type(C)
> <class 'sage.categories.objects.Objects'>
> sage: isinstance(C,SageObject)
> True
> sage: isinstance(SG,SageObject)
>
> should comment.
My bet is that there was no specific design intent here. It's just as
it came out. Do you see it as specifically bad?
Simon King
On 4 Jan., 14:35, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
> this direction. Yet, I'd rather leave that area as blank as possible:
> either we will never wander in those troubled water, and then there is
> no reason to introduce new concepts; or we will, and then I'd rather
> have serious use cases under hand before taking any design decision.
> So at this point, I vote for either removing the category methods when
> we don't have a good view of what the result should be, or just to
> leave things as is, just adding notes that this is not necessarily
> meaningful and thus subject to change at any point.
* Aim: Clean up the code for group actions (of a group G on a set S).
The current implementation pretends to be based on functors, but
that's a fake, as the call method is totally different.
* Idea: It is good for efficiency that the call method is not like for
a functor (but then it should not be a class derived from Functor).
However, it would be good for conceptual work to also have an
implementation that really is a functor.
* Problem: The framework laid out in #8807 won't work yet, because the
elements of G are not yet recognised as morphisms of the category
Groupoid(G) (as discussed in another thread).
* While trying to make it work, I noticed that morphisms and elements
have a method category(). I wondered, why. Then I found that
SageObject (from which both elements and morphisms inherit) provides
things that I would only expect from CategoryObject.
* While trying to clearly separete CategoryObject (from which Parents
inherit) and SageObject (from which elements and morphisms inherit), I
had to decide whether Category inherits from CategoryObject (credo:
Any category is an object in the pseudo-category of categories, hence,
it is a CategoryObject) or only inherits from SageObject (Credo: It
would be very odd to consider a category as an object in another
category by *default*).
At that point, I asked here.
Having Category inherit from CategoryObject tends to create
mathematical mayhem. But when I removed Category.category(), many doc-
tests failed, so that the "easy way out" would be to keep
Category.category() for now.
I think it should better be removed, even though it means dull doctest
work. That work would still be easier than to implement pseudo-
categories...
Cheers,
Simon
Nicolas M. Thiery
> The reason why I came up with that whole discussion evolved like this:
> * Aim: Clean up the code for group actions (of a group G on a set S).
> The current implementation pretends to be based on functors, but
> that's a fake, as the call method is totally different.
> * Idea: It is good for efficiency that the call method is not like for
> a functor (but then it should not be a class derived from Functor).
> However, it would be good for conceptual work to also have an
> implementation that really is a functor.
> * Problem: The framework laid out in #8807 won't work yet, because the
> elements of G are not yet recognised as morphisms of the category
> Groupoid(G) (as discussed in another thread).
> * While trying to make it work, I noticed that morphisms and elements
> have a method category(). I wondered, why. Then I found that
> SageObject (from which both elements and morphisms inherit) provides
> things that I would only expect from CategoryObject.
> * While trying to clearly separete CategoryObject (from which Parents
> inherit) and SageObject (from which elements and morphisms inherit), I
> had to decide whether Category inherits from CategoryObject (credo:
> Any category is an object in the pseudo-category of categories, hence,
> it is a CategoryObject) or only inherits from SageObject (Credo: It
> would be very odd to consider a category as an object in another
> category by *default*).
> At that point, I asked here.
:-)
Thanks for going through all this trouble to clean things up! It's
worthwhile work for Sage!
> Having Category inherit from CategoryObject tends to create
> mathematical mayhem.
Yup.
> But when I removed Category.category(), many doc- tests failed, so
> that the "easy way out" would be to keep Category.category() for
> now. I think it should better be removed, even though it means dull
> doctest work.
If it was mine to do, I would choose the first option and just a leave
a ticket for the second one, in order to focus on the rest of the
cleanup. But both options are fine to me!
Cheers,