Re: Fwd: [sage-devel] Re: Categories restart

32 views
Skip to first unread message

William Stein

unread,
Jun 19, 2009, 6:29:47 AM6/19/09
to ko...@iml.univ-mrs.fr, Nicolas M. Thiery, sage-devel
On Fri, Jun 19, 2009 at 11:58 AM, <ko...@iml.univ-mrs.fr> wrote:
> Hi William,
>
> I'd be happy to have a look at referee this.  Do I need to apply
> the dozen or so patches, or what is required?  The challenge for
> the referee seems to be to sort out what has been refereed, what
> needs careful inspection.

I don't know the answers to any of those questions, so I've cc'd this
to sage-devel.

> Also, what version should I build against?

sage-4.0.2 (which will be released today) -- if anything doesn't apply, ask
Nic to rebase it.

William

>
> Cheers,
>
> David
>
> Quoting William Stein <wst...@gmail.com>:
>
>> David,
>>
>> Any chance you would be interested in reviewing this, e.g., at Sage
>> Days next week. After all, you were the first person to implement
>> categories in Sage.
>>
>> William
>>
>>
>> ---------- Forwarded message ----------
>> From: Nicolas M. Thiery <Nicolas...@u-psud.fr>
>> Date: Thu, Jun 18, 2009 at 9:59 AM
>> Subject: [sage-devel] Re: Categories restart
>> To: sage-...@googlegroups.com
>>
>>
>>
>>        Dear category fans!
>>
>> The original plan was for Craig to review the most mathematically
>> oriented (and therefore fun) part of the category patch, namely the
>> definition of the categories themselves. However he got burned out by
>> the handling of the Sage releases, and something tells me he could be
>> busy in the coming weeks :-)
>>
>> So, I am looking for volunteer(s) for taking over the review of this part!
>>
>> See categories-categories-nt.patch on:
>>
>>        http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap
>>
>> The good news is that, with #6343 extracted out, it is now much
>> smaller: 8000 lines "only", with lots of them just due to the
>> splitting of the category code in separate files.
>>
>> Please feel free to suggest names of potential reviewers as well :-)
>>
>> Thanks in advance!
>>
>> Cheers,
>>                                Nicolas
>> --
>> Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
>> http://Nicolas.Thiery.name/
>>
>> >>
>>
>>
>>
>> --
>> William Stein
>> Associate Professor of Mathematics
>> University of Washington
>> http://wstein.org
>>
>
>
>
>



--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

Nicolas M. Thiery

unread,
Jun 20, 2009, 11:58:35 AM6/20/09
to drk...@gmail.com, sage-...@googlegroups.com
Dear David,

On Fri, Jun 19, 2009 at 12:29:47PM +0200, William Stein wrote:
> On Fri, Jun 19, 2009 at 11:58 AM, <ko...@iml.univ-mrs.fr> wrote:
> > Hi William,
> >
> > I'd be happy to have a look at referee this.

Thanks so much for looking at this!

> > Do I need to apply the dozen or so patches, or what is required?

At SD15 we had agreed with the other reviewers that, given the number
of patches it was easiest to use the sage-combinat patch server
(installing the patches is a 1 minute thing: editing your .hgrc to
enable mercurial queues, and running `sage -combinat install` see
http://wiki.sagemath.org/combinat/MercurialStepByStep). Then, from
within the source run:

hg qpop categories-unpickle_backward_compatibility_aliases-nt.patch

to get only the category patches installed.

> > The challenge for the referee seems to be to sort out what has
> > been refereed, what needs careful inspection.

Yes, sorry; we discussed this orally, and did not report everything to:

http://sagetrac.org/sage_trac/wiki/CategoriesRoadMap

So feel free to bug me with any question! (I might not answer
instantly this week-end though).

Your mission, if you accept it, is to review the content of this patch:

http://combinat.sagemath.org/patches/file/tip/categories-categories-nt.patch

You may ignore for the moment everything about __mul__, and __add__ as
Craig and Robert will make a little change to those shortly.

> > Also, what version should I build against?
>
> sage-4.0.2 (which will be released today) -- if anything doesn't apply, ask
> Nic to rebase it.

For the moment, the patches apply on 4.0 and 4.0.1. I am compiling
4.0.2 now, and will rebase the patches on Monday at the latest.

Nicolas M. Thiery

unread,
Jun 22, 2009, 2:41:07 AM6/22/09
to drk...@gmail.com, sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear David, dear Sage(-Combinat) devs

On Sat, Jun 20, 2009 at 08:58:34AM -0700, Nicolas Thiéry wrote:
> For the moment, the patches apply on 4.0 and 4.0.1. I am compiling
> 4.0.2 now, and will rebase the patches on Monday at the latest.

Done.

For the first time in a long while, rebasing the sage-combinat queue
was trivial! Yippee!

Well, I did not run all tests to double check, but at least the patch
apply and don't break sage -br.

Nicolas M. Thiery

unread,
Jul 8, 2009, 1:06:20 AM7/8/09
to drk...@gmail.com, sage-...@googlegroups.com
Dear David Kohel,

Can I be of any help for the reviewing of the category patch? Do you
have a timeline for your progress on this?

Best,
Nicolas

Nicolas M. Thiery

unread,
Jul 8, 2009, 1:59:25 PM7/8/09
to David R. Kohel, sage-...@googlegroups.com, sage-comb...@googlegroups.com
Hi David (K),

On Wed, Jul 08, 2009 at 12:41:40PM +0200, David R. Kohel wrote:
> I think the sage-combinat build should help. During Sage Days 16 in
> Barcelona I tried naively applying the one patch you or William asked
> me to review but it failed to apply.

Hmm, did you receive the instructions I sent you for how to install
the patches? In short, just do:

sage -combinat install

assuming your .hgrc includes the following lines:

[extensions]
hgext.mq =

> On:
> http://sagetrac.org/sage_trac/wiki/CategoriesRoadMap
> Is the main issue #5891?

Yes. And for you categories-categories-nt.patch.

> Afterwards David Roe took the lead; so I need to know what he has
> done.

I am waiting for his feedback; but he is only working on
categories-framework-nt.patch, so this is independent. In fact, the
only interaction with the other reviewers about
categories-categories-nt.patch is about the special methods __add__
and __mul__ that Robert is supposed to work on. Just ignore them.

> Just to verify: David refers (still) to me not David Roe?

Yes. I updated this page with the last names to clear up the ambiguity.

> Are the patches now at 100% doctests? If I remember or understood
> correctly, think this is a point with which David Roe was helping
> out and this work should be incorporated.

I think categories-categories-nt.patch is up to speed (but I may have
missed some: please let me know!). In any cases this part was not
touched by David R.

> P.S. As a remark, although this doesn't seem to play a role in the
> improvements to the categories framework, I make a distinction
> between the class hierarchy and the (default) categories to which
> they belong. E.g. "Get nice category graph pictures!"

Definitely!

Best,

David Roe

unread,
Jul 8, 2009, 7:46:27 PM7/8/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
I've updated my review patches (categories-framework-ref-dr.patch and the small categories-tensorial_rename-dr.patch).  Unfortunately, I won't be able to work on this much more in the next month and a half.  categories-framework is quite close to getting a positive review; the following are the main things that need to be remedied first.

* 100% doctests.  I wrote some doctests, but not as many as I'd hoped.  This probably constitutes the major portion of the remaining reviewing work.

* Have some pickling tests, but make sure that it's comprehensive.

* The function Hom in sage.categories.homset could use some cleaning up, though it works currently.

* Find a better name for sage.categories.map.Map.category_for

* Delete sage.categories.morphism.SetMorphismPython, or give a reason it shouldn't be deleted.

Notes:

* construction is unneeded for categories (used by the coercion system for parents).  I commented out the definitions of construction

Discussion: we currently have CategoryObject._base as a C attribute because some elements want fast access to a "base."  Is CategoryObject the right place to put this?  Maybe we should generalize the examples of sage.rings.integer_mod.NativeIntStruct and sage.rings.padics.pow_computer.PowComputer_class?

Nicolas: Can the comment at the top of category.py "# Ugly temporary? workaround; see doc of UniqueRepresentation" describe why this hack is needed?

Discussion: what's the right inheritance structure for homsets?  Also, how should one specify that a category's homsets are enriched in another category?  Via a method like "enriched_in()" on the category?  By extra_super_categories() in a custom HomCategory?

* Currently ParentGens.__init__ does not call ParentWithBase.__init__.  This should presumably change at some point.

* I added a new weakref version of cachefunc, and source introspection for dynamic classes.  Someone should review these (along with the rest of my changes)

Nicolas: can you clarify the use of sage.categories.morphism.Morphism.register_as_coercion

I will be accessible on e-mail, but don't have time to work on this anytime soon.  Good luck!  I want to see this incorporated into Sage.
David

P.S. I don't think I have permission to post to sage-combinat-devel; Nicolas, do you want to forward this to that list?

Robert Bradshaw

unread,
Jul 9, 2009, 5:17:52 AM7/9/09
to sage-...@googlegroups.com
On Jul 8, 2009, at 4:46 PM, David Roe wrote:

> Discussion: we currently have CategoryObject._base as a C attribute
> because some elements want fast access to a "base." Is
> CategoryObject the right place to put this? Maybe we should
> generalize the examples of sage.rings.integer_mod.NativeIntStruct
> and sage.rings.padics.pow_computer.PowComputer_class?

I think it may be useful to have an extra object field for stuff like
NativeIntStruct and PowComputer_class. However, base is so common
that we might as well stick it there and make it easy to access.


>
>
> * Currently ParentGens.__init__ does not call
> ParentWithBase.__init__. This should presumably change at some point.

I believe both of those should simply go away when everything's moved
to the new coercion model.

- Robert

Nicolas M. Thiery

unread,
Jul 10, 2009, 4:09:58 PM7/10/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
On Wed, Jul 08, 2009 at 04:46:27PM -0700, David Roe wrote:
> I've updated my review patches (categories-framework-ref-dr.patch and the
> small categories-tensorial_rename-dr.patch).

