#8392: Implement RSK for generalized permutations
-------------------------------------+-------------------------------------
Reporter: nborie | Owner: tscrim
Type: enhancement | Status: closed
Priority: major | Milestone: sage-5.11
Component: combinatorics | Resolution: fixed
Keywords: permutation, | Merged in: sage-5.11.beta0
check, days38, days45 | Reviewers: Jeff Ferreira, Darij
Authors: Travis Scrimshaw | Grinberg
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: #6495, #13605, | Stopgaps:
#8703, #14459, #14319, #14302 |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Hey Franco,
Replying to [comment:38 saliola]:
> Thanks for writing this patch. I support the proposed clean up of the
code, but I want to raise an objection to choices in the user interface:
>
> - I don't think that it is useful to deprecate the method
{{{robinson_schensted}}}:
>
> {{{
> DeprecationWarning: p.robinson_schensted() is deprecated. Use instead
RSK(p)
> }}}
>
> Telling users to use the RSK function instead of a method is not in
the spirit of object-oriented programming. More importantly, it is totally
unnecessary to deprecate the method.
If we wanted to be fully OOP, then there needs to be a class of something
like `RSKUsable` which has an abstract method `RSK()` where each type of
object implements it's own version of RSK and `RSKUsable` would implement
the row-insertion procedure. The problem with this is that we want to be
able to handle (pairs of) lists, which we can't modify its class structure
and I don't want to have to wrap a list as a word, and I also don't want
to clutter up the MRO. Another reason why this is better as a function is
most of the operation is independent of the type of object being passed
in; all it does is it converts it into a pair of lists of the same size.
Thus it provides a uniform interface for objects, and the fact that only
permutations has such a method conflicts with this, so I think it is
worthwhile to deprecate this.
> - Also, I disagree with importing {{{RSK, RSK_inverse,
RobinsonSchenstedKnuth, RobinsonSchenstedKnuth_inverse}}} into the global
namespace when one object could easily handle all of these.
Then what is your proposed interface? If the input is a pair of tableaux
as a list or is given as input 2 tableaux, then run the inverse? Hence we
should combine two functions which do completely different behavior into
one as I think of RSK as a procedure in 1 direction? What about if someone
only thinks of this as the Robinson-Schensted bijection and tries
`RobinsonSchestead<tab>`? This is why I setup these aliases and imported
them.
> - Perhaps these names should not be capitalized since they are python
functions and not classes. See the
[http://www.sagemath.org/doc/developer/conventions.html?highlight=camelcase
#python-coding-conventions developers guide].
For the full name, probably yes it should be changed. For the shortname
`RSK`, it is an acronym, so I think it is better and more likely to be
found than `rsk`. See the bottom of
[http://www.sagemath.org/doc/developer/conventions.html?highlight=camelcase
#python-coding-conventions this section of the developers guide].
> The ability of doing RSK and EG is a great feature, but the
documentation isn't very clear. What is [3,3,2] mean with EG insertion?
Since it isn't a reduced word, how should this be interpreted?
The documentation could use some expansion.
> I would have expected that the output of RSK could be used as input to
RSK_inverse:
This is because it's more logical to me for the input to be 2 arguments
where we can explicitly specify what they are (as arguments), than a
single parameter taking a list and checking to make sure it has length 2
and explaining the (non-standard IMO) input form in the docsting. We could
handle both forms of input, but this seems overly complicated, and I
imagine python programmers would simply use the `*` to expand the list as
inputs as in the EG examples. This could probably use another example
(maybe so far as a docstring explanation, but I'm hesitant about that)
that's not for EG insertion.
Best,[[BR]]
Travis
--
Ticket URL: <http://trac.sagemath.org/ticket/8392#comment:41>
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/groups/opt_out.
