Changes between Initial Version and Version 1 of Ticket #10963, comment 450
 Timestamp:
 01/20/14 17:15:44 (9 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #10963, comment 450
initial v1 11 11 {{{ 12 12 CartesianProduct.summand_projection() 13 Sets.CartesianProduct.ParentMethods.summand_projection() 14 Sets.CartesianProduct.ElementMethods.summand_projection() 15 Sets.CartesianProduct.ElementMethods.summand_split() 13 Sets.CartesianProducts.ParentMethods.summand_projection() 14 Sets.CartesianProducts.ElementMethods.summand_projection() 15 Sets.CartesianProducts.ElementMethods.summand_split() 16 CombinatorialFreeModule_CartesianProduct.summand_embedding() 17 CombinatorialFreeModule_CartesianProduct.summand_projection() 16 18 }}} 17 19 Maybe the quickest solution is to insert betternamed aliases for these, rename the method `summands()` introduced here, and later deprecate `summand_projection()` and `summand_split()` in a different ticket. … … 19 21 My first reflex would be to rename `summand_projection()` to `projection()` and `summand_split()` to `tuple()`. If this is too conflictprone, maybe using the prefix `cartesian_` suggested by Simon would be a solution? 20 22 21 There are also `summand_embedding()` and `summand_projection()` methods in `CombinatorialFreeModule_CartesianProduct`. Thatis OK if and only if there are only finitely many summands/factors; in that case the product and sum coincide, since modules form an additive category.23 For products of modules (the last two methods in the above list), calling the components "summands" is OK if and only if there are only finitely many summands/factors; in that case the product and sum coincide, since modules form an additive category. 22 24 23 25 > Also, I would like something different from ``factors'', since we will