fix non-crystallographic "example" of Dynkin diagram

[hthomas]

DynkinDiagram().an_instance() returns something that isn't a Dynkin diagram, in the sense that it is non-crystallographic, i.e., its Cartan matrix is not symmetrizable.

sage: X=DynkinDiagram().an_instance()
sage: X.cartan_matrix()
[ 2 -1 -1]
[-2  2 -1]
[-1 -1  2]
sage: X.cartan_matrix().is_symmetrizable()
False

It will be trivial to fix this.

I wonder if the "add_edge()" method should be changed -- as it stands, it is easy for the user to create instances of DynkinDiagram() which will not in fact be Dynkin diagrams, as this example shows.

[hthomas]

The code says the example is a hyperbolic Dynkin diagram and appears on p. 57 of Kac's Infinite Dimension Lie algebras, in exercise 4.9. In Chapter 4, Kac is not assuming his (generalized) Cartan matrices are symmetrizable, which is probably at the root of the problem.

[jakobkroeker]

can the described behaviour be qualified as 'mathematically wrong answer'?

[tscrim]

How I have always seen Dynkin diagrams, no assumption of symmetrizability is required, which is a different condition than crystallographic condition. So in a way, this is about getting our conventions decided.

[hthomas]

I don't exactly know why I got worked up enough about this to open a ticket.

My usage (which I think is typical of people in representation theory of finite-dimensional algebras) is that Dynkin diagrams are of types A to G.

Maybe the thing that bugged me is that if you ask for an instance of a Dynkin diagram, I feel like you should get a typical instance. I feel like C_3 would be a better choice.

But I don't have a clear sense of how questions like this are resolved in Sage.

[nthiery]

I think the result is mathematically correct. But I see the point of returning something more typical. This is the outcome of the tension between the two use cases of this method:

• Providing something typical / well known for the user
• Providing something generic enough, in particular for running tests.

If I checked correctly, this method is barely used. So we don't have to worry about backward compatibility. Here is a suggestion:

    sage: DynkinDiagram_class.an_instance()
    ... returns a Dynkin diagram of type C3 ...

    sage: DynkinDiagram_class.an_instance(finite=False)
    ... returns the current output ...

Any variant for the name of the argument is welcome.

For the Dynkin diagram of type C3, we have two options: either return DynkinDiagram?(["C",3]), or build by hand the same Dynkin diagram (again for a bit more genericity). I don't have an opinion on this.

Cheers,

[tscrim]

Actually, I'm thinking we should remove this outright:

sage: DynkinDiagram(['D',4]).an_instance()
Dynkin diagram of rank 3

I understand the point, but it is strange having it as a method of an instance of a Dynkin diagram. I know this is a fault of Python/@staticmethod, but still, if anything we would likely be better served having this as a method attached to the function DynkinDiagram. We could switch to samples as we have for CartanType(Factory).

Although switching to C₃ is good to me.

[hthomas]

I agree with Travis that the current usage of an_instance() doesn't make any sense and should be removed. I hadn't grasped exactly what was happening.

I have no opinion about the right way to implement a feature which would give example(s) of Dynkin diagrams.