Talk:Coxeter group

{{User:MiszaBot/config

| algo = old(365d)

| archive = Talk:Coxeter group/Archive %(counter)d

| counter = 1

| maxarchivesize = 150K

| archiveheader = {{Automatic archive navigator}}

| minthreadstoarchive = 1

| minthreadsleft = 10

}}

{{WikiProject banner shell|class=B|

{{WikiProject Mathematics|importance = high}}

}}

{{Archive box |search=yes |bot=Lowercase sigmabot III |age=12 |units=months |auto=yes }}

Let's define "Coxeter group" properly

The article defines Coxeter group as follows:

"Formally, a Coxeter group can be defined as a group with the presentation

〈 r_1, r_2, . . ., r_n | (r_i r_j)^m_ij 〉

where m_ii = 1 and m_ij >= 2 for i ≠ j. The condition m_ij = ∞ means no relation of the form (r_i r_j)^m should be imposed."

The exact meaning of this definition can probably be guessed from reading further down the page. But why should anyone have to do that when a few more statements would make this definition clear, instead of unclear???

For one thing, no quantifier is applied to the subscripts of m_ij in the presentation, nor to the subscripts of m_ii in the next clause: Why not? And why not state *somewhere* that m_ij belongs to ℤ ∪ {∞} ???

Also: the last statement is mysterious, since it is unclear how "the condition m_ij = ∞" can be part of the presentation of the group (and there is nowhere else for this condition to be imposed). Probably this is backwards: what is intended is likely "If no relation of the form (r_i r_j)^m_ij appears in the presentation, then the number m_ij is taken to be ∞." If so, this should be stated clearly.Daqu (talk) 16:41, 29 January 2010 (UTC)

I think Daqu is exactly right --- and if not, could somebody please explain why not?

That is, why not say:

"An involution is an element of order 2. A Coxeter group is any group generated by finitely many involutions."??

If true, that lets somebody know exactly what a Coxeter group is without knowing what the word "presentation" means, or (worse) having to know or accept on faith any theorems about presentations.

Then the stuff about m_ij and so on could be presented as consequences of the definition. And those who know about presentations could then say "Ah, yes, and in fact the class of Coxeter groups can be defined via presentations".

I think in general definitions should involve just as little apparatus as possible, and only involve extra machinery when that significantly shortens and simplifies what is being defined.

An easier definition should never depend on a harder definition.

Of course, if i'm wrong and this is not what a Coxeter group is, somebody please explain and give a counterexample, and thanks in advance.

Son of eugene (talk) 20:11, 13 November 2010 (UTC)

: There are many groups which are generated by involutions and which are not Coxeter groups. For example, (almost?) all non-abelian finite simple groups are generated by involutions. So your suggestion does not work. One really needs to define Coxeter groups using the m_ij. BlackFingolfin (talk) 20:44, 11 January 2011 (UTC)

Naming scheme of Coxeter graphs diagrams

Any one care to explain the reasoning for the naming scheme of the graphs? Jka02 (talk) 15:26, 28 March 2012 (UTC)

Relationship between Coxeter group and diagram

If it's known, it might be nice to put up the relationship between the graph and the corresponding classification by finite simple groups? If not, I think GAP might be able to do this? Jka02 (talk) 15:26, 28 March 2012 (UTC)

Connection between bilinear form and Cartan matrix

At some point in time a little discussion about the connection between the Cartan matrix and the bilinear form would be worth adding. Jka02 (talk) 15:26, 28 March 2012 (UTC)

Finitely generated?

We are told all finitely generated Coxeter groups are automatic. Sure, but why specify finitely generated - that's in the definition as given. Is this not assuming a more general convention? — Preceding unsigned comment added by 75.38.193.168 (talk) 01:55, 4 November 2011 (UTC)

--

I've almost always seen Coxeter groups and Coxeter systems presented as finitely generated, this does not mean that someone has not done any research on non-finitely generated Coxeter groups - it just means that it isn't very popular. Jka02 (talk) 15:22, 28 March 2012 (UTC)

B3 cartan matrix??

In the example in the table the Cartan matrix for B3 has sqrt(2) in it!!!

--surely it should be non symmetric and have integral entries? — Preceding unsigned comment added by 158.109.1.18 (talk) 17:27, 29 May 2012 (UTC)

: Coxeter groups are undirected, so the Cartan entries are symmetric. Tom Ruen (talk) 19:53, 29 May 2012 (UTC)

Cartan Matrices

In the table of Coxeter matrices and Cartan Matrices, and nowhere else in the article, the Cartan matrices are called "Schlaefli" matrices. Ericlord (talk) 07:10, 19 February 2013 (UTC)

: I changed it to Schläfli matrix which redirects to a section at Coxeter-Dynkin diagram. Tom Ruen (talk) 20:06, 19 February 2013 (UTC)

All finitely generated Coxeter groups have a faithful reflection representation. This article suggests there exist Coxeter groups which do not. Since such a group must necessarily be infinitely generated, I'm curious if there's an example that can be given? — Preceding unsigned comment added by 50.131.246.101 (talk) 09:53, 16 March 2013 (UTC)

Bad Links

Table has:

Script error: No such module "CDD".

No further details are available. — Preceding unsigned comment added by 75.4.201.47 (talk) 03:39, 27 February 2019 (UTC)

: Caused by a name change, seems to fix on refresh. Tom Ruen (talk) 10:06, 27 February 2019 (UTC)

Contradiction about Ãn

In the section on affine Coxeter groups, it is stated that Ãn = [3^[n]], but according to the page on simplicial honeycombs, Ãn = [3^[n+1]]. This is clearly in conflict, but I do not know which one is considered standard. Eisenstein Integer (talk) 18:57, 1 January 2025 (UTC)

:I don't see this notation on Simplicial honeycomb; I think both articles agree that affine A_n has n + 1 nodes. (All our articles on Coxeter groups have a serious over-emphasis on unimportant notations, a reflection of the peculiarities of the people who have written them.) --JBL (talk) 03:57, 3 January 2025 (UTC)

::Ãn has n+1 nodes, but [3^[n]] implies that it has n nodes, because it's a cyclic structure, so, like a polygon, the number of nodes and the number of links should be equal, and therefore, it should be [3^[n+1]] Eisenstein Integer (talk) 18:51, 4 January 2025 (UTC)

:::I see no evidence that this undefined notation has the meaning you ascribe to it here, rather than the meaning that would agree with the rest of the article; the problem is the use of undefined, unexplained, uncited notations. --JBL (talk) 19:15, 4 January 2025 (UTC)

::::I assumed bracket notation to be the one as explained in the article on Coxeter notation, since that article explains a notation called 'bracket notation' and it works exactly as it does in this article, except for the affine Coxeter group Ãn. That being said, I don't have any citations for either scheme Eisenstein Integer (talk) 20:31, 4 January 2025 (UTC)

:::::The first mention of bracket notation in the page also links to the article on Coxeter notation. Eisenstein Integer (talk) 20:32, 4 January 2025 (UTC)

::::::Ok, thanks -- I now agree with you that there are two problems (the heavy emphasis on unexplained, uncited, unimportant notation, and its misuse in this instance). I'll change to n+1 as a minor fix of the one error. --JBL (talk) 22:46, 9 January 2025 (UTC)