I just reviewed your reviewer patch this morning. Wow, thanks for the
massive work!

> Unfortunately, I won't be able to work on this much more in the
> next month and a half. categories-framework is quite close to
> getting a positive review; the following are the main things that
> need to be remedied first.

I have a couple things that I need to discuss with you. Would you be
available at some point for an IRC chat? Today would be best (except
from 5 to midnight). This week-end should be possible.

> * 100% doctests. I wrote some doctests, but not as many as I'd hoped.

Well, far more than "some"!

> This probably constitutes the major portion of the remaining
> reviewing work.

Ok. I will work on that.

> * Have some pickling tests, but make sure that it's comprehensive.

Ok. Good occasion to add plenty of TestSuite(...).run().

> * The function Hom in sage.categories.homset could use some cleaning up,
> though it works currently.

Yeah. Morphims in general need a lot of work. So, let's postpone this.

> * Find a better name for sage.categories.map.Map.category_for

> * Delete sage.categories.morphism.SetMorphismPython, or give a reason it
> shouldn't be deleted.

Deleted.

> Notes:
>
> * construction is unneeded for categories (used by the coercion system for
> parents). I commented out the definitions of construction

From a general point of view, I find this very nice feature for the
user to know how a given object has been constructed (or can be
reconstructed). But yes, this is not urgently needed; let's postpone
this.

> Discussion: we currently have CategoryObject._base as a C attribute
> because some elements want fast access to a "base." Is CategoryObject the
> right place to put this? Maybe we should generalize the examples of
> sage.rings.integer_mod.NativeIntStruct and
> sage.rings.padics.pow_computer.PowComputer_class?
>
> Nicolas: Can the comment at the top of category.py "# Ugly temporary?
> workaround; see doc of UniqueRepresentation" describe why this hack is
> needed?

Thanks for pointing this out. It's indeed not needed anymore
(UniqueRepresentation works now better than it used to be). I just
removed it (and am running the tests).

> Discussion: what's the right inheritance structure for homsets? Also, how
> should one specify that a category's homsets are enriched in another
> category? Via a method like "enriched_in()" on the category? By
> extra_super_categories() in a custom HomCategory?

I added those comments to
http://sagetrac.org/sage_trac/wiki/CategoriesRoadMap. We really
should have a general brainstorm later about homsets. It might be
easier during some future Sage days.

> * I added a new weakref .version of cachefunc,

I'll extract a separate patch for this and review it.

> and source introspection for dynamic classes. Someone should
> review these (along with the rest of my changes)

I will make this into a reviewer's patch for the dynamic_class patch
#5991, and review it.

> Nicolas: can you clarify the use of
> sage.categories.morphism.Morphism.register_as_coercion

It's just an experiment toward expressive notations for constructing
new coercions. With it, you can just do:

- hom(domain, codomain, ...).register_as_coercion()

rather than:

- codomain.register_coercion(hom(domain, codomain, ...))

It's actually not yet used, but would improve the readability of the
sf patch.

Do you have suggestions for a better name?


> I will be accessible on e-mail, but don't have time to work on this
> anytime soon. Good luck! I want to see this incorporated into Sage.

Thanks again for all your work!

Cheers,
Nicolas

Nicolas M. Thiery

unread,
Jul 10, 2009, 7:34:30 PM7/10/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
> > and source introspection for dynamic classes. Someone should
> > review these (along with the rest of my changes)
>
> I will make this into a reviewer's patch for the dynamic_class patch
> #5991, and review it.

Done. Can you double check http://sagetrac.org/sage_trac/ticket/5991
and, if possible, give it a positive review (pending 5985)?

Cheers,

David Roe

unread,
Jul 11, 2009, 3:17:20 AM7/11/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Yep.  I don't have time tomorrow, but I can be on IRC Sunday afternoon.
David

Nicolas M. Thiery

unread,
Jul 27, 2009, 4:45:40 PM7/27/09
to David R. Kohel, sage-...@googlegroups.com, sage-comb...@googlegroups.com
Hi David (K),

How far are you with the review of the category patch?

I am with Florent and Franco at RISC, and will give a hard blow of
doctest tomorrow. We would like to avoid doing things where you may
already have done some.

Thanks for your quick reply!

Cheers,

William Stein

unread,
Jul 27, 2009, 5:13:54 PM7/27/09
to sage-comb...@googlegroups.com, David R. Kohel, sage-...@googlegroups.com
On Mon, Jul 27, 2009 at 1:45 PM, Nicolas M.
Thiery<Nicolas...@u-psud.fr> wrote:
>
>        Hi David (K),
>
> How far are you with the review of the category patch?
>
> I am with Florent and Franco at RISC, and will give a hard blow of
> doctest tomorrow. We would like to avoid doing things where you may
> already have done some.
>
> Thanks for your quick reply!

I'm guessing David Kohel hasn't done anything with reviewing
categories. I don't know if he was even able to get setup to do the
review. David Roe is super busy with mathcamp...

>
> Cheers,
>                                Nicolas
> --
> Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
> http://Nicolas.Thiery.name/
>
> >
>



Nicolas M. Thiery

unread,
Aug 1, 2009, 9:32:48 AM8/1/09
to David R. Kohel, sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear David, dear category fans,

We made some good progress on the review of the main category patch.
Most of the (hopf) algebra categories were reviewed by Florent Hivert,
and the semigroup/monoid ones by Franco Saliola. See the progress
report on:

http://sagetrac.org/sage_trac/wiki/CategoriesCategoriesReview

Most of the remaining categories are essentially empty, so the review
should be super quick. They also should be essentially 100% doctested
up to adding a TestSuite?(C).run() where needed. I'll try to do this
in the coming days, starting from the bottom up, but no promise on
this.

Since they are of general purpose and/or outside of our main topics,
we would rather have someone outside of our group review them. Please
tell us very shortly what your timeline could be for reviewing them,
and / or tell us whether we should be looking for another reviewer.

Thanks in advance!

Best regards,
Nicolas


For your convenience, the sage code with the sage-combinat patches
applied is (experimentally!) browsable from:

http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories

PS: I am currently in vacations in the south of France (Uzès, then
Aix-en-Provence on Thursday). If useful, we could possibly meet to
discuss all of this.

Nicolas M. Thiery

unread,
Aug 18, 2009, 5:22:07 PM8/18/09
to David R. Kohel, sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear Franco, dear category fans,

I just finished bringing AdditiveCommutativeSemigroups and friend
categories to 100% doctests. Would you have any chance to review them
in the coming days? Since they are very close from their
multiplicative counterparts, that should be a very quick job for
you.

Note that I made a small change in the Parent.summation vs
Element._add_ logic and similarly for product/_mul_, you may want to
double check the later.

I also brought examples/semigroups_cython to 100% doctest, in case you
can also spare a bit of time for it.

Thanks!

Cheers,
Nicolas

Nicolas M. Thiery

unread,
Aug 18, 2009, 6:09:45 PM8/18/09
to David R. Kohel, sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear David, dear category fans,

I just finished bringing all categories to 100% doctests, except the
following ones:

sets_cat
algebras_with_basis
examples/hopf_algebras_with_basis

See: http://sagetrac.org/sage_trac/wiki/CategoriesCategoriesReview

In particular, all the categories which are currently marked for you
to review are 100% doctested (and essentially empty).

Please tell us very shortly what your timeline could be for reviewing
them, and / or tell us whether we should be looking for another
reviewer.


Thanks in advance!

Best regards,
Nicolas

For your convenience, the sage code with the sage-combinat patches
applied is (experimentally!) browsable from:

http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories

PS: I am in Aix-en-Provence until next week-end. If useful, we could

Nicolas M. Thiery

unread,
Aug 19, 2009, 6:52:30 PM8/19/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear category fans,

David Kohel won't be available in the next two weeks for working on
the category review. Is there any volunteer for reviewing (some of
the) 40 categories listed under his name on:

http://sagetrac.org/sage_trac/wiki/CategoriesCategoriesReview

The files are all 100% doctested, and most of them are essentially
trivial. So the reviewing work is essentially about their mathematical
sanity.

For your convenience, the sage code with the sage-combinat patches
applied is (experimentally!) browsable from:

http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories

Alternatively, they can be installed with:

sage -combinat install

Thanks in advance!

Cheers,
Nicolas

javier

unread,
Aug 20, 2009, 5:17:34 AM8/20/09
to sage-devel
I would like to get more involved with Sage developing, and
"mathematical sanity check" looks like something I can certainly do
and a nice way to get started, so I will try to jump into this one.

Mind that I haven't been involved with Sage any further than the mail
lists so far, so any pointers will be appreciated.

Cheers
Javier



On Aug 19, 11:52 pm, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
> Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>http://Nicolas.Thiery.name/

Minh Nguyen

unread,
Aug 20, 2009, 5:39:36 AM8/20/09
to sage-...@googlegroups.com
Hi Javier,

On Thu, Aug 20, 2009 at 7:17 PM, javier<veng...@gmail.com> wrote:
>
> I would like to get more involved with Sage developing, and
> "mathematical sanity check" looks like something I can certainly do
> and a nice way to get started, so I will try to jump into this one.

Welcome aboard! At the moment, there is no official quality assurance
team with respect to code quality, but any help is appreciated.


> Mind that I haven't been involved with Sage any further than the mail
> lists so far, so any pointers will be appreciated.

You might find the Developers' Guide helpful:

http://www.sagemath.org/doc/developer/index.html

It covers topics like coding conventions, using Mercurial to manage
patches, and guidelines for things like reviewing other people's
patches. The sage-combinat team has written a tutorial on using
Mercurial for Sage development, so you might find that helpful:

http://wiki.sagemath.org/combinat/MercurialStepByStep

If you require more documentation about Mercurial, the official
website of Mercurial contains heaps of documentation ranging from
short tutorials to full-blown books and of course the standard
Mercurial documentation:

http://mercurial.selenic.com/wiki/

At Sage Days 16 in Barcelona, Spain, Martin Albrecht gave a talk on
how to get started with Sage development. You can find his talk slides
at the talks wiki page:

http://wiki.sagemath.org/days16

Sage development isn't just about writing computer code in some
programming language. You can also help out with translating the Sage
tutorial (or some other documentation) to another (human) language.
Presently, there are translations of the tutorial in French and
Spanish, which you can find here:

http://www.sagemath.org/help.html

Nathann Cohen has volunteered to help maintain a French mirror of Sage
and do more translation work:

http://www.sagemath.fr

I have recorded some of my experiences in Sage development in the
following blog post:

http://mvngu.wordpress.com/2009/07/02/getting-started-with-developing-sage/

Yes, I know... Shame on me for promoting myself :-)

--
Regards
Minh Van Nguyen

Nicolas M. Thiery

unread,
Aug 22, 2009, 7:32:46 PM8/22/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear category fans,

For information: in principle, the new category code is now 100% doctested!

Nicolas M. Thiery

unread,
Aug 22, 2009, 7:56:34 PM8/22/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear javier,

On Thu, Aug 20, 2009 at 02:17:34AM -0700, javier wrote:
> I would like to get more involved with Sage developing, and
> "mathematical sanity check" looks like something I can certainly do
> and a nice way to get started, so I will try to jump into this one.

Great, thanks!

> Mind that I haven't been involved with Sage any further than the mail
> lists so far, so any pointers will be appreciated.

Just to complete the Minh's answer (thanks Minh!) for this particular mission:

You probably want to start by browsing through:

http://combinat.sagemath.org/doc/reference/sage/categories/primer.html

to get the general picture about categories.

For the rest, this review is a bit specific: you can skip the
technical part of the review (checking that the patch applies
smoothly, pass tests, ...); this part will be done at once for all the
category code once the mathematical review will be finished.

So you can focus on looking at the code, doc, and tests in the files
mentioned in:

http://trac.sagemath.org/sage_trac/wiki/CategoriesCategoriesReview

possibly simply by browsing:

http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories)

and make sure they makes sense.

You may want to actually install the patch with sage -combinat install
to play around with it and/or create a reviewer patch.

Feel free to ask for further help!

Best regards,
Nicolas
--
Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

javier

unread,
Aug 23, 2009, 5:48:15 AM8/23/09
to sage-devel
On Aug 23, 12:56 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
> For the rest, this review is a bit specific: you can skip the
> technical part of the review (checking that the patch applies
> smoothly, pass tests, ...); this part will be done at once for all the
> category code once the mathematical review will be finished.

So, just to be clear, I don't need to get a trac account or learn how
to use mercurial right now, right?

> possibly simply by browsing:
>
>        http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories)
>
> and make sure they makes sense.

About this, I clicked on a file at random (algebras.py) to have an
idea on a general shape of the stuff. I was very startled to see a
method called direct sum. The category of algebras (over a fixed based
field) does not have a "direct sum" (or coproduct), what is
constructed there is actually the direct product. Sure thing, as in
the "big category" (vector spaces over the base field) there is a
direct sum, which coincides with the direct product, but it doesn't
descend to the category of algebras: the map A ---> A\oplus B in
vector spaces is defined by a |---> (a,0), which this is not a
morphism of algebras.

I know that most physicists and some mathematicians abuse the term
"direct sum" to refer to the direct product, but since this whole
thing is called "Categories" I expect a "Category theory" level of
precision.

Is this the kind of stuff you refer to with "checking mathematical
sanity", or am I going needlessly abstract here?


> You may want to actually install the patch with sage -combinat install
> to play around with it and/or create a reviewer patch.

I tried, but got a "No username found" error that resulted in aborting
the process. I guess I do need that trac account after all?

Cheers
Javier

John Cremona

unread,
Aug 23, 2009, 7:37:11 AM8/23/09
to sage-...@googlegroups.com
2009/8/23 Nicolas M. Thiery <Nicolas...@u-psud.fr>:

> So you can focus on looking at the code, doc, and tests in the files
> mentioned in:
>
>        http://trac.sagemath.org/sage_trac/wiki/CategoriesCategoriesReview
>
> possibly simply by browsing:
>
>        http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories)
>
> and make sure they makes sense.
>

I don't really know how this type of reviewing differs from normal
Sage reviewing of patches attached to trac tickets. But anyway, I
looked at one file, finite_fields.py, and the method _call_() in there
looks wrong -- it raises an error whatever the input, while the
dicstring suggests that it is supposed to try using __call__() and
only change the error message if that does not work.

If I have completely misunderstood what is going on, then I will carry
on ignoring the category activity until it is finished, at which point
I'm sure I will use it all the time!

John

Nicolas M. Thiery

unread,
Aug 24, 2009, 3:39:03 AM8/24/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Hi John!

On Sun, Aug 23, 2009 at 12:37:11PM +0100, John Cremona wrote:
> 2009/8/23 Nicolas M. Thiery <Nicolas...@u-psud.fr>:
> > So you can focus on looking at the code, doc, and tests in the files
> > mentioned in:
> >
> >        http://trac.sagemath.org/sage_trac/wiki/CategoriesCategoriesReview
> >
> > possibly simply by browsing:
> >
> >        http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories)
> >
> > and make sure they makes sense.
>
> I don't really know how this type of reviewing differs from normal
> Sage reviewing of patches attached to trac tickets.

Just that you don't need to worry about the technical side (checking
that the patch applies, pass test, ...). Also setting a positive
review will be on the wiki page, file by file, rather than on the trac
ticket. Finally, there is essentially no datastructure/algorithm issue
in the current code (that will change!)

> But anyway, I looked at one file, finite_fields.py, and the method
> _call_() in there looks wrong -- it raises an error whatever the
> input, while the dicstring suggests that it is supposed to try using
> __call__() and only change the error message if that does not work.

It's the converse: __call__ tries to do generic stuff (like C(P)
returns P if P is readilly a parent in the category C), and if that
does not work calls _call_ (similar to what happens for __mul__ /
_mul). I actually haven't changed that part; that's how it is in the
original category framework.

See the doc of _call_ / __call__ in Category (sage.category.category.py).

Suggestions to improve the doctests to clarify this are welcome!

> If I have completely misunderstood what is going on, then I will
> carry on ignoring the category activity until it is finished,

Please don't!

> at which point I'm sure I will use it all the time!

Which is why I want as much "early" feedback from you as possible :-)

Cheers,

Tim Daly

unread,
Aug 24, 2009, 4:04:28 AM8/24/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com, Nicolas...@u-psud.fr, daly, axiom-developer@nongnu.org >> Axiom-Developer
Nicolas

Do you have the inheritance graph of the categories?

Tim Daly

Nicolas M. Thiery

unread,
Aug 24, 2009, 7:37:33 AM8/24/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
On Sun, Aug 23, 2009 at 02:48:15AM -0700, javier wrote:
> On Aug 23, 12:56 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> wrote:
> > For the rest, this review is a bit specific: you can skip the
> > technical part of the review (checking that the patch applies
> > smoothly, pass tests, ...); this part will be done at once for all the
> > category code once the mathematical review will be finished.
>
> So, just to be clear, I don't need to get a trac account or learn how
> to use mercurial right now, right?

Nope.

> I tried, but got a "No username found" error that resulted in aborting
> the process. I guess I do need that trac account after all?

This is just a warning. Ah but you are using sage 4.1.1, right? Oops,
sorry, I should have though about this and warned you. The
sage-combinat patches have not yet be rebased for 4.1.1. Actually they
have, but only on my machine, and I still need to double check a
couple things before pushing. Please try again tonight or tomorrow
night.

Cheers,

Nicolas M. Thiery

unread,
Aug 24, 2009, 8:39:15 AM8/24/09
to Tim Daly, sage-...@googlegroups.com, sage-comb...@googlegroups.com
Hi Tim!

On Mon, Aug 24, 2009 at 04:04:28AM -0400, Tim Daly wrote:
> Do you have the inheritance graph of the categories?

Almost :-) The category primer currently suggests:

