relabelled DynkinDiagram can has weird index set

[vit-tucek]

Usually relabeling works nice but when one wants to relabel with symbolic variables the index set is in wrong order. The index set of the associated CartanType is however correct.

D = DynkinDiagram("A3")
print(D)
print(D.index_set())
var('a', 'b', 'c')
rsD = D.relabel({1:'a', 2:'b', 3:'c'})
print(rsD)
print(rsD.index_set())
rD = D.relabel({1:a, 2:b, 3:c})
print(rD)
print(rD.index_set())
print(rD.cartan_type().index_set())

Component: combinatorics

Reviewer: Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/24385

[tscrim]

Reviewer: Travis Scrimshaw

[tscrim]

comment:1

This is not a bug as the ordering of the index set (which the ordering does not matter because it is a set) is determined by the vertices of the Dynkin diagram.

[vit-tucek]

comment:2

I guess my problem stems from the fact that index_set returns a tuple which is implicitly ordered. I think either it should return a set as its name suggest or the ordering should be consistent.

[tscrim]

comment:3

One needs an implicit ordering for the Cartan matrix. Also, anyone who does stuff with Lie/Coxeter types that I know would want this to be called index_set. Also, working with (frozen)sets is slower (and can be more difficult to work with) for common operations with the index set such as iteration.

There is no loss of generality for fixing an order, but why should one order be preferred over another? You are also getting different relabelings because the types are different too, so there is not really an inconsistency.

[vit-tucek]

comment:4

If you view Dynkin diagram as a directed graph then there are basically two orderings, right? But the thing is that there is a fixed ordering hidden in DynkinDiagram._cartan_type._index_set (or in DynkinDiagram.cartan_type().index_set(). So I think the question is if we want to admit it explicitly and just return this for DynkinDiagram.index_set(). I was actually bitten by this fact that DynkinDiagram.index_set() is NOT the index set of the Cartan type the Dynkin diagram encodes. If there is a good reason to keep it in this current form and (imho misleadingly) return just a tuple of vertices of the underlying directed graph, then I am fine with that. Otherwise I don't see any harm in making this simple change.