Changes between Initial Version and Version 1 of Ticket #10963, comment 450


Ignore:
Timestamp:
01/20/14 17:15:44 (9 years ago)
Author:
pbruin
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #10963, comment 450

    initial v1  
    1111{{{
    1212CartesianProduct.summand_projection()
    13 Sets.CartesianProduct.ParentMethods.summand_projection()
    14 Sets.CartesianProduct.ElementMethods.summand_projection()
    15 Sets.CartesianProduct.ElementMethods.summand_split()
     13Sets.CartesianProducts.ParentMethods.summand_projection()
     14Sets.CartesianProducts.ElementMethods.summand_projection()
     15Sets.CartesianProducts.ElementMethods.summand_split()
     16CombinatorialFreeModule_CartesianProduct.summand_embedding()
     17CombinatorialFreeModule_CartesianProduct.summand_projection()
    1618}}}
    1719Maybe 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.
    … …  
    1921My 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?
    2022
    21 There are also `summand_embedding()` and `summand_projection()` methods in `CombinatorialFreeModule_CartesianProduct`.  That 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.
     23For 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.
    2224
    2325> Also, I would like something different from ``factors'', since we will