>
> 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.
