Longest element in a Coxeter Group - name decision

[Kannappan Sampath]

Hello friends, 

I am writing this mail to ask for your help in a naming decision. 

In the file sage/categories/finite_coxeter_groups.py, there is a function called long_element. The docstring asks if this should be renamed and if so, to what?  

There are two suggestions from the authors: longest_element, maximal_element. 

Now, I think "longest_element" is pretty common. But, LiE, Marc's Lie Group computation software seems to call this `long_word()`. 

1) what should we pick?

2) I started a ticket to clean up this file on trac: http://trac.sagemath.org/sage_trac/ticket/14050 

I understand that name changes are to be handled with care. How do we go about this one? Deprecate? 

With Sincere Regards, 

Kannappan. 

[tom d]

I think longest_element is fine; long_word indicates that there will be a word returned instead of an element, which is maybe not what we're after here.

Wiser minds than mine will have more knowledge of how to handle deprecation, but here's an example from skew_partition.py:

sage: x.r_quotient??

Type:       instancemethod

String Form:<bound method SkewPartition_class.r_quotient of [[12, 6, 5, 3, 1], [6, 5, 3, 1]]>

File:       /home/kaibutsu/sage-5.7/local/lib/python2.7/site-packages/sage/combinat/skew_partition.py

Definition: x.r_quotient(self, length)

Source:

    def r_quotient(self, length):

      """

      This method is deprecated.

      EXAMPLES::

          sage: SkewPartition([[3, 3, 2, 1], [2, 1]]).r_quotient(2)

          doctest:1: DeprecationWarning: r_quotient is deprecated. Use quotient instead.

          See http://trac.sagemath.org/5790 for details.

          [[[3], []], [[], []]]

      """

      from sage.misc.superseded import deprecation

      deprecation(5790, 'r_quotient is deprecated. Use quotient instead.')

      return self.quotient(length)

[Nicolas M. Thiery]

On Tue, Mar 05, 2013 at 03:11:00AM -0800, tom d wrote:
> I think longest_element is fine;

Ok for me, unless someone finds something better.

> long_word indicates that there will be a word returned instead of
> an element, which is maybe not what we're after here.

+1


Thanks Kannappan for your work on this! By the way: would you mind
using the occasion to move this method to the CoxeterGroups category?
Of course, calling "W.longest_element()" for an infinite coxeter group
W is not a wise thing to do; but we recently had the need for
computing longest elements for finite parabolic subgroups and
``W.longest_element(I)`` would have been useful. Ideally there would
be a warning or error if called without argument or on an infinite
parabolic subgroup, but that might be tricky to detect.

Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[Travis Scrimshaw]

Hey,

Thanks Kannappan for your work on this! By the way: would you mind
using the occasion to move this method to the CoxeterGroups category?
Of course, calling "W.longest_element()" for an infinite coxeter group
W is not a wise thing to do; but we recently had the need for
computing longest elements for finite parabolic subgroups and
``W.longest_element(I)`` would have been useful.  Ideally there would
be a warning or error if called without argument or on an infinite
parabolic subgroup, but that might be tricky to detect.

 

   I'd throw a type error if the group W was infinite since this does not exist. Also I would think it would be (relatively) easy to check if subgroup the group is finite since there are only 3 infinitely families and would be easy to detect when it does not fall into these types (basically if the Coxeter matrix has something off the sub/super diagonals or is type D), the rest are exceptional and could just be a big case check by equality. Of course this would only be after it has been broken up into connected components. Perhaps I'm over simplifying things...

Best,

Travis

[Christian Stump]

> Of
> course this would only be after it has been broken up into connected
> components. Perhaps I'm over simplifying things...

If I understand it right, Nicolas suggested to move that stuff the the
CoxeterGroups category. In this generality, this approach of checking
finite types doesn't work, but the other way round should be possible
by checking if the Cartan matrix is a finite type Cartan matrix.

Cheers, Christian

[Nicolas M. Thiery]

On Wed, Mar 06, 2013 at 04:27:57AM -0800, Travis Scrimshaw wrote:
> I'd throw a type error if the group W was infinite since this does not
> exist. Also I would think it would be (relatively) easy to check if
> subgroup the group is finite since there are only 3 infinitely families
> and would be easy to detect when it does not fall into these types
> (basically if the Coxeter matrix has something off the sub/super diagonals
> or is type D), the rest are exceptional and could just be a big case check
> by equality. Of course this would only be after it has been broken up into
> connected components. Perhaps I'm over simplifying things...

Yes, we will definitely want some automatic type recognition at some
point (like GAP does); as a side effect this will give finite type
detection.

Now, for the problem at hand, I guess that's overkill. Let's write in
the specs, as a big fat warning, that the function will only terminate
if the (parabolic sub) group is finite. And add some simple and fast
sanity checks in the easy to handle cases. Something like:

def longest_element(index_set=None):
if index_set is None:
if self in CoxeterGroups().Infinite():
raise ...
...