#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:
  Anne Schilling, Nicolas M. Thiery  |  Work issues:
Report Upstream:  N/A                |       Commit:
         Branch:                     |  39d1993d70a837967109be12de261f4f504901cc
  public/ticket/17979                |     Stopgaps:
   Dependencies:                     |
-------------------------------------+-------------------------------------

Comment (by nthiery):

 Replying to [comment:85 jdemeyer]:
 > Replying to [comment:75 bgillespie]:
 > > Note that `floor` and `ceiling` take multiple different types of
 parameters, not just functions.  This code checks for the type of the
 input parameter and optimizes when using a constant or a list of integers.
 >
 > However, without `min_part`, there is absolutely no way to specify
 "`floor` is a function which is always at least 1". I should be able to
 specify such an input with `floor=myfunc, min_part=1` and the code can
 optimize this case better than when just specifying the function.
 [comment:60] is an excellent example of this.

 We were experimenting a bit with the API to try to minimize redundancy.
 At this point, I have settled for:

 - `min_part` to specify a lower bound for all parts
 - `floor` to specify lower bounds on the individual parts

 What do you think?

 Question: if the users passes `floor=f, min_part=i` should
 `IntegerListsLex` assume that `f(k)` is always at most `i`, or should it
 wrap `f` to add this guarantee? At this point it does the latter, which of
 course adds a bit of overhead (which could be tamed with appropriate
 caching which we will anyway want to do during the Cythonization).

--
Ticket URL: <http://trac.sagemath.org/ticket/17979#comment:105>
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.

Reply via email to