> My point was not about the existence of the answer, but the way I > wrote it :-) Was it helpful?
Oh. As an answer on sage-devel yes, but you can' t write ling things like that in the doc. I mean, if you do people probably will not find it when they have the problem. > This is about the coercion system, which has been in Sage since 2008 > or so. When I joined Sage and started implementing elements, I found > the information by reading the documention of > sage.structure.element. Now we have Simon's very nice thematic > tutorial "How to implement new algebraic structures in Sage", which > explains this in details. > > If you believe the names should be changed, open a thread on the > subject on sage-devel. Not my job. Really. I don't mind fixing bugs in graphs/LP/Designs, but making sure that the category/coercion system is bug-free and understandable is not my job. That's when somebody who feels responsible about this has to deal with it. What I do is provide bug reports, and it seems that some people agree that this should be changed. > If we put everything about cartesian products in a single spot, we > will end up, for example, with a bunch of irrelevant methods (like > "one", "product", ...) when we construct a plain cartesian product of > sets. No, the "one" thing does not belong to CartesianProduct because it does not apply to everything. I was just wondering about category/cartesian_product and sets/cartesian_product. Those two files seem to address all cartesian products of everything (and this everything is always a set, isn't it ?) >> > - Vector spaces are already endowed with their addition. Sounds like >> > A you accidently overrode it. >> HMmmm... I don't get it. CommutativeAdditiveGroup is more general than >> vector spaces, so if something is a vector space it should inherit all >> addition functions from vector spaces, shouldn't they ? > > That's the general principle indeed; I would need to see the code to > find out what went wrong precisely. I will be glad to send it to you if it happens, in the meantime I hope that I will never see it again :-P >> > - Using .value directly breaks encapsulation and is thus >> > A implementation dependent. >> Yeah but I needed to iterate over all the coordinates of an element of a >> cartesian product. Does it mean that I should instead implement an >> __iter__ in the ParentMethods of the category they belong to ?.. I'll try >> that .... > > I would iterate through x.cartesian_factors(): > > sage: C = cartesian_product([GF(3), GF(5)]) > sage: x = C.an_element() > sage: x.cartesian_factors() > (0, 0) > sage: for i in x.cartesian_factors(): ... > > or its equivalent pre #10963; I don't remember the name, but see: The current Sage *IS* pre-10963. And I hope that you have summand_projection in mind for it is what I used in #16269. Thanks for your answers. It really makes a difference when I feel I am not speaking where nobody cares to listen. Nathann -- 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. For more options, visit https://groups.google.com/d/optout.
