On Feb 11, 11:30 pm, Robert Bradshaw <rober...@math.washington.edu> wrote: > I don't think we should have a separate ZZ whose category is > EuclideanDomains another one whose category is Rings, another one > whose category is AbelianGroups, and another one whose category is > Sets. Perhaps this is a special case, as this is a nested set of > subcategories.
Absolutely. I think that is more a matter of choosing which objects we actually want to be able to construct. Actually, 1 dimensional free ZZ- modules and infinite cyclic abelian groups already exist for good reason, as special cases of more general constructions, so basically we already have these. > I would propose that (1) every method (within reason) whose result > depends on the category take a category as an argument and (2) for > most (but perhaps not all) methods this defaults to the category in > which the element was constructed, regardless of specializations that > are later discovered. Perhaps this could be (partially) enforced with > a decorator for such methods. Indeed. In particular, it means that a parent knows in which category it was originally created. I think that's the important observation here (the rest is a matter of how to best make use of the information available). This is because: 1) Parents are supposed to model category object and as such HAVE a category of which they are a member. This category is part of their identity. 2) Parents must be immutable because they are shared. Therefore this category cannot change. In addition, parents may keep track of their "refined category" which reflects additional structure discovered during computations. It may well be that this "refined category" plays a more important role internally because it is useful in method dispatch. Currently "refined category" is called "_category" and I don't think we're tracking the creation category. Perhaps we don't have to store it explicitly if it is recoverable via other means, but I doubt it. The in my opinion more logical naming scheme would be "category" and "refined_category". However, if for compatibility reasons this has to be "_creation_category" and "_category" instead, I think that would be acceptable. I concur with Robert that it's quite reasonable to have methods that can inquire about the properties of a parent in a category other than its creation category. Logically that's just a composition with a functor. In most cases the functor application by itself would serve little purpose, so we can just store the composition. I'm not so sure that parametrizing by category leads to particularly efficient and nice code. Different method names may work there as well. It would be the generic routine (if required) that has to dispatch by "creation_category" then. I suspect that in practice category refinement will be a relatively rare occurrence, with probably rather minimal effects. However, if we're going to allow for it we'll have to specify clear semantics for it. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
