Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 use this class so I don't really know how handy it is). But the permutation object Permutation is more like a combinatorial object that basically is a word with some extra properties. For example, I never use the cycle notation... And for everything I do with permutations, the list notation (and the list structure) is what I want. For me, the list(perm), the perm[i], and the perm(i) all make sense and are useful. Many algorithms on the Permutation object actually use this kind of structure, especially all the "combinatorial maps" that send permutations to other combinatorial objects like Dyck paths, binary trees, tableaux or whatever. Also, you have to keep in mind that this object has already been implemented in a certain way, which is the "list way". I'm not saying it's the good way but many people actually use this and rely on this on their code (especially the perm[i] and perm(i), I myself have tons of code using this). Best Viviane 2014-09-11 14:14 GMT+02:00 Pierre : > 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, >> >> 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_matrix() ; however >> i think the code for matrices should rely on to_matrix(), and then at least >> the conversation would be strictly one about the code for permutations. >> This answers a complain above. >> >> (2) if sigma is a permutation, i don't think sigma[i] should make sense >> at all. This requires the user to appreciate that sigma is implemented as a >> list, which i think is not a good idea. Of course some people (including >> me) want the permutation as a word; why not have a as_word() method, which >> could take a bunch of parameters for shifting (starting from 0 instead of 1 >> for example...) ? >> >> Also, permutations should always print in cycle notation, just like in >> GAP ! It's much easier to read, and drives the user away from the idea that >> the permutation "is" a list. >> >> [By the way, i also don't think sigma(i) should be implemented. The >> permutations in Sage act on the right, so i^sigma, just like in GAP, is >> more logical. This is not a very useful comment as changing the behaviour >> of standard ints is complicated (if possible at all?), and backward >> compatibility is needed.] >> >> (3) in fact i agree that permutations should not be implemented as lists, >> and should be thought of as acting on all integers from 0, as was >> suggested. Would the multiplication be as fast if they were stored as lists >> of cycles? I'm thinking that an implementation as a dictionnary, much like >> a sparse matrix, would be reasonable. >> >> (4) Here's a notation I use when I have a lot of permutation to input >> interactively: >> >> def C(*args) : # C for "cycle" >> >> >> >> >> >> >> >> -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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, > > 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_matrix() ; however i > think the code for matrices should rely on to_matrix(), and then at least > the conversation would be strictly one about the code for permutations. > This answers a complain above. > > (2) if sigma is a permutation, i don't think sigma[i] should make sense at > all. This requires the user to appreciate that sigma is implemented as a > list, which i think is not a good idea. Of course some people (including > me) want the permutation as a word; why not have a as_word() method, which > could take a bunch of parameters for shifting (starting from 0 instead of 1 > for example...) ? > > Also, permutations should always print in cycle notation, just like in GAP > ! It's much easier to read, and drives the user away from the idea that the > permutation "is" a list. > > [By the way, i also don't think sigma(i) should be implemented. The > permutations in Sage act on the right, so i^sigma, just like in GAP, is > more logical. This is not a very useful comment as changing the behaviour > of standard ints is complicated (if possible at all?), and backward > compatibility is needed.] > > (3) in fact i agree that permutations should not be implemented as lists, > and should be thought of as acting on all integers from 0, as was > suggested. Would the multiplication be as fast if they were stored as lists > of cycles? I'm thinking that an implementation as a dictionnary, much like > a sparse matrix, would be reasonable. > > (4) Here's a notation I use when I have a lot of permutation to input > interactively: > > def C(*args) : # C for "cycle" > > > > > > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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_matrix() ; however i think the code for matrices should rely on to_matrix(), and then at least the conversation would be strictly one about the code for permutations. This answers a complain above. (2) if sigma is a permutation, i don't think sigma[i] should make sense at all. This requires the user to appreciate that sigma is implemented as a list, which i think is not a good idea. Of course some people (including me) want the permutation as a word; why not have a as_word() method, which could take a bunch of parameters for shifting (starting from 0 instead of 1 for example...) ? Also, permutations should always print in cycle notation, just like in GAP ! It's much easier to read, and drives the user away from the idea that the permutation "is" a list. [By the way, i also don't think sigma(i) should be implemented. The permutations in Sage act on the right, so i^sigma, just like in GAP, is more logical. This is not a very useful comment as changing the behaviour of standard ints is complicated (if possible at all?), and backward compatibility is needed.] (3) in fact i agree that permutations should not be implemented as lists, and should be thought of as acting on all integers from 0, as was suggested. Would the multiplication be as fast if they were stored as lists of cycles? I'm thinking that an implementation as a dictionnary, much like a sparse matrix, would be reasonable. (4) Here's a notation I use when I have a lot of permutation to input interactively: def C(*args) : # C for "cycle" -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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] sage: list(Permutation([3,2,1])) [3, 2, 1] sage: list(Permutation([3,2,1]))[0] 3 sage: list(Permutation([3,2,1]))[0] == Permutation([3,2,1])[0] True I wouldn't want list(perm) to return something different than the permutation word itself, especially because I want to have: sage: perm = Permutation([3,2,1]) sage: Permutation(list(perm)) == perm True I'm afraid that by "fixing" this, we would just break other things and obtain very annoying behavior in practice. For me the 0-based word is not really a problem. People who want to stay strictly 1-based can use only the call perm(i) and you need perm[i] only when digging inside the structure itself. Best, Viviane -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 prefer 2). Should we hold a formal vote? 2) would make it less inconsistent but then we still have the problem that Permutation([1,2,3]) != Permutation((1,2,3)). So given that: Permutation([(3,5,7),(1,2),(42,41)]) already works I do not find it is very bad if Permutation((3,5,7),(1,2),(42,41)) does not. So I vote for 1). 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 Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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: 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 domain must must occur exactly once,
>> so
>>
>> Permutation([1,2,0]) is a cyclic permutation on the 3 element set {0,1,2}
>> and Permutation([2,3,1]) is a cyclic permutation on {1,2,3}. So, in cycle
>> notation, 0- or 1-based doesn't matter (unless you're explicit about
>> domain, but then you should just be explicit about domain) and with
>> enumerated-images notation you can distinguish the two. I guess the only
>> point then is whether it's acceptable to have
>>
>> sage: Permutation([2,3,1])
>> [0,2,3,1]
>>
>> (but really, we could just always suppress the printing of fixed initial
>> and tail, in which case the printing problem goes away too).
>>
>
> Indeed. The only thing which I really really find annoying is the special
> notation for circular permutations.
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 prefer 2). Should we hold a formal vote?
Dima
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 list whether the permutation is 0-based or
> 1-based, since every element from the domain must must occur exactly once,
> so
>
> Permutation([1,2,0]) is a cyclic permutation on the 3 element set {0,1,2}
> and Permutation([2,3,1]) is a cyclic permutation on {1,2,3}. So, in cycle
> notation, 0- or 1-based doesn't matter (unless you're explicit about
> domain, but then you should just be explicit about domain) and with
> enumerated-images notation you can distinguish the two. I guess the only
> point then is whether it's acceptable to have
>
> sage: Permutation([2,3,1])
> [0,2,3,1]
>
> (but really, we could just always suppress the printing of fixed initial
> and tail, in which case the printing problem goes away too).
>
Indeed. The only thing which I really really find annoying is the special
notation for circular permutations.
Martin
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 domain must must occur exactly once,
so
Permutation([1,2,0]) is a cyclic permutation on the 3 element set {0,1,2}
and Permutation([2,3,1]) is a cyclic permutation on {1,2,3}. So, in cycle
notation, 0- or 1-based doesn't matter (unless you're explicit about
domain, but then you should just be explicit about domain) and with
enumerated-images notation you can distinguish the two. I guess the only
point then is whether it's acceptable to have
sage: Permutation([2,3,1])
[0,2,3,1]
(but really, we could just always suppress the printing of fixed initial
and tail, in which case the printing problem goes away too).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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-09-10 22:37 GMT+02:00 'Martin R' via sage-devel <
sage-devel@googlegroups.com>:
> 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 order 4! as a permutation group
>> sage: PermutationGroupElement([1,2,3]).parent()
>> Symmetric group of order 3! as a permutation group
>>
>> They live in Sym({1,...,n}) (where n is somehow divined from the input),
>> not in the injective limit of those things.
>>
>
> You are right. What I had in mind was:
>
> sage: S3 = PermutationGroup([['b','c','a'],['a','c','b']],
> domain=['a','b','c'])
> sage: S3.list()
> [(), ('b','c'), ('a','b'), ('a','b','c'), ('a','c','b'), ('a','c')]
>
> I agree with you that a permutation should be a set of cycles. There are
> two natural options then: anything that does not appear in a cycle is a
> fixed point, or the domain is the set of elements appearing in the cycles.
>
> It's important though to be able to regard "standard" permutations as
> words, too...
>
> Martin
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 order 4! as a permutation group
> sage: PermutationGroupElement([1,2,3]).parent()
> Symmetric group of order 3! as a permutation group
>
> They live in Sym({1,...,n}) (where n is somehow divined from the input),
> not in the injective limit of those things.
>
You are right. What I had in mind was:
sage: S3 = PermutationGroup([['b','c','a'],['a','c','b']],
domain=['a','b','c'])
sage: S3.list()
[(), ('b','c'), ('a','b'), ('a','b','c'), ('a','c','b'), ('a','c')]
I agree with you that a permutation should be a set of cycles. There are
two natural options then: anything that does not appear in a cycle is a
fixed point, or the domain is the set of elements appearing in the cycles.
It's important though to be able to regard "standard" permutations as
words, too...
Martin
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 > means the base actually is important right from the start. Can't we just > define permutations as a composition of cycles instead? Then we indeed do > not have to worry about whether they're 0 or 1 based. There seems to be a community of people in sage-combinat who don't multiply permutations in the maths they do. They don't care about cyclic structure that much. For them permutations are just combinatial objects... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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()
Symmetric group of order 3! as a permutation group
They live in Sym({1,...,n}) (where n is somehow divined from the input),
not in the injective limit of those things.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 as a composition of > cycles. That means the base actually is important right from the start. > Can't we just define permutations as a composition of cycles instead? Then > we indeed do not have to worry about whether they're 0 or 1 based. > I think that's what PermutationGroup and PermutationGroupElement do. Martin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 from the start. Can't we just define permutations as a composition of cycles instead? Then we indeed do not have to worry about whether they're 0 or 1 based. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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
> should print and accept inputs of the mathematical objects I use the way I
> use them in my math... As you know, I have no trouble understanding 0-based
> arrays, this is not the problem here. I'm not bluffing, I NEED those
> objects. I'm not sure what is so difficult for you to understand here.
>
In the discussion here it seems people are convinced that 0-based
permutations and 1-based permutations need to be distinct objects. While we
should probably have Sym() anyway, I imagine that Sym({0..n})
and/or Sym({1..n}) should probably exist on their own, because they can
likely be represented and worked with much more efficiently (and then
Sym() can just wrap it.
However, there's a natural inclusion {1..n} subset {0..n}, which induces a
natural inclusion Sym({1..n}) subset Sym({0..n}). By the time you're
working with permutations I can't believe that carrying around one extra
word is going to be much of an issue (and if n doesn't fit in a word,
you're not going to represent your permutations as arrays anyway). So on
any system that has Sym({0..n}) fully implemented, you'll have Sym({1..n})
anyway.
It would matter a bit if the permutations we're talking about would
actually have registered on them whether they act naturally on {0..n} or on
{1..n}, but they don't:
sage: parent(Permutation([1,2,3]))
Standard permutations
The parent is apparently lim_inj( Sym({1..n}), n -> infty ), i.e, bijective
selfmaps on {1,2,3,...} with all-but-finitely many values fixed. Changing
that to lim_inj( Sym({0..n}), n -> infty ) doesn't seem to have any effect
to me other than that
sage: Permutation([0,1,2])
would be valid rather than an error.
It DOES matter when a permutation is asked to naturally act on ordered
sequences, for which in Python lists are the archetype. And those are
mappings on {0,...,n}, not {1,...,n}. So if you want a data type that acts
naturally on ordered finite sequences then you pretty much need to act on
{0,...,n}, as Nicolas' example of permutations acting on matrices shows.
So I think there's a clear argument we NEED 0-based permutation.
Do we NEED 1-based permutations in a way that is not provided with the
inclusion {1,2,...} subset {0,1,2,...} ? It might help to identify
examples. I haven't seen them here yet.
Note that this is about whether we need
lim_inj( {1,...,n}, n -> infty) *in addition to* lim_inj({0,...,n}, n->
infty)
That we need Sym({0,...n}), Sym({1,..n}), and for that matter
Sym({n,...,m}) and Sym() is probably a given anyway, but
it seems orthogonal to the semantics of Permutation(...).
It is definitely the case that the current situation has led to a rather
screwed-up implementations. I quote from the documentation of
bruhat_inversions :
EXAMPLES:
sage: Permutation([5,2,3,4,1]).bruhat_inversions()
[[0, 1], [0, 2], [0, 3], [1, 4], [2, 4], [3, 4]]
sage: Permutation([6,1,4,5,2,3]).bruhat_inversions()
[[0, 1], [0, 2], [0, 3], [2, 4], [2, 5], [3, 4], [3, 5]]
(bruhat_inversions returns classic off-by-one answers, typical of 1-based
vs. 0-based confused code.)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 them in my math... As you know, I have no trouble understanding 0-based arrays, this is not the problem here. I'm not bluffing, I NEED those objects. I'm not sure what is so difficult for you to understand here. 0-based arrays are not "incompatible" with 1-based permutations. I'm sure that in the history of computer science, much more complicated data structures than 1-based permutations have been implemented... The way it is now is not that bad, in the sense that even so it's not good, I'm using it every day and it's very very useful for me (and for many others). I don't have major problems with it, it works completely fine for what I do with permutations. I understand it's not the case for everyone and I like clean / consistent code, so yes, it could be better designed, improved, etc. But I don't understand why 1-based permutations could not exist : we need a way to leave them here for the people who need them without letting them affect the people who don't need them... 2014-09-10 17:04 GMT+02:00 Nathann Cohen : > 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 permutations are so > uncompatible with Python's standard that we will never be at peace until we > have 0-based permutations instead. And I take this function as evidence. > > > But still, the solution is not to remove 1-based permutation. Maybe I > could > > be more clear, if 1-based permutations were removed, I would have to use > an > > old version of Sage so that I can properly work, or fork it, or > re-introduce > > them. I NEED THEM FOR MY RESEARCH, can you understand that? And I'm > > definitely not the only one. > > It makes me weep when I think of all those mathematicians who stopped > using computers because arrays are 0-indexed. > > Sorry, but I call that bluff. > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 permutations are so uncompatible with Python's standard that we will never be at peace until we have 0-based permutations instead. And I take this function as evidence. > But still, the solution is not to remove 1-based permutation. Maybe I could > be more clear, if 1-based permutations were removed, I would have to use an > old version of Sage so that I can properly work, or fork it, or re-introduce > them. I NEED THEM FOR MY RESEARCH, can you understand that? And I'm > definitely not the only one. It makes me weep when I think of all those mathematicians who stopped using computers because arrays are 0-indexed. Sorry, but I call that bluff. Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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
classically 0-based and could be used in many contexts) and the
combinatorial object Permutation which should stay 1-based.
And yes Nathan, everyone agrees there are some lack of consistency and the
one you mention about bruhat_inversions and inversions is definitely one.
But still, the solution is not to remove 1-based permutation. Maybe I could
be more clear, if 1-based permutations were removed, I would have to use an
old version of Sage so that I can properly work, or fork it, or
re-introduce them. I NEED THEM FOR MY RESEARCH, can you understand that?
And I'm definitely not the only one.
Best
Viviane
2014-09-10 15:30 GMT+02:00 Volker Braun :
> 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 arbitrary labels. 90% of the work will be
> just moving loop ranges to a single method that differs in the two
> implementations:
>
> for i in range(1,n+1):
> do_something(i)
>
> to
>
> for i in self._range(n):
> do_something(i)
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 arbitrary labels. 90% of the work will be just moving loop ranges to a single method that differs in the two implementations: for i in range(1,n+1): do_something(i) to for i in self._range(n): do_something(i) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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 permutations that do not work together is even worse than having 1-based permutations. Plus I am dead scared of what it may mean to either 1) Change the current code to handle 0-based AND 1-based permutations; or 2) Have two versions of each function The only good side that I see is that having those two kind of permutations will be so awful that we will shortly drop one, preferably the 1-based permutations. Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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_columns(sigma, base=0) with base=1 being the default. In either > case an error is raised if the range does not fit. Once we have separate > 0-based permutations we can make the default = do the right thing and > deprecate the optional parameter. 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). Dima -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 corrected. It should be simpler: (1,2,3)(4,5)(7,8) should be pre-parsed to ((1,2,3),(4,5),(7,8)) and we can define '*', '^-1', etc simply on the tuples of tuples, can't we? > Should (1,2,3) return a permutation instead of a tuple ? :- then there will be no difference between a tuple and a cyclic permutation... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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 ? :- Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 there, the harder it becomes to maintain. At one point we should think about a real tokenizer/parser IMHO. Also there are a few extra caveats, the following are all legal Python: (1, 2 , 3) (1, / 2, 3) (1, 2, # comment 3) On Wednesday, September 10, 2014 11:24:55 AM UTC+1, Dima Pasechnik 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)']) > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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, 3] >>sage: Permutation((1,2,3)) >>[2, 3, 1] >>I hate that code. > > So do I. However this has nothing to do with the ticket at hand which > is about how *permutation group elements* act on matrices: > > Permute the rows and columns of ``self`` by applying the > permutation group elements ``row_permutation`` and > ``column_permutation`` respectively. > > I'd like to have feedback on that part. 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)']) It looks tricky, as ( ...) (..) pattern might make sense in Python if everything except the last (..) is a function, e.g. (lambda x,y: x+y)(x,y) is valid Python, so this needs to be tested... This should not be hard if it can only be a lambda form though. Perhaps I am missing some obvious case that makes such a feature not possible within the current perparser limitations. Dima > > Cheers, > Nicolas > -- > Nicolas M. Thiéry "Isil" > http://Nicolas.Thiery.name/ > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 permutations apart with certainty before we can fix permute_columns() to do the right thing (TM). On Tuesday, September 9, 2014 9:44:00 PM UTC+1, Nicolas M. Thiéry wrote: > > 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 operations, yes, I am definitely in > favor of deprecating it. Volker's explicit "base" argument is a > good approach for the transition period. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 operations, yes, I am definitely in favor of deprecating it. Volker's explicit "base" argument is a good approach for the transition period. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 raised if the range does not fit. Once we have separate 0-based permutations we can make the default = do the right thing and deprecate the optional parameter. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> > 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. Martin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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,
>+the columns are considered as being numbered from `1`::
>+
>+sage: G = PermutationGroup(['(1,2,3)(4,5)',
>'(1,2,3,4,5)'])
>+sage: sigma, tau = G.gens()
>+sage: sigma
>+(1,2,3)(4,5)
>+sage: M = copy(N)
>+sage: M.permute_columns(sigma)
>+sage: M
>+[1 0 1 0 0]
>+[2 2 0 0 0]
>+[0 3 0 0 3]
>+[0 0 0 4 4]
>+[0 0 0 5 0]
>note that there is an unpleasant ambiguity here:
>namely, if, say in this example you take
>G = PermutationGroup(['(1,2,3)'])
>how one could tell whether it is meant to permute stuff in [0..2], or
>in [1..3] ?
>Do you mean that one must write G = PermutationGroup(['(0),(1,2,3)'])
>for the latter?
I agree it's not great. But do you have a better proposal?
The current situation is a painful source of confusion, and is
actually already ambiguous if one is not reading the specifications
carefully: in your above example, the unwary user may well expect that
he will permute stuff in [1..3].
The ticket only adds a new feature allowing for the natural 0-based
permutations. Otherwise it does not change the current behavior.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil"
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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, 1] >I hate that code. So do I. However this has nothing to do with the ticket at hand which is about how *permutation group elements* act on matrices: Permute the rows and columns of ``self`` by applying the permutation group elements ``row_permutation`` and ``column_permutation`` respectively. I'd like to have feedback on that part. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> > 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, let us define it with a list of cycles (and tuple of cycles too btw) Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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,2,3)(4,5)) >> >> In fact, you'd think ',' will do the trick, and yes, you can do >> >> Permutation((1,2,3),(4,5)) >> >> BUT: >> sage: Permutation((1,2,3),(4,5)) >> [2, 3, 1] >> >> this is the design decision I'd call, pardom my French, "f*ck typing, f*ck >> the user..." >> > >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 > unexpected behavior or errors. documenting an awful interface does not make it less awful. >As for this behavior, it's a shorthand, and I think it's acceptable. Yet > from this discussion, it could use more documentation. A way out is either implement Permutation((1,2,3),(4,5)) (and other similar inputs) to return what it should, i.e. [2, 3, 1, 5, 4] or remove Permutation((1,2,3)) If there are no objections to the former, I can probably provide an implementaion... Dima -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 () or [ ] on a object. Yes, maybe, it wasn't the best choice. But it's not absurd: it just considers the permutation to be a word and adds the () feature to use it as a function. Changing this would just mess tons of people work, mine included. But anyway we're going very far from the original subject. I'm not sure anyone has time now to rethink permutations entirely in a way that would be more consistent and without messing people's code and work, i.e. without erasing everythink as you suggest and change behaviour everywhere on a object that is used by many many people. Best, Viviane Le 8 sept. 2014 08:07, "Nathann Cohen" a écrit : > > 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 thing is dead misleading. > > > It's not a bug because it's not doing something wrong. It's just doing > > something different than you expect. Moreover I would not necessarily > expect > > those two to behave in the same way because I'm giving different input; > > especially for p(1) and p[1]. > > Travis, you can't even expect an user to be able to get the doc for () and > []. And it's not even the problem. This [] notation is about considering a > 1-based permutation as a 0-based arrays that returns 1-based indices. > > Can you really not see that it is a bad idea ? > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 that you don't. Come > on Travis open your eyes, this thing is dead misleading. For me, here Permutation((1,2,3)) vs Permutation([1,2,3]) is a source of confusions for programmers! Not for users. There are many places in Python where iterators return tupes and there are many places in Sage where iterators return lists... >> It's not a bug because it's not doing something wrong. It's just doing >> something different than you expect. Moreover I would not necessarily > expect >> those two to behave in the same way because I'm giving different input; >> especially for p(1) and p[1]. > > Travis, you can't even expect an user to be able to get the doc for () and > []. And it's not even the problem. This [] notation is about considering a > 1-based permutation as a 0-based arrays that returns 1-based indices. > > Can you really not see that it is a bad idea ? This is not so bad. You can consider a permutation as an ordered word, ie a bijection 0..n-1 to your domain. And then p[i] makes sense: it gives you the letter at position i (0 based). And by the way, it is the way it is printed on screen sage: Permutation([3,2,1]) [3, 2, 1] so you expect it to work more or less like a list. And this is what it does with respect to []. The notation perm(i) clearly refers to the fact that you consider the permutation as a map A -> A. Now mixing bijection 0..n-1 -> A with bijection A -> A is not necessarily a good idea... unless A is totally ordered and there is a prefered 0..n-1 -> A bijection which would correspond to the identity map. Vincent -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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 thing is dead misleading. > It's not a bug because it's not doing something wrong. It's just doing > something different than you expect. Moreover I would not necessarily expect > those two to behave in the same way because I'm giving different input; > especially for p(1) and p[1]. Travis, you can't even expect an user to be able to get the doc for () and []. And it's not even the problem. This [] notation is about considering a 1-based permutation as a 0-based arrays that returns 1-based indices. Can you really not see that it is a bad idea ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> > > 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 hellish -1/+1 difference between p[] and p(). It > takes forever to find this out. > When Sage does something different than what I expect, I look at the doc instead of wondering why it's different and being angry about it. Also again, different operations for p[] and p(). How long do you spend on figuring out why 2 + 2 != 2 / 2 because you were confused the operators look similar (well, when writing the division operator)? >From this discussion you see that people got in trouble because of > that, and changing the doc will make no difference. You don't read the > doc of every single function you use. You read the doc when you look > for a feature, a new flag or something. Or when you can't guess the > behaviour. You don't read the doc of "is_prime" when you want to test > if an integer is prime. > > When you type Permutation((1,2,3)) you expect it to return the same as > Permutation([1,2,3]), and when you type p(1) you expect the same as > p[1]. Documenting a bug does not fix it. > > It's not a bug because it's not doing something wrong. It's just doing something different than you expect. Moreover I would not necessarily expect those two to behave in the same way because I'm giving different input; especially for p(1) and p[1]. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
>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 > unexpected behavior or errors. 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 hellish -1/+1 difference between p[] and p(). It takes forever to find this out. >As for this behavior, it's a shorthand, and I think it's acceptable. Yet > from this discussion, it could use more documentation. >From this discussion you see that people got in trouble because of that, and changing the doc will make no difference. You don't read the doc of every single function you use. You read the doc when you look for a feature, a new flag or something. Or when you can't guess the behaviour. You don't read the doc of "is_prime" when you want to test if an integer is prime. When you type Permutation((1,2,3)) you expect it to return the same as Permutation([1,2,3]), and when you type p(1) you expect the same as p[1]. Documenting a bug does not fix it. Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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 the trick, and yes, you can do > > Permutation((1,2,3),(4,5)) > > BUT: > sage: Permutation((1,2,3),(4,5)) > [2, 3, 1] > > this is the design decision I'd call, pardom my French, "f*ck typing, f*ck > the user..." > 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 unexpected behavior or errors. As for this behavior, it's a shorthand, and I think it's acceptable. Yet from this discussion, it could use more documentation. > > -- > > But we digressed from #16557, as in fact one cannot do > > M.permute_columns(Permutation((1,2,3))) > > - you get > AttributeError: 'StandardPermutations_all_with_category.element_class' > object has no attribute 'domain' > > If a numerical linear algebra person were to try doing their stuff in > Sage, and they > actually do a lot of row and column permutations of matrices, (s)he would > run away screaming. > I agree this is a problem; it is a regression and needs to be fixed. Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 with columns and rows indexed from 1 to n. Apart from that, I also found Permutation((1,2,3,4)) == Permutation([2,3,4,1]) and Permutation([1,2])[1] == 2 confusing for a long time. I would have thought that circular permutations wouldn't have a special notation, and I would have thought that Permutations really are mappings, not words. I think it would make my coding life slightly easier if this behaviour went away, especially the notation for circular permutations. Thus, I guess having Permutation0 and Permutations0 is a good idea. Martin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 be pythonic, because a tuple should be the same as a list by what
> you're saying, we must have
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 the trick, and yes, you can do
Permutation((1,2,3),(4,5))
BUT:
sage: Permutation((1,2,3),(4,5))
[2, 3, 1]
this is the design decision I'd call, pardom my French, "f*ck typing, f*ck the
user..."
--
But we digressed from #16557, as in fact one cannot do
M.permute_columns(Permutation((1,2,3)))
- you get
AttributeError: 'StandardPermutations_all_with_category.element_class' object
has no attribute 'domain'
If a numerical linear algebra person were to try doing their stuff in Sage, and
they
actually do a lot of row and column permutations of matrices, (s)he would run
away
screaming.
>
> sage: [1, 2].append(3) == (1, 2).append(3)
>
> or perhaps you mean because they are both iterable, so
>
> sage: Permutation([(1,2,3)])
>
> should be a permutation on the set { (1,2,3) } because checking types is
> not pythonic?
>
>The point I'm making is that it is pythonic to handle different input
> types differently. That's what Permutation is doing, and there are examples
> which demonstrate this behavior. Now does it need to be better
> documentation, perhaps, but the programmer needs to be careful about what
> types are being used, even more so in weakly typed languages. Refining duck
> typing is not evil: you're only counting Mallards, not all ducks.
>
>
>> 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 anybody
>> creates a Permutation from a tuple. I find it worse, but that's the Sage
>> way.
>>
>
>I'm for keeping it (it's a natural shorthand) as I understand, and can
> easily teach people (mainly using the first example above), that a list and
> a tuple are different and there's an example which clearly shows they are
> handled differently. This difference between lists and tuples is something
> we have to work with a lot in Sage when dealing with hashing. Again,
> perhaps better documentation is useful.
>
>> Nathan, I would be glad if you could give *some* credit to the people who
>>> use permutations the way they are and listen when we tell you: we need them
>>> to start at 1!!
>>>
>> This thread has been created because Nicolas is implementing a workaround
>> for this "standard" in Matrices. Doesn't it scream that the standard is bad
>> ? A workaround in the very same software !
>>
>
>I'm for making the users' lives easier if programmers are willing to
> work a little bit more. In other words no, it just says that these objects
> have different standards for different reasons and we (the programmers)
> need to bridge this.
>
>>
>> If I were a reviewer for this patch, I would set the ticket to needs_work
>> only because "the matrix file is no place to parse permutation input. Use
>> the class that already exists for that. If it does not do what you want
>> then update it, but this code does not belong to the matrix files".
>>
>> Still left unanswered:
>>
>> sage: Permutation([1,2,3])[1]
>> 2
>> sage: Permutation([1,2,3])(1)
>> 1
>>
>> Is there a consensus here that this is a sound behaviour ? How do you want
>> me to believe that the current 1-based syntax is the best to not confuse
>> beginners when it creates behaviours like that ?
>>
>
>I think you should teach the beginners that what you've done P[i] vs.
> P(i) are two *completely* different operations. In math terms, you're doing
> 1 + 1 vs 1 * 1. Plus as mentioned (I think by you), we need to teach people
> that lists and other list-like objects are 0-based. Both of these are easy
> concepts that people pick up easily.
>
> Best,
> Travis
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
>
> 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 what
you're saying, we must have
sage: [1, 2].append(3) == (1, 2).append(3)
or perhaps you mean because they are both iterable, so
sage: Permutation([(1,2,3)])
should be a permutation on the set { (1,2,3) } because checking types is
not pythonic?
The point I'm making is that it is pythonic to handle different input
types differently. That's what Permutation is doing, and there are examples
which demonstrate this behavior. Now does it need to be better
documentation, perhaps, but the programmer needs to be careful about what
types are being used, even more so in weakly typed languages. Refining duck
typing is not evil: you're only counting Mallards, not all ducks.
> 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 anybody
> creates a Permutation from a tuple. I find it worse, but that's the Sage
> way.
>
I'm for keeping it (it's a natural shorthand) as I understand, and can
easily teach people (mainly using the first example above), that a list and
a tuple are different and there's an example which clearly shows they are
handled differently. This difference between lists and tuples is something
we have to work with a lot in Sage when dealing with hashing. Again,
perhaps better documentation is useful.
> Nathan, I would be glad if you could give *some* credit to the people who
>> use permutations the way they are and listen when we tell you: we need them
>> to start at 1!!
>>
> This thread has been created because Nicolas is implementing a workaround
> for this "standard" in Matrices. Doesn't it scream that the standard is bad
> ? A workaround in the very same software !
>
I'm for making the users' lives easier if programmers are willing to
work a little bit more. In other words no, it just says that these objects
have different standards for different reasons and we (the programmers)
need to bridge this.
>
> If I were a reviewer for this patch, I would set the ticket to needs_work
> only because "the matrix file is no place to parse permutation input. Use
> the class that already exists for that. If it does not do what you want
> then update it, but this code does not belong to the matrix files".
>
> Still left unanswered:
>
> sage: Permutation([1,2,3])[1]
> 2
> sage: Permutation([1,2,3])(1)
> 1
>
> Is there a consensus here that this is a sound behaviour ? How do you want
> me to believe that the current 1-based syntax is the best to not confuse
> beginners when it creates behaviours like that ?
>
I think you should teach the beginners that what you've done P[i] vs.
P(i) are two *completely* different operations. In math terms, you're doing
1 + 1 vs 1 * 1. Plus as mentioned (I think by you), we need to teach people
that lists and other list-like objects are 0-based. Both of these are easy
concepts that people pick up easily.
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> > 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 anybody creates a Permutation from a tuple. I find it worse, but that's the Sage way. > Nathan, I would be glad if you could give *some* credit to the people who > use permutations the way they are and listen when we tell you: we need them > to start at 1!! > This thread has been created because Nicolas is implementing a workaround for this "standard" in Matrices. Doesn't it scream that the standard is bad ? A workaround in the very same software ! If I were a reviewer for this patch, I would set the ticket to needs_work only because "the matrix file is no place to parse permutation input. Use the class that already exists for that. If it does not do what you want then update it, but this code does not belong to the matrix files". Still left unanswered: sage: Permutation([1,2,3])[1] 2 sage: Permutation([1,2,3])(1) 1 Is there a consensus here that this is a sound behaviour ? How do you want me to believe that the current 1-based syntax is the best to not confuse beginners when it creates behaviours like that ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 container, regardless of whether the container is indexed starting at 0 or 1. Anything that just depends on this action can be shared between the two classes. And yes, different _repr_ so you don't get confused all the time. And no coercion between the two permutation types, if you want to multiply a 0- and a 1-based permutation then you have to convert explicitly to your favorite representation. > > Yes, I think that's the way to go. We have to separate the Permutation as a combinatorical mathematical object (which starts at one) and the underlying structure which starts at 0. 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. Appart from that, I won't try anymore to convince people (Nathan) that 1-perm are needed. The point is: they exist, they are used and there is definitly no consensus to remove them. Nathan, I would be glad if you could give *some* credit to the people who use permutations the way they are and listen when we tell you: we need them to start at 1!! Yes there are some +-1 in my code but better there than in my head ALL THE TIME. Sage is mathematical software and I conceive it to print my objects as I use them in my maths. I don't say that your concerns are ill founded but the solution is not to remove 1-perms all together. Cheers Viviane > > > On Saturday, September 6, 2014 8:13:58 AM UTC+1, Nathann Cohen wrote: >> >> > 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 it to your desired presentation if you depend on the actual integers. >> >> This would be cool, but how do we write the code afterwards ? What are >> the objects returned by Permutation1 and Permutation0 ? The functions >> of this class have been written with a standard in mind, and if you >> let it deal with 0-based permutations and 1-based ones some functions >> will break. >> >> And if we make 1-based permutations be 0-based permutations with a >> diferent __repr__, a different __call__ and a different __getitem__ we >> will run into problem too.. How could we make this strategy work ? >> >> Nathann > > -- > You received this message because you are subscribed to the Google Groups "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 > compatibility is important. It's really annoying when you have to rewrite > ALL your old personal code when you update your sage version (which happens > all the time), and I know it's a put-off for many people (and Sage has > quite a bad reputation for it). > > Also, Nathann, please do not assume that you represent all the Sage coders. > I'm a Sage coder and user, and I use 1-Permutation. I use them ALL THE TIME > and I need them. In every single of my programs, because permutation is my > main object of study! And the users you seem to so easily ignore are > contributors too. They contribute to algorithms and maps on permutations > that are useful to everyone. The fact is that in the math world, in every > single paper about the symmetric group, the permutations are 1-Permutations > and it makes sense to have them. This is not 100% true. In permutation groups one often does not care about the ordering of the domain the group operates on. Besides, if one's domain is, say, Z/nZ, it's immediately obvious that using 0-base is much more natural. It's true that GAP and Magma, historically the oldest GAS' to do permutation groups, number permutations from 1, but this is due to them orginating from a Fortran IV program! Subsequent literature naturally used the same notation, for obvious reasons. So yes, we're captives of Fortran IV here... By the way, I help maintaining some 25+ years old C program to compute with centraliser rings of permutation groups, and there permutations are 0-based: https://github.com/dimpase/coco (it's a rewrite from scratch of a Fortran program, where permutations, naturally, were 1-based :-)) Dima -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 indexed starting at 0 or 1. Anything that just depends on this action can be shared between the two classes. And yes, different _repr_ so you don't get confused all the time. And no coercion between the two permutation types, if you want to multiply a 0- and a 1-based permutation then you have to convert explicitly to your favorite representation. On Saturday, September 6, 2014 8:13:58 AM UTC+1, Nathann Cohen wrote: > > > 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 it to your desired presentation if you depend on the actual > integers. > > This would be cool, but how do we write the code afterwards ? What are > the objects returned by Permutation1 and Permutation0 ? The functions > of this class have been written with a standard in mind, and if you > let it deal with 0-based permutations and 1-based ones some functions > will break. > > And if we make 1-based permutations be 0-based permutations with a > diferent __repr__, a different __call__ and a different __getitem__ we > will run into problem too.. How could we make this strategy work ? > > Nathann > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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.
If we start having Permutations0 and Permutations1 why not list0,
list1, tuple0, tuple1, etc? For me it does not looks like a solution.
As Sage is built on Python the only coherent way to define
permutations is on 0..n-1. Nevertheless, it is nice and useful to have
permutations on other domains like 1..n or {a,b,c}. What do you think
about the following for action on matrices/vectors/etc
class Matrix:
def permutation_action_on_rows(self, s):
D = s.parent().domain().cardinality()
if not D.cardinality() == self.nrows(): raise ValueError
s0 = s.as_perm_on_0_n() # might raise an Error if
# D is not totally ordered
self._permutation0_action_on_rows(s0)
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 world > sage: Permutation((1,2,3)) > > must be equal to > sage: Permutation([1,2,3]) +1 It would be particularly dangerous to have different behavior in that case (think about the semantic of an iterator that changes from iterating through list to iterating through tuples). > And if you mean the cyclic permutation (1,2,3) this should be > sage: Permutation([(1,2,3)]) +1 Vincent -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 for as long as people will ignore it, but NO it does not > make sense. You define a permutation with a collection of disjoint cycles, > not with one cycle alone. OK, sorry, perhaps, I am too used to GAP, which allows things like a:=(1,2)(3,4); b:=(3,4,5); 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)]) Dima -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 not make sense. You define a permutation with a collection of disjoint cycles, not with one cycle alone. And if some input are list of lists (cycle notation) and some others just list you do not need to differentiate between tuple/list. This is also your only protection against undefined domains. Secondly, from the point of view of the coder (or from the point of view of a guy who does not know that he uses Permutations, because he calls a function which calls a function, , which calls Permutation) this is dangerous too. I had this very problem when playing on permutation group: in general you do not expect the meaning of function( tuple(thing) ) to be different from the meaning ot function( list(thing) ). And you can't really say that one has to "know a bit about permutations" when you do not even call Permutation yourself though the function you use does it. Quite recently we had this too in #16261. sage: H = AdditiveAbelianGroup([0,2]) sage: H((2,0)) (0, 0) sage: H(vector((2,0))) (2, 0) Everybody seemed to agree that the following was a very bad idea: Is there a reason why it is a bad idea in AbelianGroup with tuples/vectors and a good idea for Permutations with tuples/lists ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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 it to your > desired presentation if you depend on the actual integers. This would be cool, but how do we write the code afterwards ? What are the objects returned by Permutation1 and Permutation0 ? The functions of this class have been written with a standard in mind, and if you let it deal with 0-based permutations and 1-based ones some functions will break. And if we make 1-based permutations be 0-based permutations with a diferent __repr__, a different __call__ and a different __getitem__ we will run into problem too.. How could we make this strategy work ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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 distinguish between tuples and lists. > Also, Nathann, please do not assume that you represent all the Sage coders. Look at the code. Those +1 -1 everywhere are a clear sign. The fact that we use different standard in the same software is another one. The fact that Nicolas implements functions to use both is another one. The fact that it is hard to handle both syntaxes at the same time yet another one. > I'm a Sage coder and user, and I use 1-Permutation. I use them ALL THE TIME > and I need them. You use permutations. it is fine. permutations are useful. I'm not for removing permutations, I am for having them 0-based. > The fact is that in the math world, in every single paper about the > symmetric group, the permutations are 1-Permutations and it makes sense to > have them. When you have a set of size n in a math paper, the points are labelled 1...n. On computers everything is 0-indexed. And nobody died because of that. > As Volker says, it's an old debate and you can't just erase everyone else's > work and point of views because it suits you. The arguments you give me are all contradicted by the fact that arrays are 0-based. It creates the very same problems, but changing having 1-based arrays is not even an open question. You are just enforcing a different syntax for permutations, and this is bad. It shows. Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 think backward > compatibility is important. It's really annoying when you have to rewrite Agreed. I quit Maple years and years ago because of this. An optional parameter can solve all this, IMHO. > ALL your old personal code when you update your sage version (which happens > all the time), and I know it's a put-off for many people (and Sage has quite > a bad reputation for it). > > Also, Nathann, please do not assume that you represent all the Sage coders. > I'm a Sage coder and user, and I use 1-Permutation. I use them ALL THE TIME > and I need them. In every single of my programs, because permutation is my > main object of study! And the users you seem to so easily ignore are > contributors too. They contribute to algorithms and maps on permutations > that are useful to everyone. The fact is that in the math world, in every > single paper about the symmetric group, the permutations are 1-Permutations > and it makes sense to have them. > > As Volker says, it's an old debate and you can't just erase everyone else's > work and point of views because it suits you. The fact that it makes you > lose time is bad and yes, we have to do something about it. But there is no > simple answer and people are making efforts to handle all these different > situations as best as they could. > > Cheers > > Viviane > > > 2014-09-05 22:16 GMT+02:00 Volker Braun : >> >> 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 >> can never say for sure if thats a 0-based permutation that just doesn't act >> on 0. >> >> 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 >> it to your desired presentation if you depend on the actual integers. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-devel+unsubscr...@googlegroups.com. >> To post to this group, send email to sage-devel@googlegroups.com. >> Visit this group at http://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 when you have to rewrite ALL your old personal code when you update your sage version (which happens all the time), and I know it's a put-off for many people (and Sage has quite a bad reputation for it). Also, Nathann, please do not assume that you represent all the Sage coders. I'm a Sage coder and user, and I use 1-Permutation. I use them ALL THE TIME and I need them. In every single of my programs, because permutation is my main object of study! And the users you seem to so easily ignore are contributors too. They contribute to algorithms and maps on permutations that are useful to everyone. The fact is that in the math world, in every single paper about the symmetric group, the permutations are 1-Permutations and it makes sense to have them. As Volker says, it's an old debate and you can't just erase everyone else's work and point of views because it suits you. The fact that it makes you lose time is bad and yes, we have to do something about it. But there is no simple answer and people are making efforts to handle all these different situations as best as they could. Cheers Viviane 2014-09-05 22:16 GMT+02:00 Volker Braun : > 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 > can never say for sure if thats a 0-based permutation that just doesn't act > on 0. > > 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 it to your desired presentation if you depend on the actual > integers. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 someone with some group theory background. (array notation vs cyclic notation) But the idea that one can guess the domain of a permutation given in cyclic notation is dangerous and is virtually guaranteed to cause pain and suffering. Cyclic notation comes from permutation groups, where each has a well-defined domain. Specifying permutations in cyclic notation without specifying the group they live in is akin to specifying a polynomial "by itself", outside of a polynomial ring... Dima -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 can never say for sure if thats a 0-based permutation that just doesn't act on 0. 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 it to your desired presentation if you depend on the actual integers. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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 and > accept entries as 1-starting perms. Not only for backward compatibility but > also for real-non-coder-people compatibility. Those combinatorists who would not think that one can define a 0-based permutation probably think the same for arrays, yet in every language I know arrays are 0-based. They will have to deal with this hard truth eventually. More importantly: why is it so easy for you to behave as if the time we (=coder-people) waste on those bugs is worth less than the time non-coder users waste on that ? It took me more than half an hour to find that out the last time I had a bug with a permutation group code. Just because of a tuple instead of a list ! Why is my time less valuable than somebody else's ? Why can't we make code that is good and useful for us ? Why should we make our work harder just to keep users in a dream world where permutations are 1-based, arrays 0-based, and some functions like Nicolas' handle both ? (and what kind of dream world is that ?). I am not a Sage employee. I use Sage for work and I contribute, but I don't know why I should keep on adding +1 and -1 in my permutation code if it is more practical for me and for all other developpers to have 0-based permutations. All it can do is cause more bugs and waste our time. A free software is a tool that developpers build for themselves. By the way: 1) Even in your way of looking at things the syntax is incorrect: a permutation can be defined as a list of cycles, so okay for Permutation( ((1,2,3),) ), but not for Permutation((1,2,3)). This is already sufficient to avoid the confusion above, and the distinction between tuples and lists. 2) Really, look at that: sage: Permutation([1,2,3])[1] 2 sage: Permutation([1,2,3])(1) 1 What do you believe it achieves, except confusing everybody ? Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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. Agreed. This should have deterministic output. > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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 notation. 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 and accept entries as 1-starting perms. Not only for backward compatibility but also for real-non-coder-people compatibility. Cheers Viviane Le 5 sept. 2014 17:00, "Nathann Cohen" a écrit : > > 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 Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> 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 Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
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`::
+
+sage: G = PermutationGroup(['(1,2,3)(4,5)', '(1,2,3,4,5)'])
+sage: sigma, tau = G.gens()
+sage: sigma
+(1,2,3)(4,5)
+sage: M = copy(N)
+sage: M.permute_columns(sigma)
+sage: M
+[1 0 1 0 0]
+[2 2 0 0 0]
+[0 3 0 0 3]
+[0 0 0 4 4]
+[0 0 0 5 0]
note that there is an unpleasant ambiguity here:
namely, if, say in this example you take
G = PermutationGroup(['(1,2,3)'])
how one could tell whether it is meant to permute stuff in [0..2], or in
[1..3] ?
Do you mean that one must write G = PermutationGroup(['(0),(1,2,3)']) for
the latter?
Dima
On Wednesday, September 3, 2014 2:46:25 PM UTC+1, Nicolas M. Thiéry wrote:
>
> Dear Sage devs,
>
> From the description of ticket #16577:
>
> 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. After this ticket,
> permutation of 0,...,n-1 are accepted and handled as can be
> expected. For permutations of 1..n and subsets thereof, the behavior
> is unchanged for backward compatibility.
>
> This ticket also includes the following changes:
>
> A rewrite of the documentation
> New documentation on a related method
> Code refactorization to avoid some duplication
> The implementation of M.permute_rows_and_columns(sigma)
>
> The ticket has been reviewed by Karl and is ready to go. This is just
> a final call in case someone would have some more opinion about it.
>
> Speak now or forever hold your peace :-)
>
> Cheers,
> Nicolas
> --
> Nicolas M. Thiéry "Isil" >
> http://Nicolas.Thiery.name/
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: #16577: enable 0-based row/column permutation of matrices
> > 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 uses the code. Happens in graphs too, and in combinatorial designs. > After this ticket, > permutation of 0,...,n-1 are accepted and handled as can be > expected. For permutations of 1..n and subsets thereof, the behavior > is unchanged for backward compatibility. > What about doing the job properly and respecting our own standards ? If you want to use 0-based permutations (and I am pretty sure that we all do), let's change this %*%*%$(&*(#&%_ permutation class to do what it should have been doing all along ! Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
