I think most of the problems here come from the fact that we're using the
wrong objects to do things. For many things, it makes much more sense to
use permutations as a product of cylces and store them this way etc. Maybe
the one that should be used here is more a "PermutationGroupElement" (I
never
sorry some keyboard shortcut has sent the post. I was saying:
def C(*args): #C for "cycle"
return Permutation([ args ])
and then for (1, 2, 3)(4, 5) I type C(1, 2, 3) * C(4, 5). I got very used
to it.
cheers
Pierre
On Thursday, September 11, 2014 2:12:21 PM UTC+2, Pierre wrote:
>
> Hi all,
Hi all,
Here are a few suggestions:
(1) permutations have a to_matrix() method; permuting the rows of M
according to the permutation sigma can be done by
M= M * sigma.to_matrix()
and for the rows:
M= sigma.to_matrix().transpose() * M
Of course there is a debate about the behaviour of to_matr
> I would also be very happy if 1-based permutations were not at the same
> time 0-based words, i.e.:
>
> sage: Permutation([3,2,1])(1)
> 3
> sage: Permutation([3,2,1])[1]
> 2
>
I understand your concern but on the other hand, the following behavior is
good:
sage: Permutation([3,2,1])
[3, 2, 1]
s
Yooo !
> Well, there are two ways to make this consistent:
>
> 1) it being deprecated and removed, eventually.
> i.e. things like Permutation((3,5,7))
> must become Permutation(['(3,5,7)'])
>
> 2) things like Permutation((3,5,7),(1,2),(42,41))
> should be allowed as well.
>
> I'd much pre
On 2014-09-11, 'Martin R' via sage-devel wrote:
> Am Donnerstag, 11. September 2014 01:36:40 UTC+2 schrieb Nils Bruin:
>>
>> On Wednesday, September 10, 2014 10:54:06 AM UTC-7, Nils Bruin wrote:
>>>
>>> On Wednesday, September 10, 2014 10:38:50 AM UTC-7, Nils Bruin wrote:
sage: Permutati
Am Donnerstag, 11. September 2014 01:36:40 UTC+2 schrieb Nils Bruin:
>
> On Wednesday, September 10, 2014 10:54:06 AM UTC-7, Nils Bruin wrote:
>>
>> On Wednesday, September 10, 2014 10:38:50 AM UTC-7, Nils Bruin wrote:
>>>
>>> sage: Permutation([0,1,2])
>>>
>>
> In fact, one CAN see from this lis
On Wednesday, September 10, 2014 10:54:06 AM UTC-7, Nils Bruin wrote:
>
> On Wednesday, September 10, 2014 10:38:50 AM UTC-7, Nils Bruin wrote:
>>
>> sage: Permutation([0,1,2])
>>
>
In fact, one CAN see from this list whether the permutation is 0-based or
1-based, since every element from the do
I'm confirming what Dima and Martin just said: a lot of us need to see
permutations as words. For most of what I do, a permutation of size 4 is
just a word on the letter 1234. And in this case, the fact that it is
1-based or 0-based matters. It mostly matters in terms of printing and
input.
2014-0
Am Mittwoch, 10. September 2014 21:03:36 UTC+2 schrieb Nils Bruin:
>
> On Wednesday, September 10, 2014 11:51:55 AM UTC-7, Martin R wrote:
>>
>> I think that's what PermutationGroup and PermutationGroupElement do.
>
> No:
>
> sage: PermutationGroupElement((2,3,4)).parent()
> Symmetric group of orde
On 2014-09-10, Nils Bruin wrote:
> On Wednesday, September 10, 2014 10:38:50 AM UTC-7, Nils Bruin wrote:
>>
>> sage: Permutation([0,1,2])
>>
>
> aw shoot. The problem is there already, because we're defining permutations
> by *ordered list of images* rather than as a composition of cycles. That
On Wednesday, September 10, 2014 11:51:55 AM UTC-7, Martin R wrote:
>
> I think that's what PermutationGroup and PermutationGroupElement do.
No:
sage: PermutationGroupElement((2,3,4)).parent()
Symmetric group of order 4! as a permutation group
sage: PermutationGroupElement([1,2,3]).parent()
Symme
Am Mittwoch, 10. September 2014 19:54:06 UTC+2 schrieb Nils Bruin:
>
> On Wednesday, September 10, 2014 10:38:50 AM UTC-7, Nils Bruin wrote:
>>
>> sage: Permutation([0,1,2])
>>
>
> aw shoot. The problem is there already, because we're defining
> permutations by *ordered list of images* rather than
On Wednesday, September 10, 2014 10:38:50 AM UTC-7, Nils Bruin wrote:
>
> sage: Permutation([0,1,2])
>
aw shoot. The problem is there already, because we're defining permutations
by *ordered list of images* rather than as a composition of cycles. That
means the base actually is important right f
On Wednesday, September 10, 2014 8:36:47 AM UTC-7, Viviane Pons wrote:
>
> It is not bluff Nathann. And it's no bluff either to say that many many
> valuable people would just stop using Sage if it stopped handling 1-based
> permutations. Sage is a mathematical software and it makes sense that it
It is not bluff Nathann. And it's no bluff either to say that many many
valuable people would just stop using Sage if it stopped handling 1-based
permutations. Sage is a mathematical software and it makes sense that it
should print and accept inputs of the mathematical objects I use the way I
use t
Hello !
> and the
> combinatorial object Permutation which should stay 1-based.
I disagree.
> And yes Nathan, everyone agrees there are some lack of consistency and the
> one you mention about bruhat_inversions and inversions is definitely one.
It is not what I say. What I say is that 1-based
Rather than having Permutation0 and Permutation1, I would rather have an
object which is a 0-based permutation attached with a set on which it's
acting. A classic permutation would be a 0-based permutation acting on
{1,...,n}. The idea is to separate the permutation process itself (which is
classic
On Wednesday, September 10, 2014 2:11:17 PM UTC+1, Nathann Cohen wrote:
>
> 1) Change the current code to handle 0-based AND 1-based permutations; or
> 2) Have two versions of each function
>
IMHO its rather easy. You never really do arithmetic with the indices in
combinatorics as they are just
Just for fun:
sage: Permutation([3,2,1]).inversions() # 0-based
[(1, 2), (1, 3), (2, 3)]
sage: Permutation([3,2,1]).bruhat_inversions() # 0-based
[[0, 1], [1, 2]]
This code is a joke.
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To u
> yes, that's a good idea.
> I also would prefer having Permutation0 and Permutation1 classes,
> and Permutation=Permutation1 by default
> (so that you can just say Permutation=Permutation0 right at the
> beginning of your code, and proceed as you like).
I believe that having two kinds of permutat
On Tue, Sep 09, 2014 at 12:18:40PM -0700, Volker Braun wrote:
> On Tuesday, September 9, 2014 6:07:49 PM UTC+1, Nicolas M. Thiéry wrote:
> >
> > I agree it's not great. But do you have a better proposal?
>
>
> How about being explicit, aka the principle of least astonishment?
> M.permute_column
On 2014-09-10, Nathann Cohen wrote:
>> How about going all the way and permit proper GAP-like syntax for
>> permutations?
>> That is, the preparser should replace
>> (1,2,3)(4,5)(7,8) with Permutation(['(1,2,3)','(4,5)','(7,8)'])
>
> Hmmm... And what about circular permutations ?
OK, I stand cor
> How about going all the way and permit proper GAP-like syntax for
> permutations?
> That is, the preparser should replace
> (1,2,3)(4,5)(7,8) with Permutation(['(1,2,3)','(4,5)','(7,8)'])
Hmmm... And what about circular permutations ?
Should (1,2,3) return a permutation instead of a tuple ? :-
Pretty much anything in parentheses can result in a callable object:
sage: R. = QQ[]
sage: (x+y+1)(2,3)
6
Though we could check for tuples containing only integers, that is a
reasonable regex. Though I'm a bit worried about the whole
preparsing-with-regex approach. The more you layer on top the
On 2014-09-09, Nicolas M. Thiery wrote:
> On Fri, Sep 05, 2014 at 05:00:29PM +0200, Nathann Cohen wrote:
>>> I just had a quick look at it, and the following looks downright
>>scary:
>>It is one of this code's many wonders. Also, note that :
>>sage: Permutation([1,2,3])
>>[1, 2
For the record, I'd rather have both 0 and 1-based permutations act on
matrices in the the natural way (as permutations on an ordered set,
regardless of how that set is written). So there is no need to get rid of
1-based permutations. However, we need to be able to tell 0- and 1-based
permutati
On Tue, Sep 09, 2014 at 10:18:29AM -0700, 'Martin R' via sage-devel wrote:
>But why shouldn't the current behaviour be deprecated?
With this ticket I was aiming for a minimal change. If there is a
consensus that we eventually want to get rid of using 1-based
permutations for row/column matrix
On Tuesday, September 9, 2014 6:07:49 PM UTC+1, Nicolas M. Thiéry wrote:
>
> I agree it's not great. But do you have a better proposal?
How about being explicit, aka the principle of least astonishment?
M.permute_columns(sigma, base=0) with base=1 being the default. In either
case an error is
>
> The ticket only adds a new feature allowing for the natural 0-based
> permutations. Otherwise it does not change the current behavior.
But why shouldn't the current behaviour be deprecated? I think requiring
that the domain is 0..n-1 (is possible, with a check) would be much better.
Mart
On Fri, Sep 05, 2014 at 07:58:30AM -0700, Dima Pasechnik wrote:
>I just had a quick look at it, and the following looks downright scary:
>+For backward compatibility, if a permutation group element
>+acts on the integers `\{1,\ldots,n\}` or a subset thereof,
>
On Fri, Sep 05, 2014 at 05:00:29PM +0200, Nathann Cohen wrote:
>> I just had a quick look at it, and the following looks downright
>scary:
>It is one of this code's many wonders. Also, note that :
>sage: Permutation([1,2,3])
>[1, 2, 3]
>sage: Permutation((1,2,3))
>[2, 3,
>
> If there are no objections to the former, I can probably provide an
> implementaion...
To me making it handle Permutation((1,2,3),(4,5,6)) still has the major
problem of making a difference between Permutation((1,2,3)) and
Permutation([1,2,3]) If a permutation is a list of cycles, le
On 2014-09-07, Travis Scrimshaw wrote:
>
>
>> I never said that, or at least I didn't mean anything like this.
>> I meant to say that it is insane to have a special
>> kind of imput for cyclic permutations:
>>
>> Permutation((1,2,3))
>>
>> while not having anything like
>>
>> Permutation((1
I understand that you would expect the same result when calling a function
on a list and on a tuple. I'm still not sure it needs to be changed: what
you call a bug is obviously a feature for many people.
And nevertheless, what I don't see is why you would expect the same
behaviour when calling ()
2014-09-08 8:07 UTC+02:00, Nathann Cohen :
>> When Sage does something different than what I expect, I look at the doc
>> instead of wondering why it's different
>
> When a list becomes a tuple and all of a sudden a 10 lines functions (that
> calls other functions) returns wrong answers I swear tha
> When Sage does something different than what I expect, I look at the doc
> instead of wondering why it's different
When a list becomes a tuple and all of a sudden a 10 lines functions (that
calls other functions) returns wrong answers I swear that you don't. Come
on Travis open your eyes, this t
>
>
> If one looks at the documentation because an exception is raised then
> there is no problem. The problem occurs when the user expects
> something and Sage does something else, without any error/exception.
>
> THIS is what costs time. The special notation for the cycle
> permutation, this
>I believe in well-documented functions/methods and examples, and the
> first thing I teach people about functions/methods is to look at the
> documentation (which tells you that giving it two arguments is not right).
> There are many functions/methods/classes where I look at the doc when I get
> I never said that, or at least I didn't mean anything like this.
> I meant to say that it is insane to have a special
> kind of imput for cyclic permutations:
>
> Permutation((1,2,3))
>
> while not having anything like
>
> Permutation((1,2,3)(4,5))
>
> In fact, you'd think ',' will do th
Hi there!
Do I understand correctly, that this patch only concerns how permutations
act on matrices, and that this is defined in the matrix class?
If so, I think that I wouldn't expect "standard permutations" (i.e.,
permutations of 1,...,n) to work - unless of course there is a matrix class
wi
On 2014-09-06, Travis Scrimshaw wrote:
>
>>
>> Yes, I must agree that in Pythonic world
>> sage: Permutation((1,2,3))
>>
>
>
> must be equal to
>> sage: Permutation([1,2,3])
>>
>
>
> And if you mean the cyclic permutation (1,2,3) this should be
>> sage: Permutation([(1,2,3)])
>
>
> So to
>
> Yes, I must agree that in Pythonic world
> sage: Permutation((1,2,3))
>
must be equal to
> sage: Permutation([1,2,3])
>
And if you mean the cyclic permutation (1,2,3) this should be
> sage: Permutation([(1,2,3)])
So to be pythonic, because a tuple should be the same as a list by
>
> Also, I agree Nathan has a point with the cycle notation. It shouln't be a
> single cycle but a list. There is still the problem of backward compatibily.
>
I don't consider that we have to stay backward-compatible with past bugs.
But we can have the usual 1-year 'deprecationwarning' whenever an
Le 6 sept. 2014 11:41, "Volker Braun" a écrit :
>
> I'd just write two different classes for permutations. The underlying
bit-twiddling is different but various high-level structures can be
inherited to both. At the end of the day the permutation should be defined
how it acts on an ordered contain
On 2014-09-05, Viviane Pons wrote:
> The Permutation0 might be a good idea, I don't know... It wouldn't change
> the tuple vs. list thing which is used to distinguish between the cycle
> notation and the word notation.
>
> I agree some of the syntax could be improved. But I do think backward
> com
I'd just write two different classes for permutations. The underlying
bit-twiddling is different but various high-level structures can be
inherited to both. At the end of the day the permutation should be defined
how it acts on an ordered container, regardless of whether the container is
indexe
Hello,
In GAP everything is coherent: permutations are based on 1..n and
arrays start at 1. Note that, in the background, permutations are
stored as a C array of ints on 0..n-1. But the C code is inaccesible
from the console and everything is nice from both the programmer and
user point of views.
2014-09-06 10:06 UTC+01:00, Dima Pasechnik :
> OK, sorry, perhaps, I am too used to GAP, which allows things like
> a:=(1,2)(3,4);
> b:=(3,4,5);
GAP is very cool to work with permutations. But this is not possible
to be as smart in Sage as (1,2,3) is a tuple.
> Yes, I must agree that in Pythonic
On 2014-09-06, Nathann Cohen wrote:
> Yo !
>
>> sage: Permutation([1,2,3])
>> > [1, 2, 3]
>> > sage: Permutation((1,2,3))
>> > [2, 3, 1]
>>
>> this actually makes perfect sense for someone with some
>> group theory background.
>> (array notation vs cyclic notation)
>>
>
> I will repeat it f
Yo !
> sage: Permutation([1,2,3])
> > [1, 2, 3]
> > sage: Permutation((1,2,3))
> > [2, 3, 1]
>
> this actually makes perfect sense for someone with some
> group theory background.
> (array notation vs cyclic notation)
>
I will repeat it for as long as people will ignore it, but NO it does
> So how about making it explicit, have separate Permutation and Permutation0
> (instead of tuple vs list). They can share most of the backend, its just a
> slightly different set that they operate on. In Code, you just call sigma =
> Permutation0(sigma) on user input in the beginning to convert
> The Permutation0 might be a good idea, I don't know... It wouldn't change the
> tuple vs. list thing which is used to distinguish between the cycle notation
> and the word notation.
The cycle notation is incorrect too, as a permutation is a collection
of cycles. It also removes the need to dis
On Fri, Sep 5, 2014 at 5:48 PM, Viviane Pons wrote:
> The Permutation0 might be a good idea, I don't know... It wouldn't change
> the tuple vs. list thing which is used to distinguish between the cycle
> notation and the word notation.
>
> I agree some of the syntax could be improved. But I do thi
The Permutation0 might be a good idea, I don't know... It wouldn't change
the tuple vs. list thing which is used to distinguish between the cycle
notation and the word notation.
I agree some of the syntax could be improved. But I do think backward
compatibility is important. It's really annoying w
On 2014-09-05, Nathann Cohen wrote:
>> I just had a quick look at it, and the following looks downright scary:
>
> It is one of this code's many wonders. Also, note that :
>
> sage: Permutation([1,2,3])
> [1, 2, 3]
> sage: Permutation((1,2,3))
> [2, 3, 1]
this actually makes perfect sense for som
The whole 0 vs. 1 based permutations (Python vs. Matlab :-) is always
confusing. And there is good reason and history in both conventions, so we
should IMHO accept that we'll have to live with it. Its not something that
can be solved satisfactorily by trying to guess the user's intentions, you
> And I must add that even so it is annoying for code, we do need the
> 1-starting permutations. All the combinatorists I know do not even think a
> permutation can start at 0. It makes things more complicated for us and we
> need to put extra care in code and documentation but we do need to print
On Fri, Sep 5, 2014 at 11:00 AM, Nathann Cohen wrote:
>> I just had a quick look at it, and the following looks downright scary:
>
> It is one of this code's many wonders. Also, note that :
>
> sage: Permutation([1,2,3])
> [1, 2, 3]
> sage: Permutation((1,2,3))
> [2, 3, 1]
>
> I hate that code.
A
Your last example makes petgect sense in terms of mathematics:
the first one is a petmutation as a word and the second one is a
permutation as a group element. We need BOTH and we need both to be simple.
The diff between brackets and parenthesis is quite natural AND consistent
with mathematic notat
> I just had a quick look at it, and the following looks downright scary:
It is one of this code's many wonders. Also, note that :
sage: Permutation([1,2,3])
[1, 2, 3]
sage: Permutation((1,2,3))
[2, 3, 1]
I hate that code.
Nathann
--
You received this message because you are subscribed to the
I just had a quick look at it, and the following looks downright scary:
+For backward compatibility, if a permutation group element
+acts on the integers `\{1,\ldots,n\}` or a subset thereof,
+the columns are considered as being numbered from `1`::
+
+
>
> Permutation groups used to only handle permutations of 1,..n, and the
> methods permute_rows and friends of matrices coped with this with an
> ugly and potentially confusing shift by 1.
EVERYBODY is using those -1 and +1 everywhere. Those 1-based permutations
are just hell for whoever use
63 matches
Mail list logo
