Dear William, dear David, Dear Javier,
Yippee, there remains essentially only eight categories left to review!
On Sat, Oct 24, 2009 at 12:04:45AM +0200, Nicolas Thiéry wrote:
> On Fri, Oct 23, 2009 at 05:23:15PM +0200, David R. Kohel wrote:
> > I put of positive review of most of the assigned category files.
> I am now having a look at your comments on the wiki.
David: I let you edit the wiki for those categories for which you are
satisfied with the answers belows.
> About _call_ in NumberFields: What is the meaning of this coercion?:
>
> def _call_(self, x):
> r"""
> Constructs an object in this category from the data in ``x``,
> or throws a TypeError.
>
> EXAMPLES::
>
> sage: C = NumberFields()
>
> sage: C(QQ)
> Rational Field
>
> sage: C(NumberField(x^2+1,'a'))
> Number Field in a with defining polynomial x^2 + 1
>
> sage: C(UnitGroup(NumberField(x^2+1,'a'))) # indirect
> doctest
> Number Field in a with defining polynomial x^2 + 1
>
> sage: C(ZZ)
> Traceback (most recent call last):
> ...
> TypeError: unable to canonically associate a number field to
> Integer Ring
> """
> try:
> return x.number_field()
> except AttributeError:
> raise TypeError, "unable to canonically associate a number field
> to %s"%x
>
> Note: A unit group is not a number field (nor a field). It should coerce into
> a category of groups.
>
> By this logic one might associate to the integers ZZ the number
> field QQ, but I don't see why C(X) should try to find some functor
> which is not a canonical identity on objects.
That's the original implementation of NumberFields._call_. The
category patches just adds a couple examples to the documentation to
show the consequences of this logic. Now it's up to you guys to decide
whether this logic is desirable or not. I vote for leaving it as is
right now since it does not change the logic, and then up to you to
update it to whatever you want once the category code is in Sage.
> pointed_sets: the __call__ function is commented out -- should this
> be a not-implemented error?
Not needed: with the default implementation of __call__
PointedSets()(P) returns P if P is readily in this category, and
raises a not-implemented error otherwise.
> sets_with_partial_maps: the call function is commented out -- same
> comment as above; does this call function fall through to the call
> function on Sets()?
I am not sure I see exactly what you mean. Is there an inconvenient to
the default implementation mentioned above?
> rings - David K: Can the TODO be implemented Rings() == Algebras(ZZ)?
Not with the current infrastructure, but as stated on the linked page
in the wiki, that should be doable in the future with some more
lazyness.
> hecke_modules (positive review: this should probably be revisited --
> notes a hecke algebra or ring category to be useful; this is
> probably not currently used.)
>
> modular_abelian_varieties (positive review): ask William Stein to
> confirm: why there is no abelian varieties category and is that a
> desirable subcategory
>
> schemes (positive review): note that someone might want to revisit
> this in the future and come up with reasonable subcategories
> (abelian varieties, etc)
William: please have a look at some point, and add relevant TODO's in
http://sagetrac.org/sage_trac/wiki/CategoriesRoadMap for later
evolutions of categories.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
