Dear Jason, Javier, John,
Thanks all for your feedback and clarification!
On Wed, Aug 26, 2009 at 11:52:37AM -0700, John H Palmieri wrote:
> 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'.
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!
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