sage: GradedHopfAlgebrasWithBasis(QQ).category_graph().plot()

which gives a reasonable approximation. However some categories are
missing, and the layout of the plot is ugly (we definitely need a good
graph layout engine for acyclic graphs; that's on its way using
graphviz dot2tex, but not quite ready).

Having such a graph have been on my todo list from the beginning.
I'll try to hack something shortly and post a pdf.

Nicolas M. Thiery

unread,
Aug 24, 2009, 8:33:38 AM8/24/09
to sage-...@googlegroups.com
On Sun, Aug 23, 2009 at 02:48:15AM -0700, javier wrote:
> > possibly simply by browsing:
> >
> >        http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories)
> >
> > and make sure they makes sense.
>
> About this, I clicked on a file at random (algebras.py) to have an
> idea on a general shape of the stuff. I was very startled to see a
> method called direct sum. The category of algebras (over a fixed based
> field) does not have a "direct sum" (or coproduct), what is
> constructed there is actually the direct product. Sure thing, as in
> the "big category" (vector spaces over the base field) there is a
> direct sum, which coincides with the direct product, but it doesn't
> descend to the category of algebras: the map A ---> A\oplus B in
> vector spaces is defined by a |---> (a,0), which this is not a
> morphism of algebras.
>
> I know that most physicists and some mathematicians abuse the term
> "direct sum" to refer to the direct product, but since this whole
> thing is called "Categories" I expect a "Category theory" level of
> precision.
>
> Is this the kind of stuff you refer to with "checking mathematical
> sanity", or am I going needlessly abstract here?

Yes, thanks much for your feedback!

Having a "Category theory" level of precision is definitely an aim of
the category framework (but practicality is also one). Many aspects
are not up to speed yet to this respect (in particular around
homsets). The category framework could (and will) definitely use
several more iterations, if at all possible from developers with
various areas of expertise.

Since we are pretty late in this second iteration on Sage categories,
and since this sounds like a relatively minor issue, I would vote for
debating it and writing down explicitly in the documentation the
current abuses. However, unless a trivial fix emerges, I would
postpone the issue for a later iteration. This to avoid delaying
further this iteration and also to limit the risks of over-engineering
(we speak of usine à gaz in French). The right design will have better
chances to emerge once practical expertise will have been gained by
the Sage community in using the category framework.

Now to the debate:

- The problem with the map a -> (a,0) is only that 1_A is mapped to
(1_A,0) which is not 1_{A\oplusB} = (1_A,1_B), right?

Otherwise said, the category of NonUnitalAlgebras (which is not yet
implemented in Sage) indeed has a direct sum?

- I am in the train right now, without appropriate references. For,
say, monoids (additive, or multiplicative), how should the
operation of taking cartesian products be called?

Cheers,

John H Palmieri

unread,
Aug 24, 2009, 4:24:36 PM8/24/09
to sage-devel
On Aug 24, 5:33 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
>  - The problem with the map a -> (a,0) is only that 1_A is mapped to
>    (1_A,0) which is not 1_{A\oplusB} = (1_A,1_B), right?
>
>    Otherwise said, the category of NonUnitalAlgebras (which is not yet
>    implemented in Sage) indeed has a direct sum?

I don't think so, but I could be wrong. There are maps of nonunital
algebras from each of A and B to A \oplus B, but I don't think A
\oplus B has the correct universal property: given ring maps f:A --> C
and g: B --> C, you want a map

h: A \oplus B --> C

compatible with f, g, and the inclusions of A, B into A \oplus B.
Since (a,b) = (a,0) + (0,b), I think the only way to define h is as h
(a,b) = f(a) + g(b). But this isn't compatible with the product
structure: in general,

h((a1,b1) (a2, b2)) != h(a1,b1) h(a2,b2).

Either that, or I'm being completely silly (or cocompletely silly,
since we're talking about coproducts).

Regards,
John

javier

unread,
Aug 26, 2009, 3:44:52 AM8/26/09
to sage-devel
Sorry for the late replies, was on a conference trip.

On Aug 24, 1:33 pm, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
>  - The problem with the map a -> (a,0) is only that 1_A is mapped to
>    (1_A,0) which is not 1_{A\oplusB} = (1_A,1_B), right?

This is an "easy to spot" problem. The deep underlying problem is the
universal property.

>    Otherwise said, the category of NonUnitalAlgebras (which is not yet
>    implemented in Sage) indeed has adirectsum?

No, as John points the problem is with the universal property. The
"filler map" required by such property always exists (and it is
unique) at the level of the underlying vector spaces, but there is no
way to guarantee that it is a morphism of algebras (in general, it
isn't).

Back to terminology, what it is implemented is a categorical product,
which in this category (algebras) coincides with the vector spaces
direct product. If we want to implement a categorical coproduct, then
we are aiming for the free product, not any "direct sum".

>  - I am in the train right now, without appropriate references. For,
>    say, monoids (additive, or multiplicative), how should the
>    operation of taking cartesian products be called?

It is also called direct product, same as in groups (where we have
direct and semi-direct products).

Cheers,
Javier

PS: I am cross-posting this to sage-combinat-devel. Maybe we should
move the discussion there?

Nicolas M. Thiery

unread,
Aug 26, 2009, 9:21:47 AM8/26/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear and Javier, dear John,

On Wed, Aug 26, 2009 at 12:44:52AM -0700, javier wrote:
> On Aug 24, 1:33 pm, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> wrote:
> >  - The problem with the map a -> (a,0) is only that 1_A is mapped to
> >    (1_A,0) which is not 1_{A\oplusB} = (1_A,1_B), right?
>
> This is an "easy to spot" problem. The deep underlying problem is the
> universal property.
>
> >    Otherwise said, the category of NonUnitalAlgebras (which is not yet
> >    implemented in Sage) indeed has adirectsum?
>
> No, as John points the problem is with the universal property. The
> "filler map" required by such property always exists (and it is
> unique) at the level of the underlying vector spaces, but there is no
> way to guarantee that it is a morphism of algebras (in general, it
> isn't).
>
> Back to terminology, what it is implemented is a categorical product,
> which in this category (algebras) coincides with the vector spaces
> direct product. If we want to implement a categorical coproduct, then
> we are aiming for the free product, not any "direct sum".
>
> >  - I am in the train right now, without appropriate references. For,
> >    say, monoids (additive, or multiplicative), how should the
> >    operation of taking cartesian products be called?
>
> It is also called direct product, same as in groups (where we have
> direct and semi-direct products).

Thanks for the feedback, http://en.wikipedia.org/wiki/Direct_product
finished to clear my confusion. I was being co-silly :-)

So in the long run, we definitely need both the direct sum and the
direct product functorial constructions, with appropriate
"inheritance" to share whatever is valid for both direct products and
direct sums. For the moment, I'll just leave a note about this in the
code (for the moment, this feature is essentially used nowhere).

A little question: if V and W are two vector spaces which turn out to
be also in stronger categories, some with direct sums, and some
without, what should the following do:

sage: direct_sum(V, W)

One 100% safe option is to raise an error.

Another would be to return the direct sum (as vector spaces) of V and
W, which is also a direct product (that would be another story if the
sum was infinite), and to endow it with whatever operations from the
other categories applying either to direct sums or to direct products.

This second option, if at all safe, sounds more friendly for non
category experts.

> PS: I am cross-posting this to sage-combinat-devel. Maybe we should
> move the discussion there?

Crosspost is good, since we need feedback from everyone.

John H Palmieri

unread,
Aug 26, 2009, 10:42:18 AM8/26/09
to sage-combinat-devel, sage-...@googlegroups.com
On Aug 26, 6:21 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:

>         Dear  and Javier, dear John,

[snip]

> So in the long run, we definitely need both the direct sum and the
> direct product functorial constructions, with appropriate
> "inheritance" to share whatever is valid for both direct products and
> direct sums. For the moment, I'll just leave a note about this in the
> code (for the moment, this feature is essentially used nowhere).
>
> A little question: if V and W are two vector spaces which turn out to
> be also in stronger categories, some with direct sums, and some
> without, what should the following do:
>
>         sage: direct_sum(V, W)

Could there be an optional argument:

sage: direct_sum(V, W, cat)

If cat is not present, find the "strongest" category which contains
both V and W, and compute the direct sum there, raising an error if it
doesn't exist. (Or just raise an error? Or raise an error, saying
what this strongest category is, and suggesting computing the direct
sum there? Maybe I like this last approach the best.) If cat is
present, check that cat contains both V and W, and then compute the
direct sum there.

