[sage-combinat-devel] Re: StandardTableaux broken

2013-10-15 Thread Jean-Yves Thibon 


Le mardi 15 octobre 2013 16:23:14 UTC+2, Jean-Yves Thibon a écrit :
>
>
>
>
> sage: tt=StandardTableaux(4)
>
> tt.list() hangs, and that's why:
>
> sage: tt[1]
> [[1, 2, 3, 4]]
> sage: tt[2]
> [[1, 2, 3, 4]]
> sage: tt[3]
> [[1, 2, 3, 4]]
> sage: 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: StandardTableaux broken

2013-10-15 Thread Frédéric Chapoton 
Salut Jean-Yves

chez moi, je n'ai pas ton problème non plus

quelle version de sage tu as ? tape "version()" pour voir

tu peux me telephoner au boulot si tu veux (voir mon tel sur 
http://math.univ-lyon1.fr/~chapoton/)

Fred

Le mardi 15 octobre 2013 16:23:14 UTC+2, Jean-Yves Thibon a écrit :
>
>
>
>
> sage: tt=StandardTableaux(4)
>
> tt.list() hangs, and that's why:
>
> sage: tt[1]
> [[1, 2, 3, 4]]
> sage: tt[2]
> [[1, 2, 3, 4]]
> sage: tt[3]
> [[1, 2, 3, 4]]
> sage: 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: StandardTableaux broken

2013-10-15 Thread Jean-Yves Thibon 
Salut Fred,

J'ai la dernière (5.12). La précédente ne compilait pas sur ma nouvelle 
machine (un mac).
Je viens juste de la compiler et d'installer combinat ...

Le mardi 15 octobre 2013 16:49:35 UTC+2, Frédéric Chapoton a écrit :
>
> Salut Jean-Yves
>
> chez moi, je n'ai pas ton problème non plus
>
> quelle version de sage tu as ? tape "version()" pour voir
>
> tu peux me telephoner au boulot si tu veux (voir mon tel sur 
> http://math.univ-lyon1.fr/~chapoton/)
>
> Fred
>
> Le mardi 15 octobre 2013 16:23:14 UTC+2, Jean-Yves Thibon a écrit :
>>
>>
>>
>>
>> sage: tt=StandardTableaux(4)
>>
>> tt.list() hangs, and that's why:
>>
>> sage: tt[1]
>> [[1, 2, 3, 4]]
>> sage: tt[2]
>> [[1, 2, 3, 4]]
>> sage: tt[3]
>> [[1, 2, 3, 4]]
>> sage: 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: StandardTableaux broken

2013-10-16 Thread Andrew Mathas 
Sorry, Jean-Yves is correct: with the **full** queue applied 
StandardTableaux was broken.

This was my fault and it is now fixed:
┌┐
│ Sage Version 5.12, Release Date: 2013-10-07│
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for help.│
└┘
sage: StandardTableaux(4)[:]
[[[1, 2, 3, 4]],
 [[1, 3, 4], [2]],
 [[1, 2, 4], [3]],
 [[1, 2, 3], [4]],
 [[1, 3], [2, 4]],
 [[1, 2], [3, 4]],
 [[1, 4], [2], [3]],
 [[1, 3], [2], [4]],
 [[1, 2], [3], [4]],
 [[1], [2], [3], [4]]]
On the plus side, there is a slight speed up when running through the list 
of all standard tableaux.

Jean-Yves, to fix your version of sage just type: 
sage -combinat update
from the shell.

Andrew


On Tuesday, 15 October 2013 16:53:59 UTC+2, Jean-Yves Thibon wrote:
>
> Salut Fred,
>
> J'ai la dernière (5.12). La précédente ne compilait pas sur ma nouvelle 
> machine (un mac).
> Je viens juste de la compiler et d'installer combinat ...
>
> Le mardi 15 octobre 2013 16:49:35 UTC+2, Frédéric Chapoton a écrit :
>>
>> Salut Jean-Yves
>>
>> chez moi, je n'ai pas ton problème non plus
>>
>> quelle version de sage tu as ? tape "version()" pour voir
>>
>> tu peux me telephoner au boulot si tu veux (voir mon tel sur 
>> http://math.univ-lyon1.fr/~chapoton/)
>>
>> Fred
>>
>> Le mardi 15 octobre 2013 16:23:14 UTC+2, Jean-Yves Thibon a écrit :
>>>
>>>
>>>
>>>
>>> sage: tt=StandardTableaux(4)
>>>
>>> tt.list() hangs, and that's why:
>>>
>>> sage: tt[1]
>>> [[1, 2, 3, 4]]
>>> sage: tt[2]
>>> [[1, 2, 3, 4]]
>>> sage: tt[3]
>>> [[1, 2, 3, 4]]
>>> sage: 
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: StandardTableaux broken

2013-10-16 Thread Jean-Yves Thibon 
OK, thanks. It works now.
But new problems arise. Now that I can get my hands on standard tableaux, I 
call a function written a few months ago,
which uses t.descents(). It does not work anymore, the output of t.descents 
has changed type
in the meantime, and the doc mentions 


   Warning: This is not to be confused with the descents of a standard
 tableau.

 This leaves me voiceless ...


Le mercredi 16 octobre 2013 16:35:25 UTC+2, Andrew Mathas a écrit :
>
> Sorry, Jean-Yves is correct: with the **full** queue applied 
> StandardTableaux was broken.
>
> This was my fault and it is now fixed:
> ┌┐
> │ Sage Version 5.12, Release Date: 2013-10-07│
> │ Type "notebook()" for the browser-based notebook interface.│
> │ Type "help()" for help.│
> └┘
> sage: StandardTableaux(4)[:]
> [[[1, 2, 3, 4]],
>  [[1, 3, 4], [2]],
>  [[1, 2, 4], [3]],
>  [[1, 2, 3], [4]],
>  [[1, 3], [2, 4]],
>  [[1, 2], [3, 4]],
>  [[1, 4], [2], [3]],
>  [[1, 3], [2], [4]],
>  [[1, 2], [3], [4]],
>  [[1], [2], [3], [4]]]
> On the plus side, there is a slight speed up when running through the list 
> of all standard tableaux.
>
> Jean-Yves, to fix your version of sage just type: 
> sage -combinat update
> from the shell.
>
> Andrew
>
>
> On Tuesday, 15 October 2013 16:53:59 UTC+2, Jean-Yves Thibon wrote:
>>
>> Salut Fred,
>>
>> J'ai la dernière (5.12). La précédente ne compilait pas sur ma nouvelle 
>> machine (un mac).
>> Je viens juste de la compiler et d'installer combinat ...
>>
>> Le mardi 15 octobre 2013 16:49:35 UTC+2, Frédéric Chapoton a écrit :
>>>
>>> Salut Jean-Yves
>>>
>>> chez moi, je n'ai pas ton problème non plus
>>>
>>> quelle version de sage tu as ? tape "version()" pour voir
>>>
>>> tu peux me telephoner au boulot si tu veux (voir mon tel sur 
>>> http://math.univ-lyon1.fr/~chapoton/)
>>>
>>> Fred
>>>
>>> Le mardi 15 octobre 2013 16:23:14 UTC+2, Jean-Yves Thibon a écrit :




 sage: tt=StandardTableaux(4)

 tt.list() hangs, and that's why:

 sage: tt[1]
 [[1, 2, 3, 4]]
 sage: tt[2]
 [[1, 2, 3, 4]]
 sage: tt[3]
 [[1, 2, 3, 4]]
 sage: 



-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: StandardTableaux broken

2013-10-16 Thread Andrew Mathas 
This seems to come from the patch http://trac.sagemath.org/ticket/7983 
which was merged in 5.12.

Perhaps what you want is now given by standard_descents() which is included 
in the same patch:

sage: StandardTableau( [[1,3,4],[2,5]] ).standard_descents()
[1, 4]
sage: StandardTableau( [[1,2],[3,4]] ).standard_descents()
[2]
sage: StandardTableau( [[1,2,5],[3,4],[6,7],[8],[9]] ).standard_descents()
[2, 5, 7, 8]
sage: StandardTableau( [] ).standard_descents()
[]

Andrew

On Wednesday, 16 October 2013 17:51:11 UTC+2, Jean-Yves Thibon wrote:
>
> OK, thanks. It works now.
> But new problems arise. Now that I can get my hands on standard tableaux, 
> I call a function written a few months ago,
> which uses t.descents(). It does not work anymore, the output of 
> t.descents has changed type
> in the meantime, and the doc mentions 
>
>
>Warning: This is not to be confused with the descents of a standard
>  tableau.
>
>  This leaves me voiceless ...
>
>
> Le mercredi 16 octobre 2013 16:35:25 UTC+2, Andrew Mathas a écrit :
>>
>> Sorry, Jean-Yves is correct: with the **full** queue applied 
>> StandardTableaux was broken.
>>
>> This was my fault and it is now fixed:
>> ┌┐
>> │ Sage Version 5.12, Release Date: 2013-10-07│
>> │ Type "notebook()" for the browser-based notebook interface.│
>> │ Type "help()" for help.│
>> └┘
>> sage: StandardTableaux(4)[:]
>> [[[1, 2, 3, 4]],
>>  [[1, 3, 4], [2]],
>>  [[1, 2, 4], [3]],
>>  [[1, 2, 3], [4]],
>>  [[1, 3], [2, 4]],
>>  [[1, 2], [3, 4]],
>>  [[1, 4], [2], [3]],
>>  [[1, 3], [2], [4]],
>>  [[1, 2], [3], [4]],
>>  [[1], [2], [3], [4]]]
>> On the plus side, there is a slight speed up when running through the 
>> list of all standard tableaux.
>>
>> Jean-Yves, to fix your version of sage just type: 
>> sage -combinat update
>> from the shell.
>>
>> Andrew
>>
>>
>> On Tuesday, 15 October 2013 16:53:59 UTC+2, Jean-Yves Thibon wrote:
>>>
>>> Salut Fred,
>>>
>>> J'ai la dernière (5.12). La précédente ne compilait pas sur ma nouvelle 
>>> machine (un mac).
>>> Je viens juste de la compiler et d'installer combinat ...
>>>
>>> Le mardi 15 octobre 2013 16:49:35 UTC+2, Frédéric Chapoton a écrit :

 Salut Jean-Yves

 chez moi, je n'ai pas ton problème non plus

 quelle version de sage tu as ? tape "version()" pour voir

 tu peux me telephoner au boulot si tu veux (voir mon tel sur 
 http://math.univ-lyon1.fr/~chapoton/)

 Fred

 Le mardi 15 octobre 2013 16:23:14 UTC+2, Jean-Yves Thibon a écrit :
>
>
>
>
> sage: tt=StandardTableaux(4)
>
> tt.list() hangs, and that's why:
>
> sage: tt[1]
> [[1, 2, 3, 4]]
> sage: tt[2]
> [[1, 2, 3, 4]]
> sage: tt[3]
> [[1, 2, 3, 4]]
> sage: 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-16 Thread Darij Grinberg 
Hello Jean-Yves, hello Andrew,

I guess I should have something to say about this but I don't really
understand what is happening. When I wrote the #7983 patch, I was
being annoyed by the fact that there was no method on the Tableaux
class computing what everyone in combinatorics calls the descents,
whereas the descents() method on tableaux was computing something
rather unrelated (that, moreover, depends only on the shape if the
tableau is semistandard). I suspect the descents() method was some
kind of helper function for Jack or H-L related code. Anyway, I
decided to rename the old descents() method into a less ambiguous name
and to make descents() compute the actual descents. But I've quickly
got talked out of this, as this would deprecate some userbase code, so
instead I added a standard_descents() method and left descents()
untouched (only adding the warning to its doc). I was working on
sage-main all the time.

Now, Jean-Yves (who, as far as I understand, has been using
sage-combinat) is saying he has been using descents() all the time and
since he is talking about standard tableaux, I assume that function
has been computing the actual descents rather than whatever it has
been computing on sage-main. Does this mean that the descents()
function on sage-combinat has been doing something completely
different from that on sage-main all the time before my #7983 patch?
That someone had done what I first had in mind (rename the old
descents() and reuse the name for the actual descents) long ago, and
now that my #7983 got merged in, the roles have switched?

Either way, sorry for contributing to this muckup and thanks a lot for
any help in understanding it.

  Best regards,
  Darij

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-16 Thread Andrew Mathas 
Hi Darij,

I've not yet needed descent sets of tableaux in sage so I don't know what 
the code did previously or what it does now in this respect. I would hope, 
however, that a descents method for tableaux would return the descent set 
of a tableau, so if you have ensured that this is now happening I think 
that's great!

Andrew

On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote:
>
> Hello Jean-Yves, hello Andrew, 
>
> I guess I should have something to say about this but I don't really 
> understand what is happening. When I wrote the #7983 patch, I was 
> being annoyed by the fact that there was no method on the Tableaux 
> class computing what everyone in combinatorics calls the descents, 
> whereas the descents() method on tableaux was computing something 
> rather unrelated (that, moreover, depends only on the shape if the 
> tableau is semistandard). I suspect the descents() method was some 
> kind of helper function for Jack or H-L related code. Anyway, I 
> decided to rename the old descents() method into a less ambiguous name 
> and to make descents() compute the actual descents. But I've quickly 
> got talked out of this, as this would deprecate some userbase code, so 
> instead I added a standard_descents() method and left descents() 
> untouched (only adding the warning to its doc). I was working on 
> sage-main all the time. 
>
> Now, Jean-Yves (who, as far as I understand, has been using 
> sage-combinat) is saying he has been using descents() all the time and 
> since he is talking about standard tableaux, I assume that function 
> has been computing the actual descents rather than whatever it has 
> been computing on sage-main. Does this mean that the descents() 
> function on sage-combinat has been doing something completely 
> different from that on sage-main all the time before my #7983 patch? 
> That someone had done what I first had in mind (rename the old 
> descents() and reuse the name for the actual descents) long ago, and 
> now that my #7983 got merged in, the roles have switched? 
>
> Either way, sorry for contributing to this muckup and thanks a lot for 
> any help in understanding it. 
>
>   Best regards, 
>   Darij 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-16 Thread Darij Grinberg 
Hi Andrew,

On Wed, Oct 16, 2013 at 4:07 PM, Andrew Mathas
 wrote:
> I've not yet needed descent sets of tableaux in sage so I don't know what
> the code did previously or what it does now in this respect. I would hope,
> however, that a descents method for tableaux would return the descent set of
> a tableau, so if you have ensured that this is now happening I think that's
> great!

I have not, because the method was already doing something different
(namely, to quote the doc, "Return a list of the cells ``(i,j)`` such
that ``self[i][j] > self[i-1][j]``", which means listing all cells in
the tableau beneath its first row if the tableau is semistandard), and
I got told not to change this. So I implemented the thing anyone would
expect from a descents() method as the standard_descents() method on
the StandardTableaux class.

Maybe the mantra of downwards compatibility isn't always the right thing...

  Best regards,
  Darij

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-16 Thread Jean-Yves Thibon 
Hi Darij,


I still have a sage-5.4.1 with all combinat patches up to december 2012 on 
another machine, and t.descents()
does what I expect. I admit that "descents" is a bad name for this (these 
are the descents of the inverse
permutation of the row reading in French convention, in French we use 
"reculs" ( = recoils, or backsteps),
but it is traditional to use "descents" in English.

Btw, the name "major index" comes from the military rank of McMahon (Foata 
and Schutzenberger called it "the major's index") ,
so there is only one "major index" 

All the best,
Jean-Yves 

Le mercredi 16 octobre 2013 22:07:38 UTC+2, Andrew Mathas a écrit :
>
> Hi Darij,
>
> I've not yet needed descent sets of tableaux in sage so I don't know what 
> the code did previously or what it does now in this respect. I would hope, 
> however, that a descents method for tableaux would return the descent set 
> of a tableau, so if you have ensured that this is now happening I think 
> that's great!
>
> Andrew
>
> On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote:
>>
>> Hello Jean-Yves, hello Andrew, 
>>
>> I guess I should have something to say about this but I don't really 
>> understand what is happening. When I wrote the #7983 patch, I was 
>> being annoyed by the fact that there was no method on the Tableaux 
>> class computing what everyone in combinatorics calls the descents, 
>> whereas the descents() method on tableaux was computing something 
>> rather unrelated (that, moreover, depends only on the shape if the 
>> tableau is semistandard). I suspect the descents() method was some 
>> kind of helper function for Jack or H-L related code. Anyway, I 
>> decided to rename the old descents() method into a less ambiguous name 
>> and to make descents() compute the actual descents. But I've quickly 
>> got talked out of this, as this would deprecate some userbase code, so 
>> instead I added a standard_descents() method and left descents() 
>> untouched (only adding the warning to its doc). I was working on 
>> sage-main all the time. 
>>
>> Now, Jean-Yves (who, as far as I understand, has been using 
>> sage-combinat) is saying he has been using descents() all the time and 
>> since he is talking about standard tableaux, I assume that function 
>> has been computing the actual descents rather than whatever it has 
>> been computing on sage-main. Does this mean that the descents() 
>> function on sage-combinat has been doing something completely 
>> different from that on sage-main all the time before my #7983 patch? 
>> That someone had done what I first had in mind (rename the old 
>> descents() and reuse the name for the actual descents) long ago, and 
>> now that my #7983 got merged in, the roles have switched? 
>>
>> Either way, sorry for contributing to this muckup and thanks a lot for 
>> any help in understanding it. 
>>
>>   Best regards, 
>>   Darij 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-16 Thread Darij Grinberg 
Hi Jean-Yves and everyone,

OK, so it seems that some patch on the sage-combinat queue as of
sage-5.4.1 solved the descents() problem in a more radical way than my
sage-main patch. When my patch got merged into sage-main, the
sage-combinat page would no longer apply, and so descents() once again
became the old weird faux-descents function, while the correct
descents function was now named standard_descents().

I wish I could confirm this but there seems to be no way to see the
sage-combinat patches without being on the queue, let alone to see the
old patches that are no longer in the queue.

Either way, we should think about descents() when we rewrite tableau.py.

  Best regards,
  Darij

On Thu, Oct 17, 2013 at 2:06 AM, Jean-Yves Thibon  wrote:
> Hi Darij,
>
>
> I still have a sage-5.4.1 with all combinat patches up to december 2012 on
> another machine, and t.descents()
> does what I expect. I admit that "descents" is a bad name for this (these
> are the descents of the inverse
> permutation of the row reading in French convention, in French we use
> "reculs" ( = recoils, or backsteps),
> but it is traditional to use "descents" in English.
>
> Btw, the name "major index" comes from the military rank of McMahon (Foata
> and Schutzenberger called it "the major's index") ,
> so there is only one "major index" 
>
> All the best,
> Jean-Yves
>
> Le mercredi 16 octobre 2013 22:07:38 UTC+2, Andrew Mathas a écrit :
>>
>> Hi Darij,
>>
>> I've not yet needed descent sets of tableaux in sage so I don't know what
>> the code did previously or what it does now in this respect. I would hope,
>> however, that a descents method for tableaux would return the descent set of
>> a tableau, so if you have ensured that this is now happening I think that's
>> great!
>>
>> Andrew
>>
>> On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote:
>>>
>>> Hello Jean-Yves, hello Andrew,
>>>
>>> I guess I should have something to say about this but I don't really
>>> understand what is happening. When I wrote the #7983 patch, I was
>>> being annoyed by the fact that there was no method on the Tableaux
>>> class computing what everyone in combinatorics calls the descents,
>>> whereas the descents() method on tableaux was computing something
>>> rather unrelated (that, moreover, depends only on the shape if the
>>> tableau is semistandard). I suspect the descents() method was some
>>> kind of helper function for Jack or H-L related code. Anyway, I
>>> decided to rename the old descents() method into a less ambiguous name
>>> and to make descents() compute the actual descents. But I've quickly
>>> got talked out of this, as this would deprecate some userbase code, so
>>> instead I added a standard_descents() method and left descents()
>>> untouched (only adding the warning to its doc). I was working on
>>> sage-main all the time.
>>>
>>> Now, Jean-Yves (who, as far as I understand, has been using
>>> sage-combinat) is saying he has been using descents() all the time and
>>> since he is talking about standard tableaux, I assume that function
>>> has been computing the actual descents rather than whatever it has
>>> been computing on sage-main. Does this mean that the descents()
>>> function on sage-combinat has been doing something completely
>>> different from that on sage-main all the time before my #7983 patch?
>>> That someone had done what I first had in mind (rename the old
>>> descents() and reuse the name for the actual descents) long ago, and
>>> now that my #7983 got merged in, the roles have switched?
>>>
>>> Either way, sorry for contributing to this muckup and thanks a lot for
>>> any help in understanding it.
>>>
>>>   Best regards,
>>>   Darij
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-combinat-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-combinat-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-combinat-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-combinat-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-17 Thread Jean-Yves Thibon 

Well, I have changed "descents" to "standard_descents", but I still have 
problems
with the next two lines of my file. I use robinson_schensted_inverse. I see
that it is deprecated (and certainly it should be, it did not even return a 
correct result
one year ago and I had to patch it). So, deprecated, OK, but it still 
exists,
and returns a different type now. Instead of a word (as it should be) it 
returns
a list of two lists. This is bad. I can easily replace w by w[1]. But this
is still not a word, and my function had to compute its descent composition.
So it fails. I replace w by Word(w[1]). It fails again, as words do not 
have anymore
a descents_composition ... So it is now
Word(w[1]).standard_permutation().descents_composition(),
and so on ...

In summary, a short and very simple code written some 10
moths ago is now totally unusable and needs to be modified at
each single line. 


Le jeudi 17 octobre 2013 08:45:13 UTC+2, darijgrinberg a écrit :
>
> Hi Jean-Yves and everyone, 
>
> OK, so it seems that some patch on the sage-combinat queue as of 
> sage-5.4.1 solved the descents() problem in a more radical way than my 
> sage-main patch. When my patch got merged into sage-main, the 
> sage-combinat page would no longer apply, and so descents() once again 
> became the old weird faux-descents function, while the correct 
> descents function was now named standard_descents(). 
>
> I wish I could confirm this but there seems to be no way to see the 
> sage-combinat patches without being on the queue, let alone to see the 
> old patches that are no longer in the queue. 
>
> Either way, we should think about descents() when we rewrite tableau.py. 
>
>   Best regards, 
>   Darij 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-17 Thread Andrew Mathas 
On Thursday, 17 October 2013 09:36:41 UTC+2, Jean-Yves Thibon wrote:
>
> *snip*
>
> In summary, a short and very simple code written some 10
> moths ago is now totally unusable and needs to be modified at
> each single line. 
>

Hi Jean-Yves,

I guess that the short (but harsh) answer is that if you have code which 
relies upon some one else's code which is in the queue, but which is not 
yet merged into sage, then there is no guarantee that your code will work 
next year, or even tomorrow. Any code which is merged should still work or, 
at a minimum, it should provide useful error messages to help you sort out 
what is going wrong (but this is only guaranteed in the first year after 
the change). I have certainly had this problem with my own private code and 
with the code that I have languishing in the queue.

As I haven't used (or touched) the methods that you are having issues with 
I don't know whether they were just in the queue or whether they were 
already part of the official sage distribution. If these methods were 
already included in an official release then clearly the review process has 
not worked properly in this instance and you have a legitimate complaint.

Looking at the patch queue, robinson_schensted_inverse was depreciated in 
trac8392 . It seems to 
have been replaced with RSK_inverse which just seems wrong to me: with 
tab-completion I don't see the need for random acronyms, even relatively 
common ones like this one. (This probably just reflects my own 
idiosyncrasies:)

Returning to the question of the descents method, irrespective of whether 
it is backwardly compatible, I think it should the descent set of a tableau 
is what any reasonable algebraic combinatorialist would expect this method 
to return. Anything else is implementation-bug and it should be fixed.

Andrew


-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-17 Thread Anne Schilling 
Hi Darij,

> I wish I could confirm this but there seems to be no way to see the
> sage-combinat patches without being on the queue, let alone to see the
> old patches that are no longer in the queue.

You can browse the source code with the patches applied here

http://combinat.sagemath.org/code/file/tip/sage/

Here you can browse the various patches

http://combinat.sagemath.org/patches/file

Best,

Anne

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-17 Thread Anne Schilling 
Perhaps I can add a couple of words to Andrew's answer:

> I guess that the short (but harsh) answer is that if you have code which 
> relies upon some one else's code which is in the queue, but which is not yet 
> merged into sage, then there is no guarantee that
> your code will work next year, or even tomorrow. Any code which is merged 
> should still work or, at a minimum, it should provide useful error messages 
> to help you sort out what is going wrong (but this
> is only guaranteed in the first year after the change). I have certainly had 
> this problem with my own private code and with the code that I have 
> languishing in the queue.

It might be a misconception that code related to combinatorics is "only" in the
sage-combinat queue. Most code is merged into sage and distributed with each
release of sage. The sage-combinat queue is used to share code that is being
developed among researchers and developers. This code can indeed change any time
(some code might even be experimental). Hence, if you are interested in reliable
code it is better not to apply the sage-combinat queue.

To use only code in sage you can do

hg qpop -a
sage -br

or alternatively change to sage-main.

Also, since the development flow will soon change to git, the sage-combinat 
queue
will most likely disappear soon and/or will be replaced by a git fork or
git branches. This is forced upon us by the move to git, but it is a good
opportunity to change part of our work flow that has not worked so well.
For example, it might be good that under the git framework the linear queue
will change into a much flatter framework (since many patches do not actually 
depend
on each other).

> As I haven't used (or touched) the methods that you are having issues with I 
> don't know whether they were just in the queue or whether they were already 
> part of the official sage distribution. If
> these methods were already included in an official release then clearly the 
> review process has not worked properly in this instance and you have a 
> legitimate complaint.
> 
> Looking at the patch queue, robinson_schensted_inverse was depreciated in 
> trac8392 . It seems to have 
> been replaced with RSK_inverse which just seems
> wrong to me: with tab-completion I don't see the need for random acronyms, 
> even relatively common ones like this one. (This probably just reflects my 
> own idiosyncrasies:)

Part of the deprecations have been reverted in

http://trac.sagemath.org/ticket/15142

Franco, Mike and I had also observed what Andrew just mentioned and asked the
authors to revert part of their changes.

I think the review process might not have worked so well recently. For big 
changes
like this a discussion should be done before completely revamping the
methods that already exist.

> Returning to the question of the descents method, irrespective of whether it 
> is backwardly compatible, I think it should the descent set of a tableau is 
> what any reasonable algebraic combinatorialist
> would expect this method to return. Anything else is implementation-bug and 
> it should be fixed.

I agree.

Best,

Anne

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-17 Thread Travis Scrimshaw 
Hey Andrew and Jean-Yves,


> Looking at the patch queue, robinson_schensted_inverse was depreciated in 
> trac8392 . It seems to 
> have been replaced with RSK_inverse which just seems wrong to me: with 
> tab-completion I don't see the need for random acronyms, even relatively 
> common ones like this one. (This probably just reflects my own 
> idiosyncrasies:)
>

   There is also robinson_schensted_knuth[_inverse] methods in the global 
namespace with #15142 . And to get 
an output as a word, use the output='word' option. Note that the output 
will be an honest word object, not a permutation since non-standard 
permutations can break some of Permutations methods. If it is indeed a 
standard permutation, you can use output='permutation'.

> Well, I have changed "descents" to "standard_descents", but I still have 
> problems
> with the next two lines of my file. I use robinson_schensted_inverse. I see
> that it is deprecated (and certainly it should be, it did not even return 
> a correct result
> one year ago and I had to patch it). So, deprecated, OK, but it still 
> exists,
> and returns a different type now. Instead of a word (as it should be) it 
> returns
> a list of two lists. This is bad. I can easily replace w by w[1]. But this
> is still not a word, and my function had to compute its descent 
> composition.
> So it fails. I replace w by Word(w[1]). It fails again, as words do not 
> have anymore
> a descents_composition ... So it is now
> Word(w[1]).standard_permutation().descents_composition(),
> and so on ...
>
>
   I see two possibilities to simplify this. The first is we add a 
descents_composition() method to words which just calls 
self.standard_permutation().descents_composition() (or perhaps its own 
optimized computation). The second would be to give RSK_inverse a checkargument 
which only checks for standardness if 
True and passes it to permutation if ouput='permutation'. I'm in favor of 
the former.

Best,
Travis


-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: StandardTableaux broken

2013-10-20 Thread Andrew Mathas 
Thanks Anne for the follow-up and my apologies to all for any lack of 
diplomacy in my post.
Andrew

On Thursday, 17 October 2013 18:01:56 UTC+2, Anne Schilling wrote:
>
> Perhaps I can add a couple of words to Andrew's answer: 
>
> > I guess that the short (but harsh) answer is that if you have code which 
> relies upon some one else's code which is in the queue, but which is not 
> yet merged into sage, then there is no guarantee that 
> > your code will work next year, or even tomorrow. Any code which is 
> merged should still work or, at a minimum, it should provide useful error 
> messages to help you sort out what is going wrong (but this 
> > is only guaranteed in the first year after the change). I have certainly 
> had this problem with my own private code and with the code that I have 
> languishing in the queue. 
>
> It might be a misconception that code related to combinatorics is "only" 
> in the 
> sage-combinat queue. Most code is merged into sage and distributed with 
> each 
> release of sage. The sage-combinat queue is used to share code that is 
> being 
> developed among researchers and developers. This code can indeed change 
> any time 
> (some code might even be experimental). Hence, if you are interested in 
> reliable 
> code it is better not to apply the sage-combinat queue. 
>
> To use only code in sage you can do 
>
> hg qpop -a 
> sage -br 
>
> or alternatively change to sage-main. 
>
> Also, since the development flow will soon change to git, the 
> sage-combinat queue 
> will most likely disappear soon and/or will be replaced by a git fork or 
> git branches. This is forced upon us by the move to git, but it is a good 
> opportunity to change part of our work flow that has not worked so well. 
> For example, it might be good that under the git framework the linear 
> queue 
> will change into a much flatter framework (since many patches do not 
> actually depend 
> on each other). 
>
> > As I haven't used (or touched) the methods that you are having issues 
> with I don't know whether they were just in the queue or whether they were 
> already part of the official sage distribution. If 
> > these methods were already included in an official release then clearly 
> the review process has not worked properly in this instance and you have a 
> legitimate complaint. 
> > 
> > Looking at the patch queue, robinson_schensted_inverse was depreciated 
> in trac8392 . It seems 
> to have been replaced with RSK_inverse which just seems 
> > wrong to me: with tab-completion I don't see the need for random 
> acronyms, even relatively common ones like this one. (This probably just 
> reflects my own idiosyncrasies:) 
>
> Part of the deprecations have been reverted in 
>
> http://trac.sagemath.org/ticket/15142 
>
> Franco, Mike and I had also observed what Andrew just mentioned and asked 
> the 
> authors to revert part of their changes. 
>
> I think the review process might not have worked so well recently. For big 
> changes 
> like this a discussion should be done before completely revamping the 
> methods that already exist. 
>
> > Returning to the question of the descents method, irrespective of 
> whether it is backwardly compatible, I think it should the descent set of a 
> tableau is what any reasonable algebraic combinatorialist 
> > would expect this method to return. Anything else is implementation-bug 
> and it should be fixed. 
>
> I agree. 
>
> Best, 
>
> Anne 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.