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 better-named 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 conflict-prone, 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