#18223: cartesian products with orders
-------------------------------------+-------------------------------------
Reporter: dkrenn | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.7
Component: categories | Resolution:
Keywords: sd67 | Merged in:
Authors: Daniel Krenn | Reviewers: Benjamin Hackl
Report Upstream: N/A | Work issues:
Branch: u/dkrenn/cat | Commit:
/cartesian-product-posets | f3b1387b378ce406e04c6f45c6629595a46640c8
Dependencies: #18586 | Stopgaps:
-------------------------------------+-------------------------------------
Changes (by dkrenn):
* status: needs_work => needs_review
Comment:
Replying to [comment:32 vdelecroix]:
> Instead of using `QQ` which is not a poset in the doctest why not use
available ones from `Posets.<tab>`?
Ok, done for the public method(s). (But I've kept the `QQ`-test in some of
the private methods).
> 10. In the documentation clqss of `CartesianProductPosets` you should
say that `order` and `order_le` are optionals and what is the default
behavior. You should also document the behavior of
> {{{
> sage: CartesianProductPoset([X,Y,Z], order='lex', order_le=my_le)
> }}}
> (or raise an appropriate error)
`order_le` is not a keyword. I've rewritten the doc to avoid this
confusion.
> 11. I am not sure how much this is supported but parents are allowed to
have their `category` argument to be set to a tuple as in
> {{{
> sage: P = Parent(category=(Rings(),Posets()))
> sage: P.category()
> Join of Category of rings and Category of posets
> }}}
> In your subclass, the operation `category & Posets()` would break. You
might use the safer `Category.join(my_list_of_categories)`. If you do so,
add an appropriate doctest for that.
Changed.
> 12. What is the point of adding `*kwargs` in the `__init__` method of
`CartesianProduct`? If this argument is not supported then it should
simply not exists.
This boils down to our discussion from #18586: They are passed on to
`CartesianProduct` where there is at least a `flatten` keyword. Thus there
is a keyword, so arguments are simply passed.
> 13. Add some `TestSuite(C).run()` for various cartesian products of
posets (i.e. at least with the two default implemented orders and one self
implemented).
Added.
> 14. Since the cartesian product elements are tuples, we might want to
use the orders from the tuple themselves (which is fastest then anything
else). What about an alternative
> {{{
> def le_native(self, x, y):
> return x.value <= y.value
> }}}
Added.
> 15. I am not sure that it is good to have the `le_*` methods as being
public. Do you have some feeling about it?
Yes, I'd prefer to keep them public, so one can use a different ordering
easily (I mean, without changing the given order, but use another order
for whatever reasons). Moreover, there seems no need to hide this methods
from the public (they can just be used as `le` in posets).
--
Ticket URL: <http://trac.sagemath.org/ticket/18223#comment:35>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
