conflicting semantics of rank

[Martin R]

Dear all,

in the category for `EnumeratedSets` we have methods `rank` and `unrank` that provide a bijection between the set and the natural numbers (or some interval [0,n], if the cardinality is n).  These methods are mostly used in the category framework, I think, to provide generic implementations of `random_element` and the like.

Unfortunately, this conflicts with the method `rank` in Posets and WeylGroups, as I realized while adding a test_rank method (which in turn uncovered quite a few bugs).

Even though `rank` and `unrank` were introduced very early in the game, I think it would make sense to rename them to something less confusing and deprecate them.  I don't think they are used much by users.   For example, I think `total_order_rank` and `total_order_unrank` would be OK.

I don't think it is wise to rename `Poset.rank` or `WeylGroup.rank`, because these are really extremely standard.  We do have `StandardTableau.standard_descents` and `StandardTableau.standard_major_index`, because of an historical accident, and I think it's a pain.  However, if very many people think it is better to do `Poset.standard_rank`, than this would also be an option.

I am also open to other suggestions, but I really think that these methods should be tested systematically.

Martin

[Nils Bruin]

Agreed! In fact, looking at the docstring, it seems like "rank" is just an alias for "index". Of course, "index" is going to be a similarly overloaded term, but at least "rank" can be freed up by just dropping it as an alias of "index". You can then solve the problems of "index" separately.

For "unrank" (which according to the doc should give the position of an element in the enumeration) you could use "ordinal" instead, but "unrank" is such an ugly word that I don't think you'll run into many clashes for that one.

[Vincent Delecroix]

The name index follows Python convention

>>> [1, 2, 5, -2, 3].index(-2)
3

sounds like a much better name than rank.

Note that rank could also refer to the dimension of a vector
space/free module or the number of generators of a free group.

> --
> 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+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/c97ab592-3a65-4fa9-8dc4-34b8176585b9n%40googlegroups.com.

[Martin R]

Well, rank is really the standard term in computational combinatorics.  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?

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.

Martin

[Nils Bruin]

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

[Martin R]

Dear Nils,

On Wednesday, 20 August 2025 at 18:00:15 UTC+2 Nils Bruin wrote:

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

Sorry, I wasn't clear.  What I meant is that `rank` and `unrank` should be *part* of the name.  As far as I know the literature, `index` is not used in this context.  See, for example, https://page.math.tu-berlin.de/~felsner/SemWS17-18/Ruskey-Comb-Gen.pdf

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.

 In my original post I proposed `total_order_rank` and `total_order_unrank`.  I think it would be good to have the same prefix, in order not to further clutter the already long list of method names you get by tab completion in enumerated sets.

All the best,

Martin

[Nils Bruin]

On Wednesday, 20 August 2025 at 13:55:04 UTC-7 axio...@yahoo.de wrote:

 In my original post I proposed `total_order_rank` and `total_order_unrank`.  I think it would be good to have the same prefix, in order not to further clutter the already long list of 

method names you get by tab completion in enumerated sets.

Sure; fine with me. I suspect you'll have to leave the alias "index" in place for compatibility with python lists. 

[Travis Scrimshaw]

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. 

Let me also point out that this is for enumerated sets, which means there is a special total order on the objects. So I might not call it arbitrary. However, that is somewhat of a digression.

Best,

Travis

[Travis Scrimshaw]

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.

 In my original post I proposed `total_order_rank` and `total_order_unrank`.  I think it would be good to have the same prefix, in order not to further clutter the already long list of method names you get by tab completion in enumerated sets.

How about enumeration_rank and enumeration_unrank to specify that it is coming from the conditions of a parent being an enumerated set?

Best,

Travis

[Nils Bruin]

On Wednesday, 20 August 2025 at 17:35:20 UTC-7 tcsc...@gmail.com wrote:

Let me also point out that this is for enumerated sets, which means there is a special total order on the objects. So I might not call it arbitrary. However, that is somewhat of a digression.

And that order is indeed relevant! This category indeed does what it advertises:

sage: E=EnumeratedSets()
sage: V=E([1,2,3])
sage: W=E([1,3,2])
sage: V == W
False

so the ordering on the elements is a very fundamental property.

Also, these objects are UniqueRepresentation, so they are incredibly expensive to create. One should only use them when one really needs parent-like properties from them. You do get lightning-fast comparison between them once they are created, though.

 

[Nicolas M. Thiery]

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

> --
> 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+...@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...@universite-paris-saclay.fr>
http://Nicolas.Thiery.name/