#17979: Reimplementation of IntegerListsLex
-------------------------------------+-------------------------------------
Reporter: aschilling | Owner:
Type: defect | Status: needs_work
Priority: blocker | Milestone: sage-6.6
Component: combinatorics | Resolution:
Keywords: days64 | Merged in:
Authors: Bryan Gillespie, | Reviewers: Nathann Cohen, Jeroen
Anne Schilling, Nicolas M. Thiery | Demeyer, Travis Scrimshaw
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/ticket/17979 | 88436500facd79bdb7fe80693459373354d4ea95
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by aschilling):
> - Are `min_sum` and `max_sum` also ignored when `n` is a list? From the
doc it
> seems to be, though I am not sure that it is the best design choice in
this
> case.
Yes. As far as I know this is how it was before.
> - I was surprised by the following output:
> {{{
> sage: IntegerListsLex(3,max_length=3,floor=[1,1,1]).list()
> [[3], [2, 1], [1, 2], [1, 1, 1]]
> }}}
> I woud have expected the length of the lists to be at least 3, as I
requested
> the first three parts to be `>=1`. The documentation is consistent,
but I
> still find it surprising.
As Jeroen mentioned, floor just requires that if there is a part, then it
satisfies the
constraint. If no part is present, that is ok. If you want at least three
parts, you need
to specify min_length.
> - ``check`` seems misnamed. It is not about checking the input or
output, only
> about displaying warnings. What about `disable_warnings` instead?
Jeroen had asked us to change this. So please first agree among yourself
before asking
to change this again.
> - In the following text which says that one can force the enumeration
when it is
> formally impossible, can you explicitly say what will happen? "All
possible
> lists are enumerated, but the ordering is incorrect" or something?
> {{{If one wants to proceed anyway, one can sign a waiver by setting
check=False:}}}
When a function for the floor or ceiling is given, it is impossible to
check that
the conditions give a finite set since the list of values is in principle
infinite.
In this case the algorithm can either hang (as it computes more and more
parts of the
integer list) or it can happen that a tail of 000100000.... will appear in
which case
nor all elements in the list will be iterated over.
> - {{{sage: list(IntegerListsLex(3, max_length=2, ))}}}
Fixed.
> - Lexicographic ordering is broken when `n` is a list.
> {{{
> sage: print IntegerListsLex([1,2],length=3).list()
> [[1, 0, 0], [0, 1, 0], [0, 0, 1], [2, 0, 0], [1, 1, 0], [1, 0, 1], [0,
2, 0], [0, 1, 1], [0, 0, 2]]
> }}}
>
> In particular, the output differs depending on how `n` is sorted.
>
> - Cardinality is broken when `n` is a list
> {{{
> sage: IntegerListsLex(3,length=3).cardinality()
> 10
> sage: IntegerListsLex([3,3],length=3).cardinality()
> 20
> }}}
See the documentation!
--
Ticket URL: <http://trac.sagemath.org/ticket/17979#comment:428>
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.
