Alcove model in affine cartan type

[sagetrac-alubovsky]

Extending the alcove path model implementation to affine type.

Apply:

• attachment: trac_14143-alcove-path-al.3.patch

CC: @sagetrac-sage-combinat @tscrim @anneschilling

Component: combinatorics

Keywords: alcove model, days45

Author: Arthur Lubovsky

Reviewer: Anne Schilling

Merged: sage-5.11.beta2

Issue created by migration from https://trac.sagemath.org/ticket/14143

[sagetrac-alubovsky]

comment:1

The second patch replaces the first, but there does not appear to be a way to do that if one forgets to click "replace patch with the same name" when submitting the patch initially.

Edit: The third patch is the latest one. It would be nice to be able to remove the first two.

[sagetrac-alubovsky]

Description changed:

--- 
+++ 
@@ -1 +1 @@
-The current implementation of the alcove model doesn't work in affine cartan type. 
+Extending the alcove path model implementation to affine type.  

[sagetrac-alubovsky]

comment:2

Attachment: trac_14143-alcove-path-al.patch.gz

[sagetrac-alubovsky]

Attachment: trac_14143-alcove-path-al.2.patch.gz

[nthiery]

comment:3

Hi Arthur,

I just did a trivial rebase of your patch in the queue: it did not apply on all.py due to the addition of CrystalOfProjectedLevelZeroLSPaths yesterday.

By the way: there is no reason to import CrystalOfAlcovePathsElement in the global name space. So I removed that. Also your patch removes the former ClassicalCrystalOfAlcovePaths. This is good since the new version is more general; however a deprecation link should inserted.

See: http://www.sagemath.org/doc/developer/coding_in_python.html#deprecation

Cheers,
Nicolas

[anneschilling]

comment:4

Hi Arthur,

Thanks for your patch on alcove paths. Here are some further comments that would be good to incorporate!

• Please specify what the default value of good_zero_arrows is. Do you want to merge this experimental code into main sage, or rather separate it out into a personal patch that can be used by yourself and your collaborators (and me :-) )?

• "Littlewood paths" in the documentation of sage.combinat.crystals.alcove_path.CrystalOfAlcovePaths should be "Littelmann paths"

• "We verify the alcove path crystal with the LS path crystal" should probably be "We verify that the alcove path crystal is isomorphic to the LS path crystal".

• The interface for the LS paths has changed and now the preferred way is to input an actual weight rather than the coefficients of the fundamental weights. The advantage is that weights are typed whereas a list of coefficients is not. Do you think you could have a look at LS paths and make the user interface for Alcove paths consistent with it? I think this would be good for the users!

• Since you mention Demazure 0-arrows in your documentation, please define what they are!

• For the method vertices please explain how you compute all crystal elements without the crystal operators (since you say that they cannot all be reached by crystal operators; so you must have an alternative way!).

• For the method :meth:digraph_fast perhaps give an example of how the speed compares to the usual digraph method and max_depth setting. You can do this with %timeit for example.

• Why is the method static sign(root) in alcove paths and not in root_systems? The same question holds for max_level.

• Typo in :meth:words: "finte Cartan types" -> "finite Cartan types"

• Please explain the inputs of sage.combinat.crystals.alcove_path.compare_graphs(g1, g2, node1, node2).

• I get some doctest failures:

sage -t alcove_path.py
**********************************************************************
File "alcove_path.py", line 637, in sage.combinat.crystals.alcove_path.CrystalOfAlcovePathsElement.epsilon
Failed example:
    [c.epsilon(1) for c in C]
Exception raised:
    Traceback (most recent call last):
      File "/Applications/sage-5.9/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 466, in _run
        self.execute(example, compiled, test.globs)
      File "/Applications/sage-5.9/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 825, in execute
        exec compiled in globs
      File "<doctest sage.combinat.crystals.alcove_path.CrystalOfAlcovePathsElement.epsilon[1]>", line 1, in <module>
        [c.epsilon(Integer(1)) for c in C]
      File "/Applications/sage-5.9/local/lib/python2.7/site-packages/sage/combinat/crystals/alcove_path.py", line 647, in epsilon
        return super(CrystalOfAlcovePathsElement, self).epsilon(i)
      File "/Applications/sage-5.9/local/lib/python2.7/site-packages/sage/misc/abstract_method.py", line 224, in __get__
        raise NotImplementedError(repr(self))
    NotImplementedError: <abstract method epsilon at 0x10a74ab90>
**********************************************************************
File "alcove_path.py", line 639, in sage.combinat.crystals.alcove_path.CrystalOfAlcovePathsElement.epsilon
Failed example:
    [c.epsilon(2) for c in C]
Exception raised:
    Traceback (most recent call last):
      File "/Applications/sage-5.9/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 466, in _run
        self.execute(example, compiled, test.globs)
      File "/Applications/sage-5.9/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 825, in execute
        exec compiled in globs
      File "<doctest sage.combinat.crystals.alcove_path.CrystalOfAlcovePathsElement.epsilon[2]>", line 1, in <module>
        [c.epsilon(Integer(2)) for c in C]
      File "/Applications/sage-5.9/local/lib/python2.7/site-packages/sage/combinat/crystals/alcove_path.py", line 647, in epsilon
        return super(CrystalOfAlcovePathsElement, self).epsilon(i)
      File "/Applications/sage-5.9/local/lib/python2.7/site-packages/sage/misc/abstract_method.py", line 224, in __get__
        raise NotImplementedError(repr(self))
    NotImplementedError: <abstract method epsilon at 0x10a74ab90>
