Hi Alex, This is a historical legacy of a heavy-handed attempt by William and me to implement schemes "from the book" (aka Hartshorne):
sage: A = AffineSpace(2, ZZ) sage: p = A(0, 0) sage: p.parent().category().element_class <class 'sage.categories.category.Schemes_abstract.HomCategory. element_class'> sage: type(p) <class 'sage.schemes.generic.morphism.SchemeMorphism_point_affine'> It is mathematically correct to say that a point is a section from the base scheme (often a field), whose coordinates are the values of the coordinate functions. However, in most working settings, you just want a list of coordinates over a ring or field. This is more efficient, more intuitive, and easier to work with. In the worst case you need multiple lists of coordinates which glue together where the base ring is not a PID or is a more general scheme. This is the standard parent-element standard used by Sage (elsewhere) and Magma. (This is a subjective point which I will argue:) Such elements are not described by a category framework (which deals with objects, morphisms, and functors). Elements are practical things which we often demand of objects in order to evaluate maps between objects. They often do have a categorical interpretation by their identification with morphisms from a free object (if such exists), but in retrospect equating the set of elements X(S) with Hom(S,X) was a bad idea. We don't implement set, module or ring elements this way, and shouldn't for schemes either. Instead, ditch this, create an elements class in the standard parent-element dichotomy and have constructors to turn elements of X(k) into morphisms in Hom(Spec(k),X). This was already done, I believe, for elliptic curves precisely because the beautiful Grothendieck theory of points as morphisms was too slow to be of any use; coordinate access by evaluation of the composition of a morphism S -> X with a coordinate function just doesn't cut it. The general theory is needed for X(S) but the line between efficient elements and their interpretation as morphisms can be made by the choice of users: X(k) or X(R) for a field k or ring R will be implemented differently from X(Spec(k)) and X(Spec(R)). --David -- 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 URL: http://www.sagemath.org
