Hi,
Thanks for raising this issue. For good and bad, rank and unrank are
indeed the standard names in enumerative combinatorics, which is why
we had chosen these names back then in MuPAD-Combinat, before the code
got ported to Sage-Combinat. I agree that the conflict with widely
used semantics in mathematics is annoying and would be best fixed by
choosing other names for the rank/unrank operations of enumerated
sets. It turns out that I'll probably meet one of the experts of the
field in the coming days; I'll ask him for suggestions for
alternatives and report back. For now I might lean toward
enumeration_rank and enumeration_unrank.
I remember that we had pondered back then about whether the
enumeration should be part of the structure (i.e. need to be preserved
by morphisms). IIRC -- but I may recall incorrectly -- we had decided
and documented somewhere that enumerated sets are sets endowed with
*some* computable enumeration (rather than a fixed one). Hence
morphisms need not preserve them.
Cheers,
Nicolas
Le Wed, Aug 20, 2025 at 09:00:15AM -0700, Nils Bruin a écrit :
> On Wednesday, 20 August 2025 at 02:57:36 UTC-7 axio...@yahoo.de wrote:
>
> Well, rank is really the standard term in computational combinatorics.
>
>
> But, as you note, it doesn't play nicely with terminology from other areas
> of mathematics -- the meaning of "rank" as for a matrix and for (free) rank
> of a module is very ingrained. Due to its very standard meaning for matrix,
> I'm confident that scoring the use of "rank" in the math literature will
> associate it most with its module meaning. For elliptic curves, this
> meaning also comes up for the abelian group formed by their rational points
> (a Z-module).
>
> A common tool used to resolve such name clashes is to use an underscored
> name. So you'd end up with ordinal_rank or enumeration_rank then. I still
> like enumeration_index better in that context.
>
> For "unrank" you could use enumeration_object or enumeration_element then,
> although I'm not too charmed by those.
>
>
> It seems to me that index is already quite overloaded: for example,
> `CombinatorialObject` defines it. I cannot find `index` as an alias for
> `rank`, where did you see that?
>
>
> sage: V=EnumeratedSets()([1..10])
> sage: V.index
> <bound method FiniteEnumeratedSet.rank of {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}>
> sage: V.rank
> <bound method FiniteEnumeratedSet.rank of {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}>
>
> The docstring actually refers to "index" and makes no mention of "rank".
>
> In src/sage/sets/finite_enumerated_set.py we have:
>
> def rank(self, x):
> """
> Return the index of ``x`` in this finite enumerated set.
>
> EXAMPLES::
>
> sage: S = FiniteEnumeratedSet(['a','b','c'])
> sage: S.index('b')
> 1
> """
> return self._elements.index(x)
>
> index = rank
>
>
>
> I think that the main use for rank and unrank is to have an arbitrary, but
> deterministic total order on the elements, and to be able to create
> elements at random. So, I would say they are of "technical" use, as
> opposed to "mathematical" use, apologies for my vague language. Therefore,
> I'd prefer a method name that makes this clear.
>
>
> Well, it says it's an enumerated set. I would say such a set comes with a
> bijection from [0..n]. Otherwise it's just a countable (or finite) set. In
> fact, I would expect that in the category of enumerated sets an isomorphism
> would respect that bijection too, so permutations would NOT be
> automorphisms in that category. We'd have enumerable sets if we do want to
> consider them automorphisms. EnumeratedSets should just be sequences
> without repeating elements. In fact if you don't insist that the ordinal
> map is an injection, it would even be allowed to have repeating elements.
>
> I don't think data that is necessary to describe an object in a category up
> to isomorphism is not "mathematical".
>
> --
> 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 view this discussion visit
> https://secure-web.cisco.com/1MrGAhqdQn-dGYxf403A0fDt2lOTNU6DE-5zyX6g_fW_XD0vOruZQU94v8x1q1mDlICp07FpLgfC8ZCVCaIWFLZrSqI97DAjwQdvqjoWzv1YL6FIyHH5EA3jnafdgvXy0pjURtGp2WjalyBD_A-TpwfkQg1Xdc1iDIHqmEfJzclqyxnhGUQvjHGtXKfDxLmTH0i9y-M-L2Me3bLZKlzlMi-WPC52nSTpu_spKLnZvDWQe0aJnK28DMoFqTNDk6opRrid1aBPvr2lpVcirLlZZ_d_ZCreLgybMrX3-1LoNAdwNlLc46IxZ1JSEKb67-NUvZgo8LkYHiJ_Aj692SCLltDKks0NGlxL-EItrp_b2USg3bl7sJfeVM8qHEE_iHFKgZCW6vOjDNDPuL8nB5PdHXzb-EWnNi_qrk1xBh5sd5MqYWeERQs7U3JSCtrqCzfWz/https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fsage-devel%2F26ea07f7-4146-4911-88a3-7ff424fceb2an%2540googlegroups.com
Nicolas
--
Nicolas M. Thiéry "Isil" <nicolas.thi...@universite-paris-saclay.fr>
http://Nicolas.Thiery.name/
--
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 view this discussion visit
https://groups.google.com/d/msgid/sage-devel/ggnku5janbsq5syecqbjdls7r7n25ou5boibvfp73daaciliul%40hxswkmaq23bp.
