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(<finite set>) 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(<finite set>) 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(<any finite set>) 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.