> One 100% safe option is to raise an error.
>
> Another would be to return the direct sum (as vector spaces) of V and
> W, which is also a direct product (that would be another story if the
> sum was infinite), and to endow it with whatever operations from the
> other categories applying either to direct sums or to direct products.

This approach doesn't make sense to me: V and W can also be viewed as
sets, but their coproduct as sets is not the same as their coproduct
as vector spaces. Why choose one over the other? And what if there
is a third category (like commutative k-algebras) in which the
coproduct is again different (like the tensor product)?

John

Jason Grout

unread,
Aug 26, 2009, 12:30:32 PM8/26/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
John H Palmieri wrote:
> On Aug 26, 6:21 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> wrote:
>> Dear and Javier, dear John,
>
> [snip]
>
>> So in the long run, we definitely need both the direct sum and the
>> direct product functorial constructions, with appropriate
>> "inheritance" to share whatever is valid for both direct products and
>> direct sums. For the moment, I'll just leave a note about this in the
>> code (for the moment, this feature is essentially used nowhere).
>>
>> A little question: if V and W are two vector spaces which turn out to
>> be also in stronger categories, some with direct sums, and some
>> without, what should the following do:
>>
>> sage: direct_sum(V, W)
>
> Could there be an optional argument:
>
> sage: direct_sum(V, W, cat)
>
> If cat is not present, find the "strongest" category which contains
> both V and W, and compute the direct sum there, raising an error if it
> doesn't exist. (Or just raise an error? Or raise an error, saying
> what this strongest category is, and suggesting computing the direct
> sum there? Maybe I like this last approach the best.) If cat is
> present, check that cat contains both V and W, and then compute the
> direct sum there.


Isn't this sort of what the coercion system is all about? If you can't
do a direct sum of V and W, try coercing them into a category that can
do a direct sum? If you want to specifically compute the direct sum in
a particular category, then do an explicit cast yourself, like
direct_sum(cat(V), cat(W)), or maybe cat.direct_sum(V,W) or something.

Maybe there is some function that gives back the categories V belongs to
and the categories W belongs to with some sort of hierarchy, so that you
can ask what the strongest category is. Maybe there is some way to
filter a set of categories by existence of operations. So you could do
something like:

category_graph=V.categories().subgraph(W.categories())
category_graph.subgraph(lambda cat: cat.exists('direct_sum'))
strongest_category=category_graph.root()

Forgive me if I don't make any sense :).

Jason

John H Palmieri

unread,
Aug 26, 2009, 2:52:37 PM8/26/09
to sage-devel
On Aug 26, 9:30 am, Jason Grout <jason-s...@creativetrax.com> wrote:
> John H Palmieri wrote:
> > On Aug 26, 6:21 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> > wrote:
> >>         Dear  and Javier, dear John,

> >> A little question: if V and W are two vector spaces which turn out to
> >> be also in stronger categories, some with direct sums, and some
> >> without, what should the following do:
>
> >>         sage: direct_sum(V, W)
>
> > Could there be an optional argument:
>
> >   sage: direct_sum(V, W, cat)
>
> > If cat is not present, find the "strongest" category which contains
> > both V and W, and compute the direct sum there, raising an error if it
> > doesn't exist.  (Or just raise an error?  Or raise an error, saying
> > what this strongest category is, and suggesting computing the direct
> > sum there?  Maybe I like this last approach the best.)  If cat is
> > present, check that cat contains both V and W, and then compute the
> > direct sum there.
>
> Isn't this sort of what the coercion system is all about?  If you can't
> do a direct sum of V and W, try coercing them into a category that can
> do a direct sum?  If you want to specifically compute the direct sum in
> a particular category, then do an explicit cast yourself, like
> direct_sum(cat(V), cat(W)), or maybe cat.direct_sum(V,W) or something.

I completely agree with your last point: direct_sum(cat(V), cat(W)) or
cat.direct_sum... is the way to go for explicitly specifying the
category. This is better than passing an optional argument to
direct_sum.

I'm leaning more strongly toward the point of view that raising an
error is the right approach when the direct sum doesn't exist. If V
and W are objects in the same category, and that category doesn't have
direct sums, then direct_sum(V,W) should raise an error. This should
even happen, I think, if there is a forgetful functor to a category in
which the direct sum is defined. As noted earlier, if V and W are k-
algebras, then they don't have a direct sum in the category of k-
algebras. If they happen to be commutative, then they do have a
direct sum in the category of commutative k-algebras: V tensor_k W.
They also have direct sums in the category of k-vector spaces (V x W)
and in the category of sets (V disjoint union W). All of these are
different, so which should you choose? It seems safest to raise an
error, perhaps with the suggestion that the direct sum might exist in
some other category, like the category of k-vector spaces, and so you
might execute direct_sum(VectorSpaces(k)(V), VectorSpaces(k)(W)) (or
whatever the command is) instead.

I suppose there could be another function, "direct_sum_force" or
something, which finds a category containing V and W in which the
direct sum exists. But I think that if category(V) == category(W) is
True, then

sage: category(V) == category(direct_sum(V, W))

should return True, also, since, as Nicolas says, 'Having a "Category
theory" level of precision is definitely an aim of the category
framework'.

John

Nicolas M. Thiery

unread,
Aug 28, 2009, 8:38:14 AM8/28/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear Jason, Javier, John,

Thanks all for your feedback and clarification!

Yes. Yet it also has to remain practical.

Let me first point out that there are about one hundred categories. So
quite often a user don't really know, in fact don't want to know, in
which category a parent is. For example many will construct and use:

