#19395: Implement Tableau to sign matrix code
-------------------------+-------------------------------------------------
       Reporter:         |        Owner:
  ssolhjem               |       Status:  needs_work
           Type:         |    Milestone:  sage-6.10
  enhancement            |   Resolution:
       Priority:  major  |    Merged in:
      Component:         |    Reviewers:  Kevin Dilks
  combinatorics          |  Work issues:
       Keywords:         |       Commit:
  Tableau                |  5b006a1b94be67ac56c96921ee7c68df37d31495
        Authors:  Sara   |     Stopgaps:
  Solhjem                |
Report Upstream:  N/A    |
         Branch:         |
  u/ssolhjem/19395       |
   Dependencies:         |
-------------------------+-------------------------------------------------
Changes (by kdilks):

 * status:  needs_review => needs_work


Comment:

 In terms of documentation:

 * Change the two paragraphs after the first one into {{{INPUT}}} and
 {{{OUTPUT}}} blocks (
 http://doc.sagemath.org/html/en/developer/coding_basics.html#the-
 docstring-of-a-function-content ).
 * Change the start of the docstring from {{{"""}}} to {{{r"""}}}. This
 changes the way the text is read when compiled. Then things enclosed in
 two graves (like {{{``self``}}}) will show up kind of bolded with a
 background, and is used to indicate variable names in the code. Things
 encased in a single set of graves will be read in math-mode. So things
 like numbers can go in there, and you can also do {{{'m\times n'}}}, and
 it should tex that.

 In terms of the code:
 * I wouldn't use sparse matrices. Your code goes through defines what the
 {{{partial_sum_matrix}}} and {{{sign_matrix}}} is at every single entry,
 so you're not taking advantage of the structure of sparse matrices. In
 fact, I picked a random SSYT of shape {{{[1000,999,998,...,2,1]}}} with
 {{{max_entry=10000}}}, and using sparse matrices was 4 times slower than
 not using sparse matrices.
 * Add some tests, one or two simple examples to check, one or two checking
 possible fringe cases (ie, making sure your code can handle things like
 the empty tableau, if such a thing exists).
 * Is m actually a parameter, or is m always the largest entry in the
 tableau? If it's always going to be the largest entry in the tableau, then
 it shouldn't be a parameter. But sometimes you want to consider the
 largest *possible* entry, in which case something like the SSYT
 {{{{[[1,1],[2]]}}}} would be a valid member of the set of SSYT of shape
 {{{[2,1]}}} with largest possible entry 3. In that case, I would change
 the name of the parameter m to {{{max_entry}}}. Make it default to the
 largest entry appearing in the tableau if the user doesn't specify a
 parameter. Your code should also check to make sure that any
 {{{{max_entry}}}} parameter entered into this method is at least as big as
 the largest entry in the tableau.

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