Changes between Initial Version and Version 1 of Ticket #18411, comment 38


Ignore:
Timestamp:
09/15/15 22:10:01 (4 years ago)
Author:
vdelecroix
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #18411, comment 38

    initial v1  
    88> is automatically filled since it is a lazy_list.
    99
    10 Oh, I had not noticed that, in EnumeratedSetFromIterator, the existence
     10Oh, I had not noticed that, in `EnumeratedSetFromIterator`, the existence
    1111of the cache was decided upon construction. +1 then.
    1212
    13 >>>> - Why moving __iter__ from EnumeratedSets.CartesianProducts to
    14 >>>> Sets.CartesianProducts?
     13>>>> - Why moving __iter__ from `EnumeratedSets.CartesianProducts` to
     14>>>> `Sets.CartesianProducts`?
    1515>>>
    1616>>> Because otherwise there are some failing doctests. For example
    17 >>>     Set([1,2,3])
     17>>>     `Set([1,2,3])`
    1818>>> is iterable but the following was not
    19 >>>     cartesian_product([Set(1,2,3), Set([1,2,3])])
     19>>>     `cartesian_product([Set(1,2,3), Set([1,2,3])])`
    2020>>>
    2121>>> The fact that something is iterable does not necessarily mean that it
    22 >>> belongs to EnumeratedSet. At least for me and the current class
    23 >>> FiniteEnumeratedSet, the enumerated set {1, 2, 3} is not equal to the
     22>>> belongs to `EnumeratedSet`. At least for me and the current class
     23>>> `FiniteEnumeratedSet`, the enumerated set {1, 2, 3} is not equal to the
    2424>>> enumerated set {3, 2, 1}. But they are equal as sets. And the set {1, 2, 3}
    2525>>> should be iterable.
    2626>>
    2727>> I see your point. Yet this is annoying; where do we want to put the
    28 >> exact limit between Set and EnumeratedSet? Where should, e.g. features
     28>> exact limit between `Set` and `EnumeratedSet`? Where should, e.g. features
    2929>> like cardinality_from_iterator live?
    3030>>
     
    5757>done
    5858>
    59 >> - CartesianProduct_iters: Make the difference with cartesian_product
     59>> - `CartesianProduct_iters`: Make the difference with cartesian_product
    6060>> more explicit and add a link?
    6161>
    6262>done
    6363>
    64 >> - Compositions: return FiniteEnumeratedSet([self])
     64>> - Compositions: `return FiniteEnumeratedSet([self])`
    6565>
    6666>done
    6767>
    68 >> or make cartesian_product() return FiniteEnumeratedSet([xxx]) or
    69 >> Set([xxx]) where xxx is the trivial tuple.
     68>> or make `cartesian_product()` return `FiniteEnumeratedSet([xxx])` or
     69>> `Set([xxx])` where `xxx` is the trivial tuple.
    7070>
    7171>This is not a good idea. The interface should be uniform when you do
     
    7676>I did not found any. The empty tuple comes from the iteration with product.
    7777>
    78 >> - root_lattice_realization: is the conversion to FiniteEnumeratedSet
     78>> - root_lattice_realization: is the conversion to `FiniteEnumeratedSet`
    7979>> still necessary?
    8080>>
     81>> {{{
    8182>> C = cartesian_product([PositiveIntegers(),
    8283>> FiniteEnumeratedSet(Q.roots())])
     84>> }}}
    8385>>
    8486>> If so, should instead cartesian_product do more input tidying work?
     
    9092> >infinity
    9193>
    92 > I reintroduced the test using cartesian_product instead of CartesianProduct
     94> I reintroduced the test using `cartesian_product` instead of `CartesianProduct`
    9395>
    9496>> ... about `cartesian_product()` ...
     
    9698>> So what about returning:
    9799>>
     100>> {{{
    98101>>          sage: from sage.sets.cartesian_product import CartesianProduct
    99102>>          sage: CartesianProduct((), Sets().CartesianProducts())
    100103>>          The cartesian product of ()
     104>> }}}
    101105>>
    102106>> I vaguely remember we discussed this at some point, but don't remember
    103107>> what the outcome was. Of course if the user did not specify a category
    104 >> to cartesian_product(), we don't quite know what's the category he
    105 >> expects, but Sets().CartesianProducts() sounds like a reasonable
     108>> to `cartesian_product()`, we don't quite know what's the category he
     109>> expects, but `Sets().CartesianProducts()` sounds like a reasonable
    106110>> starting point.
    107111>
     
    109113>backward compatibility it needs to be done in that ticket... we had
    110114>
     115> {{{
    111116>sage: CartesianProduct()
    112117>Cartesian product of
     
    115120>sage: CartesianProduct().an_element()
    116121>[]
     122>}}}
    117123>
    118124>There is an other commit for that.