On Wed, Apr 30, 2014 at 08:12:33AM +0200, Nathann Cohen wrote:
> Well, if you find the question justified, of course the answer should be
> in the doc.
My point was not about the existence of the answer, but the way I
wrote it :-) Was it helpful?
> There is also the problem of these __add__ and _add_. From just
> looking at the names you have no idea what the difference is,
> except if you wrote the code yourself.
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.
> HMmm... Yeah, but it contains a "class CartesianProductsCategory".... Why
> shouldn't it be taken as the definition of the CartesianProductCategory
> from which all other will inherit ? Thus, why shouldn't it be taken as THE
> place to implement things like .an_element() or .cardinality() ?
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. The whole point of the current infrastructure is that when you
make a cartesian product of blahs, you get exactly the cartesian
product methods relevant to blahs. Once this infrastructure is in
place, there is no reason to make a special case for an_element or
cardinality, even though they indeed be around whatever blahs is.
It's by going in this kind of direction that we will finally get rid
of all those irritating irrelevant methods that we find in so many
Sage objects (e.g. Set([1,2,3]).base_ring()).
> > - 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.
> > - 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:
sage: c.<tab>
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
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.
