Hi John, On 2016-08-06, Joseph Hundley <[email protected]> wrote: > I remark that maybe when someone qualified has some time it would be worth > updating Simon's > how-to > at > http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html#base-classes. > > This bit appears (to me, anyway) to run counter to what I'm hearing here. > > Sage provides appropriate sub–classes of Parent and Element for a variety > of more concrete algebraic structures, such as groups, rings, or fields, > and of their elements.... Since we wish to implement a special kind of > fields, namely fraction fields, it makes sense to build on top of the base > class sage.rings.ring.Field provided by Sage.
Well, I believe it *does* make sense to use pre-existing stuff. Let me phrase it as follows: - The category framework is flexible enough to deal with complicated cases in which the actual category of an instance depends on the arguments used to determine the instance. - The category framework is strong enough so that a plain Parent is a sufficient base class. - From the perspective of speed, a well-chosen element class seems more important to me than a well-chosen parent class. - In order to obtain the same flexibility for elements that we have for parents, I think it is a good idea to make sage.structure.element.Element fully functional. But even when everything can be done with Parent and Element and categories: Why should one *not* use existing base classes such as sage.rings.ring.Field if one implements something that certainly is a field? Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
