Yoooooooooo !!

> <disclaimer>
> My answer is most likely going to be a bit broad and include stuff you
> already know; I am just taking the occasion to write a blurb that
> could possibly end up somewhere in the documentation (typically as a
> complement of cartesian_product?), if someone finds it useful.
> </disclaimer>

Well, if you find the question justified, of course the answer should be in
the doc.

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.

Now, in the graph classes we have function like add_vertex,
add_vertex_unsafe, stuff like that. Wouldn't it be much better if those
_add_ were renamed to something more meaningful, like
"_add_coerced_elements_", i.e. something that describes better what they do
? Noticing that a function is called _add_ instead of __add__ is not
exactly straightforward when you don't expect it.


> The last player in the game is the `cartesian_product` object, as in
> `cartesian_product([A,B,...])`. Its role is to look at the properties
> of A,B,..., and decide on an appropriate concrete implementation and a
> category. Technically, this object is a "covariant functorial
> construction" and it's implemented in
> sage.categories.cartesian_product. In practice, unless one wants to
> use it as an example to create a new construction, there is no reason
> to fiddle with it.

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() ?

> - Vector spaces are already endowed with their addition. Sounds like
>   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 ?

> - Using .value directly breaks encapsulation and is thus
>   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 ....

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to