Opened 8 years ago

Last modified 5 years ago

#13700 new defect

fix non-crystallographic "example" of Dynkin diagram

Reported by: hthomas Owned by: sage-combinat
Priority: minor Milestone: sage-6.4
Component: combinatorics Keywords: root system, Dynkin diagram
Cc: nthiery Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:


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

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.

Change History (11)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:3 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:4 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:5 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:6 Changed 5 years ago by jakobkroeker

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

comment:7 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by 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.

comment:9 Changed 5 years ago by 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.


comment:10 Changed 5 years ago by 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 C3 is good to me.

comment:11 Changed 5 years ago by 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.

Note: See TracTickets for help on using tickets.