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