32 views

Skip to first unread message

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

> 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

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.

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.

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

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,

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?

* 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?

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

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'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

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.

> > 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,

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

David

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,

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
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!

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/

>

> >

>

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.

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

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

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

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/

"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:

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:

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

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!

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/

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:

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

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
> 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.

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.

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.

the process. I guess I do need that trac account after all?

Cheers

Javier

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.

>

> 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

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,

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

Do you have the inheritance graph of the categories?

Tim Daly

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?

> 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,

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.

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?

> >

> > 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,

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:

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

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
> (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?

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

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:

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?

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
> (1_A,0) which is not 1_{A\oplusB} = (1_A,1_B), right?

universal property.

> Otherwise said, the category of NonUnitalAlgebras (which is not yet

> implemented in Sage) indeed has adirectsum?

"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?

direct and semi-direct products).

Cheers,

Javier

PS: I am cross-posting this to sage-combinat-devel. Maybe we should

move the discussion there?

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.

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,

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

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.

> 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

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,

> 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
> >> 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.

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

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!

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

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?

> - 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.

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

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
> > - 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.

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.

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.

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.

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)

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

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

> 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,

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.

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.

> > 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:

> > 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,

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: