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
On 2014-09-11, 'Martin R' via sage-devel sage-devel@googlegroups.com 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:
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).
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:
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
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,
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
On 2014-09-09, Nicolas M. Thiery nicolas.thi...@u-psud.fr 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:
Pretty much anything in parentheses can result in a callable object:
sage: R.x,y = 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
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 ?
On 2014-09-10, Nathann Cohen nathann.co...@gmail.com 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 ?
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,
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
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
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
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
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
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
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
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
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
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()
On 2014-09-10, Nils Bruin nbr...@sfu.ca 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.
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
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.
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
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]
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 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
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
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
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
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
2014-09-08 8:07 UTC+02:00, Nathann Cohen nathann.co...@gmail.com:
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
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 ()
On 2014-09-07, Travis Scrimshaw tsc...@ucdavis.edu 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
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
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
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,
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
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
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
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
On 2014-09-06, Nathann Cohen nathann.co...@gmail.com 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
2014-09-06 10:06 UTC+01:00, Dima Pasechnik dimp...@gmail.com:
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
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.
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
On 2014-09-05, Viviane Pons vivianep...@gmail.com 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
Le 6 sept. 2014 11:41, Volker Braun vbraun.n...@gmail.com 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
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
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
On 2014-09-06, Travis Scrimshaw tsc...@ucdavis.edu 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
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
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`::
+
+
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
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
On Fri, Sep 5, 2014 at 11:00 AM, Nathann Cohen nathann.co...@gmail.com 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
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
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
On 2014-09-05, Nathann Cohen nathann.co...@gmail.com 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
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
On Fri, Sep 5, 2014 at 5:48 PM, Viviane Pons vivianep...@gmail.com 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
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
63 matches
Mail list logo
