[Sage] #14881: Some symmetric group algebra modifications
Sage
-----------------------------+----------------------------------------------
Reporter: darij | Owner: tbd
Type: PLEASE CHANGE | Status: new
Priority: major | Milestone: sage-5.12
Component: PLEASE CHANGE | Keywords: permutations, symmetric group algebra, combinat,
Work issues: | Report Upstream: N/A
Reviewers: | Authors: Darij Grinberg
Merged in: | Dependencies:
Stopgaps: |
-----------------------------+----------------------------------------------
The patch as it stands does the following:
1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
both the symmetric group algebra and the Hecke algebra. There is no
theoretical reason not to. They're not very interesting elements, but
algorithms shouldn't mysteriously fail in corner cases.
2) The ``algebra_generators()`` method on a symmetric group algebra with n
being 0 or 1 doesn't throw an error anymore.
3) The ``cpi`` method should now be a lot faster (checked on S_6 and
[3,2,1], where the speedup factor was more than 2).
All changes are in ``symmetric_group_algebra.py``; I have not touched
``permutation.py`` due to Travis' patch.
This one is probably not yet ripe for review, as I am planning some more
work. Originally I was looking over the file to find methods for the two
factors of the Young symmetrizer (one is the sum of all row-preserving
permutations, and the other is the alternating sum of all column-
preserving permutations). Seeing that these methods aren't there, I am
planning to implement them on my own, but I need two things sorted out
beforehand:
First, should they go into ``symmetric_group_algebra.py`` (given that the
elements they construct belong to symmetric group algebras) or to
``partition.py`` (given that their input is a partition)?
Second, I have only now noticed that *Sage is using Herstein's idiotic
left-to-right convention for the product of permutations as default*! I
think the only reason why I have missed this so far is that I haven't been
multiplying permutations very often in the first place. That said, I'm not
sure about this, and I feel sorry for the conjectures I have been
discarding because I thought I was able to produce counterexamples with
Sage. Can we do anything about this clusterfuck or at least document it in
such a way that it can't be missed? I will open another ticket for this
issue once I've done a quick search to see where these multiplications are
being used; I wouldn't be surprised if there are bugs lurking in the code
just because people expected that Sage would use the same conventions as
everyone else (I certainly did when I was messing around with Malvenuto-
Reutenauer). I know about GAP, but part of the reason I've been using Sage
is to not have to put up with crappy syntax.
When I grep for ``PermutationOptions`` and ``permutation_options``, I only
get hits from ``permutation.py`` and ``symmetric_group_algebra.py``, which
suggests that all other files are either oblivious to the semantics of a
product of permutations depending on a global variable, or they just work
around this product method. I'm hoping it's the latter...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, and MATLAB
Sage
Reporter: darij | Owner: sage-combinat
Type: defect | Status: new
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
Dependencies: | Stopgaps:
Changes (by darij):
* owner: tbd => sage-combinat
* type: PLEASE CHANGE => defect
* component: PLEASE CHANGE => combinatorics
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:1>
Sage
Reporter: darij | Owner: sage-combinat
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
Dependencies: | Stopgaps:
Description changed by darij:
Old description:
>
> When I grep for ``PermutationOptions`` and ``permutation_options``, I
> only get hits from ``permutation.py`` and ``symmetric_group_algebra.py``,
> which suggests that all other files are either oblivious to the semantics
> of a product of permutations depending on a global variable, or they just
> work around this product method. I'm hoping it's the latter...
The patch as it stands does the following:
1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
both the symmetric group algebra and the Hecke algebra. There is no
theoretical reason not to. They're not very interesting elements, but
algorithms shouldn't mysteriously fail in corner cases.
2) The ``algebra_generators()`` method on a symmetric group algebra with n
being 0 or 1 doesn't throw an error anymore.
3) The ``cpi`` method should now be a lot faster (checked on S_6 and
[3,2,1], where the speedup factor was more than 2).
All changes are in ``symmetric_group_algebra.py``; I have not touched
``permutation.py`` due to Travis' patch.
This one is probably not yet ripe for review, as I am planning some more
work. Originally I was looking over the file to find methods for the two
factors of the Young symmetrizer (one is the sum of all row-preserving
permutations, and the other is the alternating sum of all column-
preserving permutations). Seeing that these methods aren't there, I am
planning to implement them on my own, but I need two things sorted out
beforehand:
First, should they go into ``symmetric_group_algebra.py`` (given that the
left-to-right convention for the product of permutations as default**! I
multiplying permutations very often in the first place. That said, I'm not
sure about this, and I feel sorry for the conjectures I have been
discarding because I thought I was able to produce counterexamples with
Sage. Can we do anything about this clusterfuck or at least document it in
such a way that it can't be missed? I will open another ticket for this
issue once I've done a quick search to see where these multiplications are
being used; I wouldn't be surprised if there are bugs lurking in the code
just because people expected that Sage would use the same conventions as
everyone else (I certainly did when I was messing around with Malvenuto-
Reutenauer). I know about GAP, but part of the reason I've been using Sage
is to not have to put up with crappy syntax.
When I grep for ``PermutationOptions`` and ``permutation_options``, I only
get hits from ``permutation.py`` and ``symmetric_group_algebra.py``, which
suggests that all other files are either oblivious to the semantics of a
product of permutations depending on a global variable, or they just work
around this product method. I'm hoping it's the latter...
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:2>
Sage
Reporter: darij | Owner: sage-combinat
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
Dependencies: | Stopgaps:
Description changed by darij:
Old description:
>
> 1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
> both the symmetric group algebra and the Hecke algebra. There is no
> theoretical reason not to. They're not very interesting elements, but
> algorithms shouldn't mysteriously fail in corner cases.
>
> 2) The ``algebra_generators()`` method on a symmetric group algebra with
> n being 0 or 1 doesn't throw an error anymore.
>
> 3) The ``cpi`` method should now be a lot faster (checked on S_6 and
> [3,2,1], where the speedup factor was more than 2).
>
> All changes are in ``symmetric_group_algebra.py``; I have not touched
> ``permutation.py`` due to Travis' patch.
>
> This one is probably not yet ripe for review, as I am planning some more
> work. Originally I was looking over the file to find methods for the two
> factors of the Young symmetrizer (one is the sum of all row-preserving
> permutations, and the other is the alternating sum of all column-
> preserving permutations). Seeing that these methods aren't there, I am
> planning to implement them on my own, but I need two things sorted out
> beforehand:
>
> First, should they go into ``symmetric_group_algebra.py`` (given that the
>
> left-to-right convention for the product of permutations as default**! I
> been multiplying permutations very often in the first place. That said,
> I'm not sure about this, and I feel sorry for the conjectures I have been
> discarding because I thought I was able to produce counterexamples with
> Sage. Can we do anything about this clusterfuck or at least document it
> in such a way that it can't be missed? I will open another ticket for
> this issue once I've done a quick search to see where these
> multiplications are being used; I wouldn't be surprised if there are bugs
> lurking in the code just because people expected that Sage would use the
> same conventions as everyone else (I certainly did when I was messing
>
> When I grep for ``PermutationOptions`` and ``permutation_options``, I
> only get hits from ``permutation.py`` and ``symmetric_group_algebra.py``,
> which suggests that all other files are either oblivious to the semantics
> of a product of permutations depending on a global variable, or they just
> work around this product method. I'm hoping it's the latter...
The patch as it stands does the following:
1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
both the symmetric group algebra and the Hecke algebra. There is no
theoretical reason not to. They're not very interesting elements, but
algorithms shouldn't mysteriously fail in corner cases.
2) The ``algebra_generators()`` method on a symmetric group algebra with n
being 0 or 1 doesn't throw an error anymore.
3) The ``cpi`` method should now be a lot faster (checked on S_6 and
[3,2,1], where the speedup factor was more than 2).
All changes are in ``symmetric_group_algebra.py``; I have not touched
``permutation.py`` due to Travis' patch.
This one is probably not yet ripe for review, as I am planning some more
work. Originally I was looking over the file to find methods for the two
factors of the Young symmetrizer (one is the sum of all row-preserving
permutations, and the other is the alternating sum of all column-
preserving permutations). Seeing that these methods aren't there, I am
planning to implement them on my own, but I need two things sorted out
beforehand:
First, should they go into ``symmetric_group_algebra.py`` (given that the
left-to-right convention for the product of permutations as default**! I
multiplying permutations very often in the first place. That said, I'm not
sure about this, and I feel sorry for the conjectures I have been
discarding because I thought I was able to produce counterexamples with
Sage. Can we do anything about this clusterfuck or at least document it in
such a way that it can't be missed? I will open another ticket for this
issue once I've done a quick search to see where these multiplications are
being used; I wouldn't be surprised if there are bugs lurking in the code
just because people expected that Sage would use the same conventions as
When I grep for ``PermutationOptions`` and ``permutation_options``, I only
get hits from ``permutation.py`` and ``symmetric_group_algebra.py``, which
suggests that all other files are either oblivious to the semantics of a
product of permutations depending on a global variable, or they just work
around this product method. I'm hoping it's the latter...
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:3>
Sage
Reporter: darij | Owner: sage-combinat
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
Dependencies: | Stopgaps:
Old description:
> The patch as it stands does the following:
>
> 1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
> both the symmetric group algebra and the Hecke algebra. There is no
> theoretical reason not to. They're not very interesting elements, but
> algorithms shouldn't mysteriously fail in corner cases.
>
> 2) The ``algebra_generators()`` method on a symmetric group algebra with
> n being 0 or 1 doesn't throw an error anymore.
>
> 3) The ``cpi`` method should now be a lot faster (checked on S_6 and
> [3,2,1], where the speedup factor was more than 2).
>
> All changes are in ``symmetric_group_algebra.py``; I have not touched
> ``permutation.py`` due to Travis' patch.
>
> This one is probably not yet ripe for review, as I am planning some more
> work. Originally I was looking over the file to find methods for the two
> factors of the Young symmetrizer (one is the sum of all row-preserving
> permutations, and the other is the alternating sum of all column-
> preserving permutations). Seeing that these methods aren't there, I am
> planning to implement them on my own, but I need two things sorted out
> beforehand:
>
> First, should they go into ``symmetric_group_algebra.py`` (given that the
>
> left-to-right convention for the product of permutations as default**! I
> been multiplying permutations very often in the first place. That said,
> I'm not sure about this, and I feel sorry for the conjectures I have been
> discarding because I thought I was able to produce counterexamples with
> Sage. Can we do anything about this clusterfuck or at least document it
> in such a way that it can't be missed? I will open another ticket for
> this issue once I've done a quick search to see where these
> multiplications are being used; I wouldn't be surprised if there are bugs
> lurking in the code just because people expected that Sage would use the
> crappy syntax.
>
> When I grep for ``PermutationOptions`` and ``permutation_options``, I
> only get hits from ``permutation.py`` and ``symmetric_group_algebra.py``,
> which suggests that all other files are either oblivious to the semantics
> of a product of permutations depending on a global variable, or they just
> work around this product method. I'm hoping it's the latter...
The patch as it stands does the following:
1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
both the symmetric group algebra and the Hecke algebra. There is no
theoretical reason not to. They're not very interesting elements, but
algorithms shouldn't mysteriously fail in corner cases.
2) The ``algebra_generators()`` method on a symmetric group algebra with n
being 0 or 1 doesn't throw an error anymore.
3) The ``cpi`` method should now be a lot faster (checked on S_6 and
[3,2,1], where the speedup factor was more than 2).
All changes are in ``symmetric_group_algebra.py``; I have not touched
``permutation.py`` due to Travis' patch.
This one is probably not yet ripe for review, as I am planning some more
work. Originally I was looking over the file to find methods for the two
factors of the Young symmetrizer (one is the sum of all row-preserving
permutations, and the other is the alternating sum of all column-
preserving permutations). Seeing that these methods aren't there, I am
planning to implement them on my own, but I need two things sorted out
beforehand:
First, should they go into ``symmetric_group_algebra.py`` (given that the
left-to-right convention for the product of permutations as default**! I
multiplying permutations very often in the first place. That said, I'm not
sure about this, and I feel sorry for the conjectures I have been
discarding because I thought I was able to produce counterexamples with
I've done a quick search to see where these multiplications are being
used; I wouldn't be surprised if there are bugs lurking in the code just
because people expected that Sage would use the same conventions as
When I grep for ``PermutationOptions`` and ``permutation_options``, I only
get hits from ``permutation.py`` and ``symmetric_group_algebra.py``, which
suggests that all other files are either oblivious to the semantics of a
product of permutations depending on a global variable, or they just work
around this product method. I'm hoping it's the latter...
--
Comment (by tscrim):
For the multiplication, you can at present set the permutation options (if
you look in the `permutation.py`, it's in there, I forget how its
accessed). However with #14772, this will be a global option accessible by
{{{
Permutations.global_options(mult='r2l') # or 'l2r'
}}}
If the global options in #14772 (which needs another review) isn't well
documented enough, I can add some more documentation on it.
I'd recommend starting to work based on #14772 which should be good to go
now, if you want to work on permutations. Its dependency #14519 is
basically done too, and I'll ask Nicolas to re-review it if he doesn't do
so in a few days.
Best,[[BR]]
Travis
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:4>
Sage
Reporter: darij | Owner: sage-combinat
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
Dependencies: | Stopgaps:
Comment (by darij):
Travis -- thank you for reminding me of #14772 (which happened to fix
another problem I reported today). I'll rebase my patch atop yours in a
couple minutes.
Thanks for cleaning up the global options, but I fear I still don't like
them. This isn't the right ticket for me to rant about them; I'll open a
new one today.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:5>
Sage
Reporter: darij | Owner: sage-combinat
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
--------------------------------------------------------------------+-------
Changes (by darij):
* dependencies: => #14772
Old description:
> The patch as it stands does the following:
>
> 1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
> both the symmetric group algebra and the Hecke algebra. There is no
> theoretical reason not to. They're not very interesting elements, but
> algorithms shouldn't mysteriously fail in corner cases.
>
> 2) The ``algebra_generators()`` method on a symmetric group algebra with
> n being 0 or 1 doesn't throw an error anymore.
>
> 3) The ``cpi`` method should now be a lot faster (checked on S_6 and
> [3,2,1], where the speedup factor was more than 2).
>
> All changes are in ``symmetric_group_algebra.py``; I have not touched
> ``permutation.py`` due to Travis' patch.
>
> This one is probably not yet ripe for review, as I am planning some more
> work. Originally I was looking over the file to find methods for the two
> factors of the Young symmetrizer (one is the sum of all row-preserving
> permutations, and the other is the alternating sum of all column-
> preserving permutations). Seeing that these methods aren't there, I am
> planning to implement them on my own, but I need two things sorted out
> beforehand:
>
> First, should they go into ``symmetric_group_algebra.py`` (given that the
> elements they construct belong to symmetric group algebras) or into
> ``partition.py`` (given that their input is a partition)?
>
> Second, I have only now noticed that **Sage is using Herstein's idiotic
> left-to-right convention for the product of permutations as default**! I
> think the only reason why I have missed this so far is that I haven't
> been multiplying permutations very often in the first place. That said,
> I'm not sure about this, and I feel sorry for the conjectures I have been
> discarding because I thought I was able to produce counterexamples with
> Sage. Can we do anything about this or at least document it in such a way
> that it can't be missed? I will open another ticket for this issue once
> I've done a quick search to see where these multiplications are being
> used; I wouldn't be surprised if there are bugs lurking in the code just
> because people expected that Sage would use the same conventions as
> everyone else in mathematics. I know about GAP, but part of the reason
> I've been using Sage is to not have to put up with crappy syntax.
>
> When I grep for ``PermutationOptions`` and ``permutation_options``, I
> only get hits from ``permutation.py`` and ``symmetric_group_algebra.py``,
> which suggests that all other files are either oblivious to the semantics
> of a product of permutations depending on a global variable, or they just
> work around this product method. I'm hoping it's the latter...
New description:
The patch as it stands does the following:
1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
both the symmetric group algebra and the Hecke algebra. There is no
theoretical reason not to. They're not very interesting elements, but
algorithms shouldn't mysteriously fail in corner cases.
2) The ``algebra_generators()`` method on a symmetric group algebra with n
being 0 or 1 doesn't throw an error anymore.
3) The ``cpi`` method should now be a lot faster (checked on S_6 and
[3,2,1], where the speedup factor was more than 2).
All changes are in ``symmetric_group_algebra.py``; I have not touched
``permutation.py`` due to Travis' patch.
This one is probably not yet ripe for review, as I am planning some more
work. Originally I was looking over the file to find methods for the two
factors of the Young symmetrizer (one is the sum of all row-preserving
permutations, and the other is the alternating sum of all column-
preserving permutations). Seeing that these methods aren't there, I am
planning to implement them on my own, but I need two things sorted out
beforehand:
First, should they go into ``symmetric_group_algebra.py`` (given that the
elements they construct belong to symmetric group algebras) or into
``partition.py`` (given that their input is a partition)?
Second, I have only now noticed that **Sage is using Herstein's idiotic
left-to-right convention for the product of permutations as default**! I
think the only reason why I have missed this so far is that I haven't been
multiplying permutations very often in the first place. That said, I'm not
sure about this, and I feel sorry for the conjectures I have been
discarding because I thought I was able to produce counterexamples with
Sage. Can we do anything about this or at least document it in such a way
that it can't be missed? I will open another ticket for this issue once
I've done a quick search to see where these multiplications are being
used; I wouldn't be surprised if there are bugs lurking in the code just
because people expected that Sage would use the same conventions as
everyone else in mathematics. I know about GAP, but part of the reason
I've been using Sage is to not have to put up with crappy syntax.
When I grep for ``PermutationOptions`` and ``permutation_options``, I only
get hits from ``permutation.py`` and ``symmetric_group_algebra.py``, which
suggests that all other files are either oblivious to the semantics of a
product of permutations depending on a global variable, or they just work
around this product method. I'm hoping it's the latter...
* Apply: [attachment:trac_14881-symmetric_group_algebra_rebased-dg.patch]
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:6>
Sage
Reporter: darij | Owner: sage-combinat
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
--------------------------------------------------------------------+-------
Changes (by darij):
* dependencies: #14772 => 14772
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:7>
Sage
Reporter: darij | Owner: sage-combinat
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
--------------------------------------------------------------------+-------
Changes (by darij):
* dependencies: 14772 => #14772, #14101
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:8>
Sage
Reporter: darij | Owner: sage-combinat
Priority: major | Milestone: sage-5.12
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
--------------------------------------------------------------------+-------
Changes (by darij):
* status: new => needs_review
Old description:
> The patch as it stands does the following:
>
> 1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
> both the symmetric group algebra and the Hecke algebra. There is no
> theoretical reason not to. They're not very interesting elements, but
> algorithms shouldn't mysteriously fail in corner cases.
>
> 2) The ``algebra_generators()`` method on a symmetric group algebra with
> n being 0 or 1 doesn't throw an error anymore.
>
> 3) The ``cpi`` method should now be a lot faster (checked on S_6 and
> [3,2,1], where the speedup factor was more than 2).
>
> All changes are in ``symmetric_group_algebra.py``; I have not touched
> ``permutation.py`` due to Travis' patch.
>
> This one is probably not yet ripe for review, as I am planning some more
> work. Originally I was looking over the file to find methods for the two
> factors of the Young symmetrizer (one is the sum of all row-preserving
> permutations, and the other is the alternating sum of all column-
> preserving permutations). Seeing that these methods aren't there, I am
> planning to implement them on my own, but I need two things sorted out
> beforehand:
>
> First, should they go into ``symmetric_group_algebra.py`` (given that the
> elements they construct belong to symmetric group algebras) or into
> ``partition.py`` (given that their input is a partition)?
>
> Second, I have only now noticed that **Sage is using Herstein's idiotic
> left-to-right convention for the product of permutations as default**! I
> think the only reason why I have missed this so far is that I haven't
> been multiplying permutations very often in the first place. That said,
> I'm not sure about this, and I feel sorry for the conjectures I have been
> discarding because I thought I was able to produce counterexamples with
> Sage. Can we do anything about this or at least document it in such a way
> that it can't be missed? I will open another ticket for this issue once
> I've done a quick search to see where these multiplications are being
> used; I wouldn't be surprised if there are bugs lurking in the code just
> because people expected that Sage would use the same conventions as
> everyone else in mathematics. I know about GAP, but part of the reason
> I've been using Sage is to not have to put up with crappy syntax.
>
> When I grep for ``PermutationOptions`` and ``permutation_options``, I
> only get hits from ``permutation.py`` and ``symmetric_group_algebra.py``,
> which suggests that all other files are either oblivious to the semantics
> of a product of permutations depending on a global variable, or they just
> work around this product method. I'm hoping it's the latter...
>
> * Apply: [attachment:trac_14881-symmetric_group_algebra_rebased-dg.patch]
New description:
**UPDATED and ready for review.** The patch does the following:
1) Allows k = 1 in the construction of the k-th Jucys-Murphy element in
both the symmetric group algebra and the Hecke algebra. There is no
theoretical reason not to. They're not very interesting elements, but
algorithms shouldn't mysteriously fail in corner cases. (Note: I'm
treating k = 1 as a separate case in the Hecke algebra because I want it
to return the 1 of the Hecke algebra, not the int 1.)
2) The ``algebra_generators()`` method on a symmetric group algebra with n
being 0 or 1 doesn't throw an error anymore.
3) The ``cpi`` method should now be a lot faster (checked on S_6 and
[3,2,1], where the speedup factor was more than 2).
4) New methods ``a`` and ``b`` in ``symmetric_group_algebra.py`` allow
computing the sum of the row-preserving permutations and the alternating
sum of the column-preserving permutation of a Young tableau, not just
their product. These methods are not exported by default so as not to
pollute the namespace.
5) A fix in ``tableau.py`` ensures that ``Tableau([]).row_stabilizer()``
behaves as it should. My speed tests are inconclusive, but I don't think
this fix has any noticeable impact on overall speed of tableau
computations. The assumption I added to the documentation was already
needed beforehand; it just wasn't documented.
Issues I'd like the reviewer to look at closely:
A) I removed a "#################### SEGFAULTS ################" comment
after a doctests since that doctest doesn't even run close to segfaulting
(on my machine, that is). If it had a reason to be there, please insert it
back.
B) I don't know what the ``star`` keyword in my methods is for -- I copied
it over from the ``e`` method (which should be similar to ``a`` and ``b``
in various regards), where it was undocumented. Apparently it is used
internally in other methods. If you think I should remove it from my
methods, I will.
C) There are two TODOs which might deserve tickets of their own.
{{{
627 # This all should be over ZZ, not over QQ, but
symmetric group
628 # algebras don't seem to preserve coercion (the one
over ZZ
629 # doesn't coerce into the one over QQ even for the
same n),
630 # and the QQ version of this method is more important,
so let
631 # me stay with QQ.
632 # TODO: Fix this.
}}}
and
{{{
637 # Ugly hack for the case of an empty tableau, due to
the
638 # annoyance of
Permutation(Tableau([]).row_stabilizer()[0])
639 # being [1] rather than [] (which seems to have its
origins in
640 # permutation group code).
}}}
If you agree, I'll open these tickets.
* Apply: [attachment:trac_14881-symmetric_group_algebra_rebased-dg.patch]
====================================================================
The following rant is being kept for reference; it now has a ticket of its
own (#14885) and a sage-devel discussion (
https://groups.google.com/forum/#!topic/sage-devel/tAAb42Edh9o ). The
present ticket changes nothing about it.
Writing this patch made me notice that **Sage is using Herstein's idiotic
left-to-right convention for the product of permutations as default**! I
think the only reason why I have missed this so far is that I haven't been
multiplying permutations very often in the first place. That said, I'm not
sure about this, and I feel sorry for the conjectures I have been
discarding because I thought I was able to produce counterexamples with
Sage. Can we do anything about this or at least document it in such a way
that it can't be missed? I will open another ticket for this issue once
I've done a quick search to see where these multiplications are being
used; I wouldn't be surprised if there are bugs lurking in the code just
because people expected that Sage would use the same conventions as
everyone else in mathematics. I know about GAP, but part of the reason
I've been using Sage is to not have to put up with crappy syntax.
When I grep for ``PermutationOptions`` and ``permutation_options``, I only
get hits from ``permutation.py`` and ``symmetric_group_algebra.py``, which
suggests that all other files are either oblivious to the semantics of a
product of permutations depending on a global variable, or they just work
around this product method. I'm hoping it's the latter...
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:9>
Sage
Reporter: darij | Owner: sage-combinat
Type: defect | Status: needs_review
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
--------------------------------------------------------------------+-------
Comment (by darij):
for the patchbot:
apply trac_14881-symmetric_group_algebra_rebased-dg.patch
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:10>
Sage
Reporter: darij | Owner: sage-combinat
Type: defect | Status: needs_review
Component: combinatorics | Resolution:
Report Upstream: N/A | Reviewers:
Authors: Darij Grinberg | Merged in:
--------------------------------------------------------------------+-------
Comment (by darij):
Sorry, one final update. I've slightly changed my own fix for Jucys-Murphy
in the Hecke algebra, and modernized all errors.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14881#comment:11>