**********************************************************************
1 item had failures:
   2 of   4 in sage.combinat.crystals.alcove_path.CrystalOfAlcovePathsElement.epsilon
    [212 tests, 2 failures, 97.16 s]
----------------------------------------------------------------------
sage -t alcove_path.py  # 2 doctests failed
----------------------------------------------------------------------
Total time for all tests: 97.4 seconds
    cpu time: 94.8 seconds
    cumulative wall time: 97.2 seconds

So much for now!

Anne

[sagetrac-alubovsky]

comment:5

Hi Anne,

If it's not mentioned below, I addressed it in the new patch on combinat queue.

• Do you want to merge this experimental code into main sage, or
  rather separate it out into a personal patch that can be used by yourself and your collaborators (and me :-) )?

  A patch would probably be ideal. Would it then permanently live
  at the very bottom of the queue? Or just something available in
  private (which may be easier to implement).

  • The interface for the LS paths has changed and now the preferred way is
    to input an actual weight rather than the coefficients of the fundamental
    weights. The advantage is that weights are typed whereas a list of
    coefficients is not. Do you think you could have a look at LS paths and
    make the user interface for Alcove paths consistent with it? I think this
    would be good for the users!

    Still need to do this part. It's a bit tricky and I don't have much
    time at the moment. When I find some time... I guess in order to
    stay compatible with the old ClassicalCrystalOfAlcovePaths code I have
    to do the same implementation as the LS paths code, instead of just
    changing the parameters by hand.

  • Why is the method static sign(root) in alcove paths and not in
    root_systems? The same question holds for max_level.

    root_systems already has a is_positive_root method, sign is just
    something convenient for my purposes. Should I rename it to _sign?
    max_level is something specific to the alcove model. Can be renamed to
    _max_level. Since that is part of a private class
    (doesn't get imported into sage) I don't see the point.

    FYI, On line 284, TestSuite(C).run() (in the affine case( is now
    taking around 150sec, which it didn't used to (I added a #long time).
    Not sure why this is happening.

Arthur

[anneschilling]

comment:6

Hi Arthur,

Thanks for your work on this!

• Do you want to merge this experimental code into main sage, or
  rather separate it out into a personal patch that can be used by yourself and your collaborators (and me :-) )?

  A patch would probably be ideal. Would it then permanently live
  at the very bottom of the queue? Or just something available in
  private (which may be easier to implement).

Yes, it could be a patch somewhere in the sage-combinat queue (after the "Needs Review" section). Although, the queue will disappear soon anyway, but if you want to share the code with others, it might be best to have a patch for it!

• The interface for the LS paths has changed and now the preferred way is
  to input an actual weight rather than the coefficients of the fundamental
  weights. The advantage is that weights are typed whereas a list of
  coefficients is not. Do you think you could have a look at LS paths and
  make the user interface for Alcove paths consistent with it? I think this
  would be good for the users!

  Still need to do this part. It's a bit tricky and I don't have much
  time at the moment. When I find some time... I guess in order to
  stay compatible with the old ClassicalCrystalOfAlcovePaths code I have
  to do the same implementation as the LS paths code, instead of just
  changing the parameters by hand.

Look at __classcall_private__ line 121 in littelmann_path.py and __init__ line 158. That allows both inputs and hence you would stay compatible with the old code!

• Why is the method static sign(root) in alcove paths and not in
  root_systems? The same question holds for max_level.

  root_systems already has a is_positive_root method, sign is just
  something convenient for my purposes. Should I rename it to _sign?
  max_level is something specific to the alcove model. Can be renamed to
  _max_level. Since that is part of a private class
  (doesn't get imported into sage) I don't see the point.

Ok, then please make them underscore methods!

FYI, On line 284, TestSuite(C).run() (in the affine case( is now
taking around 150sec, which it didn't used to (I added a #long time). 
Not sure why this is happening.

Yes, I noticed that for me the code also took a long time to run! Perhaps some profiling would be a good idea to see what is taking up so much time.

Best,

Anne

[sagetrac-alubovsky]

comment:7

Hi Anne,

I've removed the 'good_zero_arrows' option, as requested.  
It may be easiest to put back in once sage moves to git, so I
would rather do that.  

The interface is changed to that of LS paths, using the 
'preferred way'.

Requested methods are now private.

I've briefly ran a profiler on TestSuite(C).run() (now line 277).
It seems to be calling the usual processor intensive methods more
than before.  Perhaps it is searching deeper in this affine
crystal?  This may or may not be related, but doc testing for LS
paths code is also taking quite a bit longer than before. 
                                                                                                
I've pushed the changes to combinat, but didn't make a patch.
This ticket already has too many patches ( my fault ).

thanks
Arthur