Thank you for the extensive explanation. It clarifies things I obviously didn't understand... sage.categories.pushout is the most relevant part for what I was trying to ask. Paul
On Wednesday, November 28, 2012 2:31:06 PM UTC+1, Simon King wrote: > > Hi Paul, > > On 2012-11-28, Paul-Olivier Dehaye <paulo...@gmail.com <javascript:>> > wrote: > >> > change "To coerce from the category down to the parent" --> "To > coerce > >> from > >> > the abstraction layer to the parent". In this abstraction layer > (which > >> is > >> > close to the categories now available, but not quite the same), > > I still don't get what you are talking about. > > What do you mean by "abstraction layer"? For example, if you have a > vector space with a fixed basis, would the next abstraction layer be the > vector space without the choice of a basis? I think this is what Nicolas > calls "abstract parent" or so. But this is by no means close to the > categories now available! The abstract parent would still be *object* of > a category. > > >> > we would > >> > have a list of methods for the parent class and the element class of > a > >> > Category C. Now say you have parentA and parentB both implementing > the > >> same > >> > category C. > > Nonono. parentA and parentB implement *objects* of said category. > > >> > As part of its definition, parentA c/should tell how to > >> > initialize it using exclusively methods from this abstraction layer. > But > >> > parentB implements some of these methods. With any luck there might > be > >> > enough overlap that we automatically get a coercion from parentB -> > >> parentA. > > Hm. Are you perhaps suggesting that the category of a parent should > prescribe what basic data are needed to determine one of its objects? I > think that can not work. > > > You are asking about a different kind of coercion from the one I was > > talking about (that's part of my point: some are are purely at the > > concrete/Parents level -when the category does not change, I think these > > are called conversions as well-, > > I think we should settle some notions. > > Axioms for "coercion": > > * A "coercion" is a morphism in a category. Hence, if A and B are parents, > then a coercion from A to B is in Hom_C(A,B), where C is a category > which has both A and B as objects. > * There is at most one coercion between A and B. > * The composition of a coercion is a coercion. > * id_A is the coercion from A to A. > > Axioms for "conversion": > > * A "conversion" from a parent A to a parent B is a partial map from A > to B. > * I think we want uniqueness, but we do not assume that the composition > of conversions is a conversion. > * *If* there is a coercion from A to B, then the conversion map must > coincide with the coercion homomorphism. > > Are you talking about the same notion? > > > Let's use decorators to describe the two "pure" kinds of coercions, with > > prototype of the code that would run: > > 1) Purely concrete level - the kind I was talking about - the category > > stays the same, but the implementation (i.e. parents) changes. > > If we talk about coercion, then we talk about a fixed category, namely > the one which the coercion is morphism of. > > > Even in this > > case this is dealt with by specifying in terms of the category what > > arguments the constructor takes in each of the parents. > > "Constructor" of what? Constructor of an object? Or constructor of an > element of an object? I really don't see how the category of Rings() > could possible prescribe the argument spectrum for the constructor of a > ring element. > > > class Parent1(Parent, category = CategoryC): # > > unrelated point: for me it makes more sense to specify the category > here. > > No, not at all! Instances of the same parent class may very well belong > to different categories. So, I think it makes no sense to prescribe a > category in a class definition. > > > class Element1(Parent1.Element) > > That would be an error even when using metaclasses: Simply > Parent1.Element is not defined at that point. > > And besides, there *are* parent classes such that the element classes > have different backends. For example, all matrix spaces are implemented > using the same parent class - but the chosen element class depends on > whether we have a finite field of characteristic 2, a finite prime field > of odd characteristic, a finite non-prime field of odd characteristic, > ZZ, QQ or general commutative rings. > > Hence, it is not the case that the element class is determined by the > parent class. And it can also be (but I don't know if this is used) that > the same element class can be used to implement the elements of parents > that belong to different parent classes. > > > So CategoryC has many invariants, M to Z. > > This may be possible for the category of vector spaces: You need a field > K, an integer n presribing the dimension, and a list B of n elements > prescribing a basis, and these data define a vector space with basis. > And you need n elements of K to determine an element of that vector > space with basis. > > But what do you do for general categories such as the category of > rings? > > > Coercions would allow here to construct a composite parent from many > > different parents sharing the same category. > > Again, it seems we use totally different notions. A coercion in the > usual meaning in Sage does not "construct a composite parent". Perhaps > you are talking about construction functors (functors may of course > transform a given parent into a new parent)? > > Construction functors are an important brick in Sage's coercion model. > See sage.categories.pushout. > > > 2) Now, this is the kind you were asking about: coercions between > Parents > > with different underlying categories. > > Again, different notion. A coercion is a morphism in a category to which > *both* parents belong as objects. > > > For this coercion, nothing would be required of the Parents: it has > nothing > > to do with them! > > Someone would have to say in the category framework that there is always > a > > morphism from a ring R to a graded algebra over that ring R, and > register > > this as a coercion > > For that purpose, you can define a parent method __init_extra__ in the > category. > In fact, sage.categories.algebras.Algebras.ParentMethods.__init_extra__ > has the purpose of registering a coercion from the base ring. > > > Is this unrealistic? Does some of this already happen? > > See above, it is already done. > > Best regards, > Simon > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
