Hi Paul, On 2012-11-28, Paul-Olivier Dehaye <pauloliv...@gmail.com> 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.