sage: GroupAlgebra(QQ, SymmetricGroup(8))

without caring about the fact that it actually is a Hopf or even a Kac
algebra. At the same time, the user don't want to erase this
information (by applying a forgetful functor), because it can be used
internally to speed up certain computations.


That being said, the whole discussion originates from a confusion (I
caused) between two desirable feature sets::

- On the one hand, categorical operations like direct sum, as
described above.

- On the other hand, set constructions (like the disjoint union or
cartesian product of two sets, the direct sum or tensor product of
two vector spaces, ...), where the result is endowed with whatever
structure it can have, depending on the categories of the operands.
(or some substructure of that, if a category is specified).

As it has been pointed out, a categorical operation, like direct_sum,
can correspond to different constructions, depending on the category
at hand (a disjoint union, a (vector space) direct sum, a tensor product).


My impression is that the categorical operations will seldom be
used. But I may be wrong, so room should be left for them. On the
other hand what *will* be useful (and readily is) to many of us are
constructions. That's what the current (possibly misnamed) direct sum
and tensor product thingies are all about.

What remains to be done is to find a good set of names to distinguish
between the two feature sets.

- The ambiguity is mostly for direct sum, right?

- Are there (useful) cases where the direct product of a subcategory
of Sets does not coincide with the cartesian product on the
underlying sets?

- There could be some ambiguity for tensor product which is often
used as an alias for cartesian product for graphs, crystals, ...
But those are not subcategories of VectorSpaces/Modules. So it
would not be an issue to have a similar alias in Sage.

Other thoughts?

But all of this discussion should not slow down the most important
thing: the review of the current code! Help!

John H Palmieri

unread,
Aug 28, 2009, 12:02:02 PM8/28/09
to sage-devel
On Aug 28, 5:38 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:

> What remains to be done is to find a good set of names to distinguish
> between the two feature sets.
>
> - The ambiguity is mostly for direct sum, right?

I think so.

> - Are there (useful) cases where the direct product of a subcategory
> of Sets does not coincide with the cartesian product on the
> underlying sets?

Not that I can think of right now.

> - There could be some ambiguity for tensor product which is often
> used as an alias for cartesian product for graphs, crystals, ...
> But those are not subcategories of VectorSpaces/Modules. So it
> would not be an issue to have a similar alias in Sage.

That sounds okay to me.

I think that "cartesian_product" is a good, unambiguous (I think) name
for the set construction. "direct_sum" and "direct_product" are maybe
okay, while definitely "coproduct" and possibly "product" should be
reserved for the category-level operation.

John

javier

unread,
Aug 28, 2009, 2:08:12 PM8/28/09
to sage-devel, sage-comb...@googlegroups.com
On Aug 28, 5:02 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
> >  - Are there (useful) cases where the direct product of a subcategory
> >    of Sets does not coincide with the cartesian product on the
> >    underlying sets?
>
> Not that I can think of right now.

The category of schemes. Not really a subcategory of sets, but even
forgetting the algebraic part, the point set of a product scheme is
not the cartesian product of the corresponding point sets.

> >  - There could be some ambiguity for tensor product which is often
> >    used as an alias for cartesian product for graphs, crystals, ...
> >    But those are not subcategories of VectorSpaces/Modules. So it
> >    would not be an issue to have a similar alias in Sage.
>
> That sounds okay to me.

The ambiguity here comes because the cartesian product for graphs, etc
gives these categories a monoidal structure, as does the tensor
product in the category of vector spaces. This "categorical tensor
product" does not need to be either a categorical product nor a
coproduct (but sometimes it is).

> I think that "cartesian_product" is a good, unambiguous (I think) name
> for the set construction. "direct_sum" and "direct_product" are maybe
> okay, while definitely "coproduct" and possibly "product" should be
> reserved for the category-level operation.

+1
I would say that each category has its own operations defined with the
usual name, eg cartesian_product for sets or vector spaces,
direct_product for groups, monoids or algebras, and so on, the
"category level operations" should be consistently named (product,
coproduct, limit, colimit, ...) and mapped to whatever the
corresponding construction is in each particular category.

Back to the original problem, "direct_sum" should be defined for
vector spaces, but not for algebras, or if defined for algebras
through coercion, then return a vector space, and not an algebra.

Cheers
Javier

PS: Yes, yes, I'll do the reviews. Busy right now finishing a paper
with deadline (sunday). Will focus on this as soon as I am done.

Nicolas M. Thiery

unread,
Sep 16, 2009, 8:49:30 AM9/16/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear category fans,

Thanks to Florent (and previous work by Anne, Jason, Franco, ...) all
the sage-combinat related categories have a positive review. There
remains just the mostly trivial categories listed below which would be
best reviewed by some non-sage-combinat person (standard categories),
or specialist (number fields, schemes, ...).

Please help!


Other than that:

Craig: what's your time line for finalizing #5985, as a patch for python?

Robert: What's your time line for:
- the review of categories-fixsagelib-nt.patch
- finalizing #5597 [with patch, needs work] rename coercion action methods
- finalizing #5598 [with patch, needs work] (allow post-creation (pre-use) declaration of coercions)
Does the later really depend on the former?

Robert: Florent did review the category+cython proof of concept
example of semigroup. Could you still have a glance at it?

David Roe: what's your time line for the review of
categories-numberfield_homset-nt.patch?


Craig, Robert, Carl: what's the status for #5986. Remember that I am
not convinced that the alternative metaclass approach (using #6121)
will be practical. So if you insist going this way, you have to
implement it, or at the very least to provide me with a proof of
concept patch covering all the use cases.

Cheers,
Nicolas

------------------------------------------------------------------------------
References:

http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap
http://trac.sagemath.org/sage_trac/wiki/CategoriesCategoriesReview


all (100% doctest)
basic (100% doctest)

algebra_ideals (100% doctest)
algebra_modules (100% doctest)
bimodules (100% doctest)
commutative_algebra_ideals (100% doctest)
commutative_algebras (100% doctest)
commutative_ring_ideals (100% doctest)
commutative_rings (100% doctest)
division_rings (100% doctest)
entire_rings (100% doctest)
euclidean_domains (100% doctest)
fields (100% doctest)
finite_fields (100% doctest)
gcd_domains (100% doctest)
hecke_modules (100% doctest)
integral_domains (100% doctest)
left_modules (100% doctest)
matrix_algebras (100% doctest)
modular_abelian_varieties (100% doctest)
modules (100% doctest)
monoid_algebras (100% doctest)
number_fields (100% doctest)
objects (100% doctest)
ordered_monoids (100% doctest)
ordered_sets (100% doctest)
pointed_sets (100% doctest)
principal_ideal_domains (100% doctest)
quotient_fields (100% doctest)
right_modules (100% doctest)
ring_ideals (100% doctest)
rings (100% doctest)
rngs (100% doctest)
schemes (100% doctest)
sets_with_partial_maps (100% doctest)
unique_factorization_domains (100% doctest)
vector_space (100% doctest)

Nicolas M. Thiery

unread,
Oct 8, 2009, 6:04:18 PM10/8/09
to Tim Daly, sage-...@googlegroups.com, sage-comb...@googlegroups.com
Hi Tim!

On Mon, Aug 24, 2009 at 02:39:15PM +0200, Nicolas Thiéry wrote:
> On Mon, Aug 24, 2009 at 04:04:28AM -0400, Tim Daly wrote:
> > Do you have the inheritance graph of the categories?
>
> Almost :-) The category primer currently suggests:
>
> sage: GradedHopfAlgebrasWithBasis(QQ).category_graph().plot()
>
> which gives a reasonable approximation. However some categories are
> missing, and the layout of the plot is ugly (we definitely need a good
> graph layout engine for acyclic graphs; that's on its way using
> graphviz dot2tex, but not quite ready).
>
> Having such a graph have been on my todo list from the beginning.
> I'll try to hack something shortly and post a pdf.

