#20555: descents for Permutations : cleanup
-------------------------+-------------------------------------------------
Reporter: | Owner:
chapoton | Status: needs_review
Type: | Milestone: sage-7.2
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers: Travis Scrimshaw, Christian Stump
combinatorics | Work issues:
Keywords: | Commit:
permutation | 8dc44205ed34a559df49aa24ddd14facf47a7b0e
Authors: | Stopgaps:
Frédéric Chapoton |
Report Upstream: N/A |
Branch: |
u/chapoton/20555 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by stumpc5):
Replying to [comment:29 tscrim]:
> If you think of the permutation as an automorphism of [n], yes, but if
you think of it as an ordering of [n] written as (p,,0,,, p,,1,,, ...,
p,,n-1,,), then `p[i]` corresponds to p,,i,,. So it is a little more than
an implementation detail. Moreover, this perspective makes the descent set
independent of the index set and/or the objects we are permuting.
A priori, one could consider the list [Travis,Frédéric,Christian] a
permutation, but one cannot multiply such permutations (in contrary to
permutations in Sage). I think, you implicitly expect the objects to be
totally ordered (that is actually also needed to define descents in the
first place) and indeed in bijection with {1,...,n} or {0,...,n-1}, and
the list just to be one-line notation for the bijection.
I more believe our "argument" is closer to the surface: it is
mathematically more common to start labelling with 1, so it was decided to
have permutations of {1,...,n} per default instead of {0,...,n-1}, and it
is pythonically more common to start labelling with 0. These two handmade
choices conflict whenever they meet in the code, and one has to choose one
over the other to go on.
Indeed, I think it would have been better to make permutations on
{0,...,n-1} standard, and as well indexing sets. This would
* have generally not resulted in the above conflict,
* result in many speed improvements everywhere, see
{{{
sage: %timeit p[0]
1000000 loops, best of 3: 610 ns per loop
sage: %timeit p(1)
100000 loops, best of 3: 2.74 µs per loop
}}}
* cleaner code as one does not always need to do the +1/-1 thing for
lookups (see the code on reflection groups).
But that choice is made and not reversible, so we have to argue what to do
whenever we see that conflict appearing.
> Also, what is both of your opinions on removing the `from_zero` option
or just changing the default?
I do not have a strong opinion there, both choices have their rights to be
taken. If I'd do it myself, I would maybe leave the option and make it
`from_one` per default. (I would also make the name of the option the
default behaviour, don't you think so?)
--
Ticket URL: <http://trac.sagemath.org/ticket/20555#comment:31>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