I finally got there!

With Sage 4.1.1, all sage-combinat patches applied, graphviz
installed, and the experimental dot2tex.spkg (pfff) one can now do:

sage: G = sage.categories.category.category_graph().reverse()
sage: G.set_latex_options(format="dot2tex")
sage: view(G, tightpage = True, pdflatex=True)

Which produces the following:

http://sagetrac.org/sage_trac/raw-attachment/wiki/CategoriesRoadMap/sage-category-graph.pdf

Nicolas M. Thiery

unread,
Oct 8, 2009, 6:07:02 PM10/8/09
to Tim Daly, sage-comb...@googlegroups.com, sage-...@googlegroups.com
On Fri, Oct 09, 2009 at 12:04:18AM +0200, Nicolas Thiéry wrote:
> With Sage 4.1.1, all sage-combinat patches applied, graphviz
> installed, and the experimental dot2tex.spkg (pfff) one can now do:
>
> sage: G = sage.categories.category.category_graph().reverse()
> sage: G.set_latex_options(format="dot2tex")
> sage: view(G, tightpage = True, pdflatex=True)
>
> Which produces the following:
>
> http://sagetrac.org/sage_trac/raw-attachment/wiki/CategoriesRoadMap/sage-category-graph.pdf

I forgot to mention: for parametrized categories, the graph includes
just a typical instance of the category (like Modules(QQ),
Algebras(QQ), ...)

Cheers,

Robert Bradshaw

unread,
Oct 9, 2009, 3:25:54 AM10/9/09
to sage-...@googlegroups.com
On Sep 16, 2009, at 5:49 AM, Nicolas M. Thiery wrote:

>
> Dear category fans,
>
> Thanks to Florent (and previous work by Anne, Jason, Franco, ...) all
> the sage-combinat related categories have a positive review. There
> remains just the mostly trivial categories listed below which would be
> best reviewed by some non-sage-combinat person (standard categories),
> or specialist (number fields, schemes, ...).
>
> Please help!
>
>
> Other than that:
>
> Craig: what's your time line for finalizing #5985, as a patch for
> python?
>
> Robert: What's your time line for:
> - the review of categories-fixsagelib-nt.patch
> - finalizing #5597 [with patch, needs work] rename coercion action
> methods

Rebased, has doctests, needs review.

> - finalizing #5598 [with patch, needs work] (allow post-creation
> (pre-use) declaration of coercions)
> Does the later really depend on the former?

No, I don't think there's a dependancy. Lots of doctest failures, but
I bet they're all due to the same bug or two. I'll get to it within a
week.

> Robert: Florent did review the category+cython proof of concept
> example of semigroup. Could you still have a glance at it?

Sure, link?

> David Roe: what's your time line for the review of
> categories-numberfield_homset-nt.patch?
>
>
> Craig, Robert, Carl: what's the status for #5986. Remember that I am
> not convinced that the alternative metaclass approach (using #6121)
> will be practical. So if you insist going this way, you have to
> implement it, or at the very least to provide me with a proof of
> concept patch covering all the use cases.

We're pretty sure it can be done--proof of concept in the works. We'd
really like to get this pickling thing out of the way without adding
ugliness that will never go upstream (and I've always regretting
letting cruft get in as it seems to never actually get cleaned up
until it really bites and is a mess.)

- Robert

P.S. Cool category graph.

Nicolas M. Thiery

unread,
Oct 9, 2009, 11:46:49 AM10/9/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
On Fri, Oct 09, 2009 at 12:25:54AM -0700, Robert Bradshaw wrote:
> > Robert: What's your time line for:
> > - the review of categories-fixsagelib-nt.patch
> > - finalizing #5597 [with patch, needs work] rename coercion action
> > methods
>
> Rebased, has doctests, needs review.

Yep. Will review very soon, unless someone beats me to it! (last week
has been loaded with teaching)

> > - finalizing #5598 [with patch, needs work] (allow post-creation
> > (pre-use) declaration of coercions)
> > Does the later really depend on the former?

> No, I don't think there's a dependancy. Lots of doctest failures,
> but I bet they're all due to the same bug or two. I'll get to it
> within a week.

Great.

> > Robert: Florent did review the category+cython proof of concept
> > example of semigroup. Could you still have a glance at it?
>
> Sure, link?

http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap

See sage.categories.examples.semigroups_cython with the category patches applied:

http://combinat.sagemath.org/hgwebdir.cgi/code/file/tip/sage/categories/examples/semigroups_cython.pyx

> > Craig, Robert, Carl: what's the status for #5986. Remember that I am
> > not convinced that the alternative metaclass approach (using #6121)
> > will be practical. So if you insist going this way, you have to
> > implement it, or at the very least to provide me with a proof of
> > concept patch covering all the use cases.

> We're pretty sure it can be done--proof of concept in the
> works. We'd really like to get this pickling thing out of the way
> without adding ugliness that will never go upstream (and I've always
> regretting letting cruft get in as it seems to never actually get
> cleaned up until it really bites and is a mess.)

As I said on sage-combinat-devel, I am now convinced by your
alternative workaround which is slick and well localized.

> P.S. Cool category graph

:-)

Cheers,

Nicolas M. Thiery

unread,
Oct 13, 2009, 8:59:39 AM10/13/09
to sage-...@googlegroups.com, sage-comb...@googlegroups.com, ko...@iml.univ-mrs.fr
Dear David, dear Javier, dear category fans,

Yippee! the technical patches required by the category code are making
their way into Sage, maybe even in 4.1.2. Then not much remains to be
done, so I am now dreaming of getting the full thing in 4.1.3 (or
whatever the next Sage version will be)!

For this, I need you! I have split the remaining categories to be
reviewed between both of you: essentially the trivial new ones to
Javier, and the larger preexisting ones to David. But anyone else,
please feel free to hop in!

http://trac.sagemath.org/sage_trac/wiki/CategoriesCategoriesReview

It would be great if we could at least get rid of all the trivial ones
very shortly.

Note: I have just updated the category patches to include some of your
previous comments. In particular, I finally did the renaming
direct_sum -> cartesian_product as we had discussed. All test pass
with 4.1.1. I am now in the process of rebasing for 4.1.2.

You can `sage -combinat update`, or just browse the code directly from: