Talk:Coxeter–Dynkin diagram/Archive 1

Archive1: February 6, 2012

Graphics element documentation

Coxeter-Dynkins graphics on Wikipedia:

These component elements can be strung together to create linear diagrams. There are three variations are 20, 30, and 48 pixels tall and are not to be intermixed to avoid vertical alignment issues. The elements are variable width, (making them hard to systematically scale with "px" pixel-width codes).

The 20-pixel tall elements are for simple linear and integer labels, with filenames prefixed by "CDW_". The 30-pixel tall elements are for simple linear elements with fractional labels, AND ALSO for 2-level node symbols, with filenames prefixed by "CD_". The 48-pixel elements are for triple level node symbols, with filenames prefixed by as "CDT_".

Note: These are all experimental, and may be improved/simplified/renamed. SVG variations exist for some, but there are some unresolved issues with some of them.

NEW

Here's a new set (not complete), built with Template:CDD argument sets, allowing 3 vertical levels of nodes, top(a), middle, and bottom(b). Tom Ruen (talk) 07:38, 4 January 2011 (UTC)

Type	rings														holes			Branch rings
CDel_

Type	nodes									2	2c	branches																Middle branch orders																				Divisors					Upper branch orders											labels
CDel_																																								...						...

WHOLE

Type	ring	node	hole	unused	n	p	q	r	s	t	u	v	w	x	y	z
PNG
SVG					File:CDW n.svg

Type	∞	∞b	2	2b	2c	3	3b	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20
PNG
SVG		File:CDW infinb.svg

Fractional

Type	ring	node	hole	unused	p	q	r	s	t	u	v	w	p/q
PNG
SVG

Type	∞	2	2b	2c	3b	3	3/2	4	4/3	5	5/2	5/3	5/4	6	6/5	7	7/2	7/3	7/4	7/5	7/6
PNG
SVG

Type	8	8/3	8/5	8/7	9	9/2	9/4	9/5	9/7	10	10/3	10/7	10/9
PNG				File:CD 8-7.png					File:CD 9-7.png	File:CD 9-8.png
SVG												File:CD 10-3.svg	File:CD 10-7.svg	File:CD 10-9.svg

Type	11	11/2	11/3	11/4	11/5	11/6	11/7	11/8	11/9	11/10	12	12/5	12/7	12/11
PNG		File:CD 11-2.png	File:CD 11-3.png	File:CD 11-4.png	File:CD 11-5.png	File:CD 11-6.png	File:CD 11-7.png	File:CD 11-8.png	File:CD 11-9.png	File:CD 11-10.png
SVG		File:CD 11-2.svg	File:CD 11-3.svg	File:CD 11-4.svg	File:CD 11-5.svg	File:CD 11-6.svg	File:CD 11-7.svg	File:CD 11-8.svg	File:CD 11-9.svg	File:CD 11-10.svg		File:CD 12-5.svg	File:CD 12-7.svg	File:CD 12-11.svg

Double-level

PNG
SVG								File:CD downbranch-23.svg		File:CD downbranch-33b.svg									File:CD downbranch-10-left-3.svg	File:CD downbranch-10-left-4.svg	File:CD downbranch-10-left-5.svg	File:CD downbranch-10-left-p.svg		File:CD downbranch-10-right-4.svg	File:CD downbranch-10-right-5.svg	File:CD downbranch-10-right-q.svg	File:CD downbranch-01-left-3.svg	File:CD downbranch-01-left-4.svg	File:CD downbranch-01-left-5.svg	File:CD downbranch-01-left-p.svg	File:CD downbranch-01-right-3.svg	File:CD downbranch-01-right-4.svg	File:CD downbranch-01-right-5.svg	File:CD downbranch-01-right-q.svg	File:CD downbranch-11-left-4.svg	File:CD downbranch-11-left-5.svg	File:CD downbranch-11-left-p.svg	File:CD downbranch-11-right-4.svg	File:CD downbranch-11-right-5.svg	File:CD downbranch-11-right-q.svg

PNG
SVG		File:CD righttriangle-100.svg	File:CD righttriangle-110.svg		File:CD righttriangle-sss.svg		File:CD righttriangleopen-100.svg	File:CD righttriangleopen-110.svg	File:CD righttriangleopen-010.svg	File:CD righttriangleopen-001.svg

Triple level

PNG
SVG	File:CDT dot.svg	File:CDT dash.svg	File:CDT ring.svg	File:CDT 2a.svg	File:CDT 3a.svg	File:CDT 3b.svg	File:CDT branch000.svg	File:CDT branch100.svg	File:CDT branch010.svg	File:CDT branch110.svg	File:CDT branch101.svg	File:CDT branch111.svg

by the way

Have the hyperbolic kaleidoscopes been enumerated? —Tamfang 07:01, 20 April 2007 (UTC)

Not given in wikipedia so far - Existence includes truncation permutations for the regular forms given at List of regular polytopes, but I don't know of any bifurcating graphs. Bitruncation lists some fun hyperbolic truncations. Tom Ruen 19:48, 20 April 2007 (UTC)

Wendy Krieger recently listed them in Talk:Polychoron. —Tamfang 08:21, 29 September 2007 (UTC)

There are an infinite number of groups with 3 nodes. In essence, {p,q,r:} (triangle marked p,q,r), except for those that occur in Euclidean and Spheric space. These are "finite extent" groups, because the symmetry has a finite linear size.

For bollochora, there are just the nine: 534, 353, 535, 53A, 3343:, 3353:, 3434:, 3435:, and 3535:

For bollotera, there are just five: 5333, 5334, 5335, 533A, amd 33334: .

No more exist in higher space (then 4dt or 5dp dt = dimensional-tilings, dp = dimensional polytopes.

For "finite content" groups, the cells have finite content, but one or more "horns" that stretch to the horizon. Because these converge logrithmically, there is little content in these horns.

If horotopic points (on the horizon) are permitted, then the number of wythoff-groups goes to 72, stretching to 9dt = 10dp. Unlike the "finite extent" groups, there is a lot of inter-relation between the groups.

If infinite cells are allowed, one gets every possible graph allowed. These are 'frieze-groups', in that there is transport in a small sector of the space, while the symmetry is bounded inside a laminotope (polytope bounded by unbounded face(t)s. A strip or layer is an example). One can 'cross' friezes to get symmetries, such as the octahedron-octahedral groups do. (these use groups like 8,3,4 ×8,3,4, 8,4,A × 8,4,A and 8,3,4,3 × 8,2,8,3.

--Wendy.krieger 07:58, 6 October 2007 (UTC)

These Compact hyperbolic Coxeter groups are enumberated in this paper: THE GROWTH SERIES OF COMPACT HYPERBOLIC COXETER GROUPS WITH 4 AND 5 GENERATORS, Canad. Math. Bull. Vol. 41 (2), 1998 pp. 231–239

SVG vs PNG

I REALLY dislike the SVG images. They are fuzzy and annoying to look at compared to crisp pixel images. They're never rescaled and so the PNG versions look fine. (ALSO, these symbols are still "in progress", adding more as needed as PNG.) Tom Ruen (talk) 21:24, 12 August 2008 (UTC)

I agree that in some cases that the PNGs do look a little crisper, but at least on my monitor, the SVGs look smoother and just as clear. What bothers me about the PNGs is the way the look in tables with gray background -- the white boxes around the symbols are kind of distracting. Here are some examples for comparison. Nonenmac (talk) 00:29, 13 August 2008 (UTC)

Yes, agreed on background colors. I COULD suggest GIF for transparent background (and smaller file size too), but no one on wiki like gifs, poor things. Tom Ruen (talk) 02:47, 13 August 2008 (UTC)

PNG images can have transparent backgrounds -- the SVG images are converted to PNG for display on wikimedia web pages anyway, so what you are seeing are PNGs. I suspect that if we come up with the right fonts and line weights that the SVG-generated images may show up as sharp as your native raster images at the nominal resolution, and you may find that it's easier to change a couple of characters of SVG code than it is to create or modify an image in a graphics editor. Though it's also possible that the rendering program that wikimedia uses will do too much smoothing whatever the font or line weights. I'll play around with some of the SVG images anyway. They may turn out to be useful if someone wants to scale them up for some reason. Also most of your PNGs haven't been ported to Commons yet, so some of the other wikis might find them useful. -- Nonenmac (talk) 13:32, 13 August 2008 (UTC)

x =	ring	dot	hole	dash	2	2b	2c	3	3b	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	p	q	r	s	t	u	v	w	∞
CDW_x.png
CDW_x.svg
CD_x.png																			n	n	n	n	n	n	n	n
CD_x.svg																			n	n	n	n	n	n	n	n

PNG
SVG

PNG CDW
SVG CD

Continuation - moved from User Talk:Tomruen

Why? Why would raster graphics be preferable to the SVG versions of these images? —Justin (koavf)❤T☮C☺M☯ 07:15, 6 March 2010 (UTC)

The Coxeter-Dynkin symbols are still in progress. The existing set doesn't allow all diagrams, and I'm more comfortable with PNG. Plus they are small as-is, no size advantage to SVG. Plus they are NEVER resized. Plus the SVG are FUZZY, while PNG are sharp. Why doesn't the fonts on my screen use fuzzy antialiasing characters? Because they're less clear and annoying to the eyes! Is that enough reasons? Tom Ruen (talk) 07:18, 6 March 2010 (UTC)

Not really I can't imagine how a scalable vector graphic could possibly be fuzzy while a raster graphic would be clear; that makes no sense to me. Also, you are removing orphan tags from pages. I suggest that you review your edits. If some of these SVGs are somehow inferior to the raster versions they are superseding, you should have the SVGs fixed. If the SVGs aren't and can't supersede the raster graphics, then {{SVG}} should probably be removed. —Justin (koavf)❤T☮C☺M☯ 07:26, 6 March 2010 (UTC)

I'm reverting because its the simplest way to reverse what you've done. And as far as orphan tag makes no sense. The polytope pages are vastly cross-linked. Tom Ruen (talk) 07:27, 6 March 2010 (UTC)

WP:ORPHAN You are incorrect about the criteria for an orphaned page. I suggest that you stop what you're doing, as you're undoing the work of replacing these raster graphics as well as identifying orphaned pages. —Justin (koavf)❤T☮C☺M☯ 07:39, 6 March 2010 (UTC)

I'm sorry for not having much pity for your edits, but you're the one doing massive changes. To your previous reply, antialiased SVG images make FUZZY PNG files. Sharp PNG images make sharp PNG images, if you don't resize them. Lastly, as to the meaning of ORPHAN, a quick read shows me nothing that contradicts my understanding. Tom Ruen (talk) 08:10, 6 March 2010 (UTC)

Pity? I'm not asking for pity; I just want you to comply with WP:ORPHAN and the fact that these images are tagged as being superior. Again, if they are actually inferior, they should have {{SVG}} removed. If they are superior, they shouldn't be replaced with their raster equivalents. I also don't see why you're reverting the addition of the SVG tag or replacing File:CD ring.png with File:CD ring.svg. Is this miniscule image actually fuzzy to you? Simply put, this seems to be a violation of WP:POINT to me, and if you don't stop, I feel like my only option is to post to WP:AN. I've no doubt that your edits are good faith, but they are apparently disruptive and undermine a number of constructive changes. —Justin (koavf)❤T☮C☺M☯ 08:16, 6 March 2010 (UTC)

Orphans E.g. Truncated 5-orthoplex has two incoming links and you removed {{Orphan}}. You should seriously stop this. —Justin (koavf)❤T☮C☺M☯ 08:18, 6 March 2010 (UTC)

I'm done reverting if you're done coverting. I don't see it's my responsibility to sort out your bad edits from good - 60 minutes of reverting is enough of my time wasted I think. I removed {{SVG}} from the PNG symbol images that you added, if that's what you're suggesting. I discussed the SVG option long ago with the other user who made the SVG versions. Tom Ruen (talk) 08:23, 6 March 2010 (UTC)

Consensus If there was some consensus reached to not convert these PNGs to SVGs, I would like to see it and I would also like to know why some of them were converted anyway. The point I was making above was that none of these were "bad" edits; they all have a clear rationale that is in conformity with a preexisting guideline. —Justin (koavf)❤T☮C☺M☯ 08:26, 6 March 2010 (UTC)

Discussion is here Talk:Coxeter–Dynkin_diagram#SVG_vs_PNG. If massive edits are reverted, I'd call that something bad, wasted time for all. Tom Ruen (talk) 08:32, 6 March 2010 (UTC)

Thank you This discussion clearly does not constitute consensus to use PNG, but I appreciate your link. Considering what I have before me, I will be reverting your reverts when I get the chance, per all of the evidence that you have provided. —Justin (koavf)❤T☮C☺M☯ 08:37, 6 March 2010 (UTC)

Are you saying because I wasn't careful to selective undo your edits, you are going to revert mine? Or are you saying SVG > PNG no matter what? Where do I complain to stop you? Tom Ruen (talk) 08:43, 6 March 2010 (UTC)

No What I am saying is that all of the following were justified:

• Changing raster graphics to SVGs, per the inclusion of {{SVG}} on those graphics
• Adding {{orphan}} per WP:ORPHAN
• Adding {{SVG}} to raster graphics that can be superseded by SVGs

I am also saying that your reversions are unjustified, as the only warrant you have given is your assertion that the PNGs generated by MediaWiki are fuzzy to you and a conversation between you and one other editor who directly contradicts that. You have given no substantial reason for your reverts and I have given you several substantial reasons for my initial edits as well as my plans to revert you.

If you think that I am in error somehow, you are free to post some compelling guideline, policy, or argument here or on my talk. Otherwise, I will revert back to the versions that I made, per above. If you feel that I am out of line, you are free to request an admin's intervention yourself, but I think that the stronger argument is going to be found in favor of my edits. I am leaving now and will be back in several hours; at that time, I will check my talk as well as yours and your contributions. —Justin (koavf)❤T☮C☺M☯ 08:59, 6 March 2010 (UTC)

I wrote a complaint here Wikipedia:Editor_assistance/Requests#Coxeter-Dynkin_diagram_symbolic_image. I hope you will have the respect to refrain from reverting my reverts until this is discussed further. Going offline. Tom Ruen (talk) 09:09, 6 March 2010 (UTC)

Just to put my view. In my browser the svg come across nice and anti-aliased, with the png nasty and pixellated. This is a matter of personal taste, for example Tom appears to prefer the opposite. I agree with Koafv that the discussion on Dynkin diagrams is inconclusive. The image format policy/guidline is clear - use svg. There is always the chance that a future svg-to-png converter might improve matters, and in the long run when all significant browsers support svg, the converter will be dropped anyway. I am firmly in favor of compatibility with the future rather than the past, and that means svg. That also puts me firmly on the side of Koavf. -- Cheers, Steelpillow (Talk) 17:31, 6 March 2010 (UTC)

When someone can make ALL the CD diagram symbols I need without ugly antialiasing, I'll think about supporting a total conversion. Until then it's stupid to convert a fraction of them, especially when the existing set still can't make all the graphs that are needed.

And as for ugliness, I see no reason that vertical lines need antialiasing! Tom Ruen (talk) 23:48, 6 March 2010 (UTC)

Some pros and cons. If all the svg diagrams are not ready yet, then it is debatable - when I commented earlier, I did not understand this possibility. It might be easier to complete the svg set than to revert to png, or it might not. I guess that in the short term the main editor (Tom?) deserves to make the call. However, we should reach some kind of consensus before any mass-reverts of another editor: three strikes and all that. In the long term, my previous comments stand. -- Cheers, Steelpillow (Talk) 20:51, 7 March 2010 (UTC)

Just to add my thoughts. I've come here as the formatting on half a dozen pages I'm watching is currently broken as in particular doesn't line up with the other diagram elements. On looking at the page histories I could not easily revert them so came here, but if the images can't be fixed they should be removed.--JohnBlackburne^words_deeds 14:25, 7 March 2010 (UTC)

Not sure which pages you refer to, but CD_4.svg is a very simple text file set to 30px high, creating a lot of white space below the 4. Maybe that's a bug and it should be less? -- Cheers, Steelpillow (Talk) 20:51, 7 March 2010 (UTC)

It was on a handful of polytope pages, but the problem's also visible at Coxeter–Dynkin_diagram#Infinite Coxeter groups. Some of the CD_4 images, in that table and the one below, have been changed to svg and where they've been changed it looks broken. E.g. In the following copied from there:

None of the lines and dots meet.--JohnBlackburne^words_deeds 20:58, 7 March 2010 (UTC)

Fixing It would be relatively easy to fix this matter. E.g., if you wanted to make the "4" lower, you can amend it as follows—change:

<?xml version="1.0" encoding="utf-8"?>

<svg width="11" height="30">

<line stroke="#000000" stroke-width="2" x1="0" y1="6" x2="11" y2="6"/>

<text x="1" y="18" font-size="12" font-weight="500" font-family="Bitstream Vera Sans">4</text>

</svg>

to:

<?xml version="1.0" encoding="utf-8"?>

<svg width="11" height="30">

<line stroke="#000000" stroke-width="2" x1="0" y1="8" x2="11" y2="8"/>

<text x="1" y="20" font-size="12" font-weight="500" font-family="Bitstream Vera Sans">4</text>

</svg>

As you can see from the above, the "y" values were made higher, thus making the image start at a lower place. Alternatively, you can readjust the dot image. This doesn't seem particularly labor-intensive or difficult, even for someone such as myself who knows very little SVG. That having been said, since I am ignorant by my own admission, please correct me if the above code is somehow mistaken. —Justin (koavf)❤T☮C☺M☯ 21:54, 7 March 2010 (UTC)

I have no idea: I've only created SVG with image editors and have no experience of looking at them as source, so I suggest you are better able to fix it than I. But until then can the changes be reverted as they have completely broken the formatting wherever it's included? --JohnBlackburne^words_deeds 22:19, 7 March 2010 (UTC)

Had a quick hack at the Commons source for the dodgy one . Hope it's a bit better now. -- Cheers, Steelpillow (Talk) 18:17, 8 March 2010 (UTC)

It's a bit better, but it still looks wrong (slightly offset and the '4' is too small), though not as disconnected and broken. But the PNG version is still far better and should be put back. Note: I had a look at some of the other 'number over line' SVGs and they also look wrong, in case anyone was planning to update them soon.--JohnBlackburne^words_deeds 18:24, 8 March 2010 (UTC)

This is NOT the correct solution. The correct solution is to use the correct file! Tom Ruen (talk) 22:11, 7 March 2010 (UTC)

Correct files You know the image upload policy and you know that some files have been converted to superior SVGs. If you have a constructive change to make (e.g. finishing the conversion from PNGs for all of these files), I would be happy to have your input. Right now, as best as I can tell, you are simply saying that I am wrong and I have no idea what I'm talking about. Rather than tell me what is true and what I should know, you are apparently taking a break. I don't see how this is helpful. —Justin (koavf)❤T☮C☺M☯ 03:13, 8 March 2010 (UTC)

Cooperating with someone who chooses to act on things he doesn't understand doesn't sound very fun to me. There was no need to push on this update at this time, and it was your choice to push when there's surely a million other things you could work on once you found resistance. Read at Talk:Coxeter-Dynkin diagram if you want to figure out what's wrong. (Clue - there's two sets of symbols and you've cross-mixed them.) Happy editing. I needed an excuse to get away from Wikipedia. Maybe I'll get my taxes done sometime in the next weeks and I'll feel more patience. Tom Ruen (talk) 04:29, 8 March 2010 (UTC)

Reversions I waited 24 hours for comment and then reverted, as I wrote above and per the input that was given. As Steelpillow writes above (after I did that), he's looking for some consensus for further changes. For what it's worth, as someone who knows very little about SVG but has made a few images before, it shouldn't be terribly difficult to make these small diagrams in SVG and if it's too labor-intensive for any one user to do in short order, it can be done by a couple of SVG-savvy editors in a matter of minutes. Choosing one at random, File:CD ring.svg is composed entirely of: <svg width="11" height="30"> <circle fill="none" stroke="#000000" stroke-width="1.2" cx="5.5" cy="6" r="5"/> <circle cx="5.5" cy="6" r="3.2"/> </svg> and that's pretty complex for these files. Again, I am not the most knowledgeable user when it comes to SVG, but I would be willing to give it a go if no one else is willing or able to make these files. I'll check this talk periodically, but I'm not actually watching it, so if it's important to reach me as soon as possible (doubtful), please use my talk or e-mail. —Justin (koavf)❤T☮C☺M☯ 21:44, 7 March 2010 (UTC)

I'm giving up. If Koavf wants to play god, I assume he's smart enough to correct his mistakes. Tom Ruen (talk) 21:33, 7 March 2010 (UTC)

Playing God? Tomruen posted the above while I was posting the comment above that. It's sad to me to see that he (you) is insisting that I'm "playing God" by simply trying to apply guidelines in a consistent manner. What you keep on insisting are "mistakes" is honestly beyond me; the only problem that you have noted this entire time is that these SVGs are rendered in a fuzzy way to you and that's hardly a mistake of mine. —Justin (koavf)❤T☮C☺M☯ 21:50, 7 March 2010 (UTC)

You have no idea what you are talking about. Please read the descriptions on the talk pages before you change the files! Tom Ruen (talk) 21:58, 7 March 2010 (UTC)

You're not the only one who sees it fuzzy. 4 T C 06:40, 9 March 2010 (UTC)

Summary to date

The story so far

• User:Tomruen has been working on .png graphics for these symbols - a bit like lego, using several graphics to build each symbol. He's part way through because there are so many.
• User:Koavf has been converting them to .svg, which is politically more correct (i.e. im line with policy), but two problems have arisen:
  1. Wikipedia renders svg to png for serving to the client, and has not been doing a very good job with these small images.
  2. Koafv has not been doing a consistent job either, with mistakes in file links, file names, and inconsistencies in the svg code (some are created by graphics editors, possibly by someone else, while others are hand-crafted in a text editor).

Comments/votes

The big question

Do we try to fix the svg system, or revert to Tom's png system?

• I believe that in such a gray situation, TomRuen as chief maintainer gets to make the call - and that would no doubt be for png. -- Cheers, Steelpillow (Talk) 19:25, 9 March 2010 (UTC)
• Go back to PNG. As per the above discussion, and the problems already apparent, the SVG's not ready for primetime yet. When there's a complete set and the gliches in CD_4 and others are fixed then revisit it.--JohnBlackburne^words_deeds 19:36, 9 March 2010 (UTC)
• I'd like to hear what technical problems stand in the way of good SVGs and rendering them well in Tom's environment, and offer any advice I can in solving them. If the problems are insuperable or would take a lot of effort, then we can consider switching back to PNG for the time being. --JWB (talk) 15:51, 10 March 2010 (UTC)

  The underlying technical issue is that the svg-to-png converter's idea of where its pixels should fall does not align with the edges of the individual objects. For these very small graphics, the result is that the converter's anti-aliasing filter creates fuzzy, unsatisfactory png images. The whole idea behind moving to svg is to avoid such problems, and here it is clearly failing to deliver. Careful positioning and styling of the individual graphic objects might (or might not) improve the conversion quality to an acceptable level, but doing this across the whole set would be a mammoth and painstaking task. The main svg protagonist has noticeably failed to engage. Far better anyway to improve the conversion algorithm, but we mere mortals have no control over that. This is why I am willing to let the main editor revert to png for the time being, as he is confident of producing adequate images that way. Hope that's clear enough? -- Cheers, Steelpillow (Talk) 21:04, 10 March 2010 (UTC)

  JWB – rendering low-resolution raster images of vector graphics is a hard question, due to trying to line up to a grid. See font hinting for the issues in fonts, and note that this is a major issue in computer typography and the subject of several patents. Simply, manually rendered PNGs (either black-and-white or manually anti-aliased) will be better than automatically rendered SVGs without years of work (on both the renderer and the SVG files) – it’s very, very hard. Thomas Rickner spent a great deal of effort on getting Verdana to look right in the 1990s, and Meiryo (current Microsoft Japanese gothic font) uses bitmaps at low resolutions – and this after 2 years of work. For all practical purposes, PNGs are going to be better for screen use. —Nils von Barth (nbarth) (talk) 03:11, 12 March 2010 (UTC)

• PNG – agree exactly with Steelpillow and JohnBlackburne above:
  • SVG files are incomplete and have errors (not ready for prime time),
  • image quality for small rendered SVGs is hard to do right, and in any case anti-aliasing (vs. black-and-white) is debatable,
  • primary maintainer (TomRuen) prefers PNGs (in current state), and has demonstrated willingness to maintain and work on them.
  • Current situation is not broken and works fine – it’s not ideal (ideally we’d have good SVGs too), but it works, and should not be broken in pursuit of improvements.

  As and when SVG files are as complete and bug-free as the PNGs, and with SVG rendering issue addressed or at least discussed, then we can revisit – as I understand it, TomRuen concurs with this view (comment of 23:48, 6 March 2010).

  Issues – SVG is in general preferable – for example, when making printouts or PDFs of images (Wikipedia is not just viewed on-screen/in web browsers) – but rendering of small black-and-white vector images is a hard question: see Font hinting for issues (the field has numerous patents). Further, current renderer has serious problems for this application – as TomRuen notes, vertical lines shouldn’t have fuzzy edges. (OTOH, I prefer the antialiased circles to the black-and-white ones, but this is debatable.)

  Thus, both PNGs and SVGs of these are useful and ultimately necessary; it may be possible to replicate the PNGs with carefully written SVGs and careful rendering, but this is an Augean task (as Steelpillow states), likely impossible to do in a satisfactory way, and should not be prioritized: use PNGs for on-screen, and SVG for print-outs.

  Thus, I’d suggest: build SVG files in parallel with PNG files – for use at larger image resolutions/sizes, as in printouts and larger screen sizes – but do not mark the PNG files as “superseded” by the SVGs, due to the problems raised (they should link to each other, but not suggest that SVG is preferred). Once we have a good set of SVGs (complete, bug-free), then we can discuss what to use in general, using templates or bots as necessary.

  Long-term, I’d suggest that we use PNGs for low-resolution, and SVG for high-resolution – rendered SVGs will realistically never be as good as manually drawn PNGs at low resolution.

  —Nils von Barth (nbarth) (talk) 03:11, 12 March 2010 (UTC)

p.s. I was curious if PDF files created from Wikipedia articles would have better graphics as SVG over PNG, and found (at least) the SVG CD symbols were wrongly sized. So this is unrelated issue since I've seen other failures of the PDF output, so I'm assuming it is still experimental feature. . Tom Ruen (talk) 04:27, 12 March 2010 (UTC)

Oh dear – that’s really bad. Thanks for checking Tom, instead of leaving us in speculation. As PDF output of SVGs is that bad, I really think we should stick with PNG in articles for now (and hope SVG → PDF gets sorted).

SVGs may still be useful for larger diagrams (as and when useful), and will help longer-term, but for the current common use, PNGs seem the only ones that produce consistently good output.

—Nils von Barth (nbarth) (talk) 11:50, 12 March 2010 (UTC)

That's a pretty clear consensus to keep png. Although it goes against my original thoughts, I am now persuaded. I have posted a summary on Koavf's talk page, so hopefully things can begin to return to the way they were. Many thanks to all contributors. -- Cheers, Steelpillow (Talk) 21:01, 12 March 2010 (UTC)

Hearing no reply from User:Koavf, I restored most of the PNG images, and cleaned up the tables in the graphic section (moved to the top). Apparently God needs clearer instructions, so next time he comes back, perhaps he'll understand what he's doing?! More documentation/examples is useful of course!

So my thought is if/when there's an SVG conversion, it should be complete, rather than mixing PNG/SVG diagrams. It should have all identical names (I removed the CDV_*.svg images which were supposed to be named CDW_).

The main categorical issue of avoiding SVG for now is the PDF export from Wikipedia articles makes HUGE SVG images, so either there's a bug in the PDF converter OR some missing information in the SVG files.

I tried to add deadlink SVG images in the documentation section for the ones that don't exist. BUT since they are all potentially experimental, I might end up replacing some of the nonlinear ones anyway, so it seems a waste of someone's time to TWEAK nice SVG images and have me replace them with something else!

The biggest category for replacement is the triangle cyclic graphs, useful in star uniform polyhedra, with fractions, but hard to make. I'm thinking of a linear graph PLUS a "jump rope" loop below to show the cyclic connection.

Okay, hopefully back to my wikibreak, hopefully earned since I spent 5-6 hours this weekend on cleanup! Tom Ruen (talk) 09:36, 15 March 2010 (UTC)

{{svg}} tags

There are still {{SVG}} codes on the PNG element images, so I expect there'll be periodic heroes who will come along. If I remove the template, I'll get complains, and if I leave it, its a prod for potentially hasty action. I don't have a solution since SVG is the wiki gods' favorite image child. Tom Ruen (talk) 09:36, 15 March 2010 (UTC)

I'd suggest you remove the tags, as they are no longer applicable. If any mistaken evangelists still arise, direct them to this discussion, Talk:Coxeter–Dynkin diagram#SVG vs PNG, and if that doesn't work give us all a shout. Soon they'll end up as crestfallen as I did. -- Cheers, Steelpillow (Talk) 19:29, 15 March 2010 (UTC)

Switch to the modern notation for Coxeter-dynkin diagrams

What I really dislike much more than SVG images (sorry for the pun ;) is the fact that this article uses the names for the diagrams from Coxeter's original book. This may be the "historically" right terminology. But to my knowledge, virtually everybody in the field is using the "modern" terminology. Which was introduced by Bourbaki (or rather, Jacques Tits) and has been in usefor several decades. Experts in the field (like Humphreys, I.e. what is called B_n in this article is called D_n elsewhere; B_n and C_n coincide; and more. The [Coxeter group] page lists both for comparison. IMO it's fine to mention the old notation in a "history" section, but for practical work, only the modern names should be used -- else beginners will learn the wrong notation if they read up here, and experts will be highly confused by the mixed up names. I am willing to make the required changes, too. BlackFingolfin (talk) 12:43, 16 August 2008 (UTC)

I'm in the process updating polytope articles to reference the newer names. Sorry things have to remain confusing for a while until it is completed. Tom Ruen (talk) 16:11, 27 August 2008 (UTC)

Hold on, you mentioned Humphreys, whose text I've got in front of me at the moment. I've noticed that in this book, the labels B~_n and C~_n are the other way round from in this article. Which one's the convention? 137.205.31.198 (talk) 20:46, 14 December 2008 (UTC)

Sadly, I've seen references both ways, and I don't know which ought to be considered standard. I'll look again when I have some time, or if you want to look more, feel free to change it. Tom Ruen (talk) 21:53, 14 December 2008 (UTC)

Okay, I confirmed that source, and swapped them. Tom Ruen (talk) 22:02, 14 December 2008 (UTC)

Just made a similar swap in the Coxeter group article. I don't know how to change PNG files though, so right now there is one picture in each article that disagrees with the changes just made. 137.205.31.198 (talk) 14:12, 16 December 2008 (UTC)

I changed the graphic . Hopefully the author won't object! Tom Ruen (talk) 16:36, 16 December 2008 (UTC)

Singularity Theory

The Dynkin diagrams are used in singularity theory. Arnold proved the connexion between the simple Lie groups and certain singularity types. As a result, Dynkin diagrams turn up quite a lot in the literature; although I must confess that I don't totally understand. I think it would be a nice addition to the article. Dharma6662000 (talk) 23:32, 19 August 2008 (UTC)

Redirection Fault

I typed in 'Dynkin Diagrams' and was redirected to the article called 'Root system'. They use Dynkin diagrams to classify root systems, but surely the redirect should have been to this page and not 'Root system'. How does one chanhe redirects? Dharma6662000 (talk) 03:01, 20 August 2008 (UTC)

This has been fixed, and indeed now Dykin diagrams have their own page; thanks for the note!

—Nils von Barth (nbarth) (talk) 07:20, 1 December 2009 (UTC)

Dykin diagrams? Is a redirect needed? —Tamfang (talk) 18:21, 1 December 2009 (UTC)

Tom, thanks for correcting my spelling and thereby illustrating that my point was a bit obscure. Nbarth left out the first 'n', as did someone in the main article (which I previously corrected); if it happens more than once, perhaps we ought to expect it to happen again, and anticipate it with a redirect. Guess I'll be bold. —Tamfang (talk) 06:47, 2 December 2009 (UTC)

Image and text formatting

Can someone try to move the lead images to a gallery below the lead text, and maybe put a smaller image next to the lead paragraph? The current layout looks terrible in some browser configurations, since the images completely squash the lead text. I have tried to do this myself, but I couldn't get the <gallery> or the {{gallery}} template to work with these oddly-sized images. Thanks, siℓℓy rabbit (talk) 13:03, 2 December 2008 (UTC)

Any better in a table? I know it's rather dense! Tom Ruen (talk)

Incorrect headings in lead image

The image File:Coxeter-dynkin plane groups.png contains a couple of errors/inconsistencies in its headings. I don't have access to SVG editing facilities; perhaps someone could update it?

• The heading ' I^~₂×I^~₂ (W₂×W₂)' should read ' I^~₁×I^~₁ (W₂×W₂)'.
• The heading ' B^~₂ group (R₃)' should be updated to ' C^~₂ group (R₃)' in line with Tom Ruen's recent changes to the rest of the article.

Thanks! Robert Stanforth (talk) 22:28, 24 December 2008 (UTC)

Corrected! Thanks for the careful look. (I just edited with MSPaint incidentally!) Tom Ruen (talk) 22:35, 24 December 2008 (UTC)

Heading in lead image may still not be correct

The diagram describing 30-60-90 triangle is an affine version of an exceptional graph commonly denoted by $G_{2}$ (although $I_{2}(6)$ would make sense as well). So I would expect it denoted by ${\tilde {G}}_{2}$. I have not encountered the notation $H_{2}$ but other diagrams which use H have a 5-fold symmetry.--Jhrabows (talk) 08:02, 15 March 2010 (UTC)

This source uses H3,H4, so H2 fits with that set, and G~2 for [6,3], so you're right, I think it should be G~2! I changed it! Tom Ruen (talk) 08:19, 15 March 2010 (UTC)

James E. Humphreys, Reflection Groups and Coxeter Groups, Cambridge studies in advanced mathematics, 29 (1990)

Questioning the numbers

I was looking at the text below the pictures of the fundamental simplexes:

C~3 fills 1/24 of the cube. B~3  fills 1/12 of the cube.
 A~3 fills 1/6 of the cube.

The pictures are beautiful, by the way. They are rarely mentioned in the literature (to my surprise). The numbers below seem to be off though. The C~3 simplex partition of the cube corresponds to the partition of one square face into 8 right triangles. Since a cube has 6 faces the simplex is 1/48 of the cube. Incidentally the fundamental simplex is the intersection of the cube with a Weyl chamber, so 48 agrees with the formula for the Weyl chamber count for C3: $2^{3}*3!$. —Preceding unsigned comment added by Jhrabows (talk • contribs) 01:34, 29 March 2010 (UTC)

Thanks! You're right. I'll change the paragraph. Tom Ruen (talk) 07:40, 29 March 2010 (UTC)

Mystery.

Exactly why Coxeter's 1935 paper in 'twelve essays', is relegated so low in the references, when it is one of the clearest treatments on the subject, remains a mystery. In any case, the correct terminology is to use 'nodes' and 'branches' for the points and edges of the graph. This prevents confusion with the points and edges generated in the polytope.

Coxeter seems to have invented both the Schläfli symbol, and the Coxeter-Dynkin diagram fairly early in the piece. However, a great number of others had found the schläfli symbol before him. His graph dates from the early 1930s, while those of de Witt and of Dynkin date from 1940s. None the same, it's pretty clear: a point represents a free operator under the relation XX = 1, and the branch is a relation between two non-comuting operators: eg an unmarked branch is ABA=BAB. Where no branch exists, AB=BA. This is what happens in both Lie groups and with mirrors. Mirror groups are, after all a kind of Lie group.

Stott's notation is to use symbols for expansion against the vertex, edge, hedron, ... of a polytope, from which one can derive most of the uniform polyhedra. For example, a tCO is an e_1 C (ie edge-expanded cube). Wythoff made the same construction by use of named mirrors, explicitly reversing Stott's c_0 to e_0 (so working from a point, rather than a polytope). The notation remains unaltered under Coxeter, where the operator precedes the symmetry.

When Coxeter read Wythoff's paper, he already understood the diagram, but realised how to decorate the thing to make polytopes. Since he already knew how to evaluate subgroups (by removing nodes and evaluating the residue order), the final notation by him is simply Wythoff's "t" notation (the real thing, not the later one) to Schläfli's symbol, eg t_1,2 {3,3,5}.

It never becomes an inline representation of the graph, such as i use in my polygloss, eg o3x3x5o for o--@--@-5-o. The main polytope listed in the twelve-essays paper ends up as an awful thing, although i write it as x3x3x3x3x3x3xBx.

--Wendy.krieger (talk) 10:57, 29 March 2010 (UTC)

I changed the graph terminology to nodes and branches, as Coxeter uses. It would be nice to document Stott's notation somewhere, unsure where. Tom Ruen (talk) 23:35, 30 March 2010 (UTC)

Flaws of this article

This article has severe issues from a mathematical point of view. IMHO it needs a major overhaul. I would go ahead and "fix" at least some those, if it wasn't for the fact that my fix would consist in deleting half of this article, and rewriting the other half... This might be a bit controversial :), so I figured it is better to start a discussion first.

So, let me describe some of problems I perceive, and how I would suggest addressing them (and I am willing to work on that, too).

• What this page describes is actually is an extension of what is usually referred to in the literature as Coxeter(-Dynkin) diagrams; namely the circled nodes and empty-nodes seem to be non-standard extensions. This should be made clear, and ideally also clear references be given to literature where this extended notation is also used/introduced (if any exists).
• Several distinct mathematical objects are being confused and mixed-up in the article. E.g. no clear attempt is made to distinguish between Coxeter(-Dynkin) diagrams; the Coxeter groups they define; and the polytopes that have these groups as symmetry groups. This is IMHO highly confusing. Here, an effort must be made to distinguish between the various objects.
• I can only guess that this mixing of terms is also justification for why there are three sections on Coxeter groups. These seem out of place here, and could probably be replaced by a single reference to the Coxeter groups page.
• If, however, there are very good reasons to keep them (which? please explain!), then they need a lot of work. For example, the table under "Finite Coxeter Groups" refers to simple and exception Lie groups, without any explanation as to why.
• Several terms are used without introduction, e.g. "polychoron" (a term I never saw before, even though I work in this field :), "Dynkin graph", "finite Dynkin graphs", etc.
• The whole thing of talking about "mirrors" all the time feels very strange to me. It seems to be an attempt to make things somehow "simpler" and "easier", but IMHO it doesn't really simplify anything for non-experts, and at the same time confuses experts with non-standard notation.

Finally, there were/are some outright false statements on this page, but I'll try to fix those directly now. BlackFingolfin (talk) 01:45, 30 December 2010 (UTC)

The rings/holes are standard markups that Coxeter used on Coxeter graphs to identify specific uniform polytopes/honeycombs. The most collected source I have is:

• Kaleidoscopes: Selected Writings of H.S.M. Coxeter, editied by F. Arthur Sherk, Peter McMullen, Anthony C. Thompson, Asia Ivic Weiss, Wiley-Interscience Publication, 1995, ISBN 978-0-471-01003-6 [1], Googlebooks [2]

Tom Ruen (talk) 02:19, 30 December 2010 (UTC)

The original work of Coxeter is certainly interesting from a historical point of view. However, I wouldn't call it a standard reference, to the contrary: his notation in general is far from being standard in modern mathematics (including the names he used for the Coxeter groups, which differ from what mathematicians have been using for the past 50 years, i.e. since the advent of Bournaki). So, I wouldn't really consider a book that presents selected writing by Coxeter as representative for modern day mathematics. But maybe you know some other? I have about a dozen math books (part of my research library, I work in this field) from the last 30 years sitting on my shelf here which introduce Coxeter groups, Coxeter/Dynkin diagrams, etc. in one way or another, and none presents this notation. Nor have I ever encountered it in a research article. BlackFingolfin (talk) 13:58, 30 December 2010 (UTC)

Glad to know I'm not the only one who has a problem with Coxeter's notations. — Did you mean Bourbaki? —Tamfang (talk) 03:38, 31 December 2010 (UTC)

That's good to know. Are any of those books visible in Googlebook copies for examples? Do any of your books explore uniform polytopes and tessellations? John Conway's book "The symmetries of things", 2008, uses this identical notation for uniform polytopes. Anyway this subject been the primary purpose I'd have for my work with Coxeter-Dynkin diagrams. Tom Ruen (talk) 21:31, 30 December 2010 (UTC)

Perhaps the examples on polytopes/tessellations should be moved to uniform polytope. Then the ring/hole notation stuff can be focused here in a single section as an application. This article is very much related to Coxeter group, so contents there should also be considered in how things are changed here. Tom Ruen (talk) 22:44, 30 December 2010 (UTC)

pure reflective symmetry

“ Every uniform polytope with pure reflective symmetry (all but a few special cases have pure reflectional symmetry) can be represented by a Coxeter-Dynkin diagram with permutations of markups. ”

I don't know what pure reflective symmetry means, but I believe the grand antiprism has the reflective symmetry of a 5x5 duoprism. —Tamfang (talk) 05:14, 4 January 2011 (UTC)

The article Grand antiprism says its symmetry [10,2+,10]. So that + implies the existence of 2-fold rotation symmetry, so its reflectional fundamental domain ought to have 2 copies of the generator point. How can this be better worded? Tom Ruen (talk) 07:15, 4 January 2011 (UTC)

"Every uniform polytope which can be generated by reflections of a single vertex"? — Do you want to cover hollow rings here? —Tamfang (talk) 20:01, 4 January 2011 (UTC)

noncompact groups

I'm delighted to see them listed at last, but: is not on my lists, because {6,6} is itself hyperbolic. (Remove a mirror from any of the other hyperbolic groups here and you get a flat or spherical group.) In compensation, the 4343 loop is missing. —Tamfang (talk) 01:56, 5 January 2011 (UTC)

Thanks for the look! I corrected first case, should have been 4s not 6s. The 4343 loop is on the compact list above. Tom Ruen (talk) 02:11, 5 January 2011 (UTC)

D'oh! —Tamfang (talk) 03:04, 5 January 2011 (UTC)

What's the source? —Tamfang (talk) 06:41, 5 January 2011 (UTC)

Incidentally — In my own notes I classify the hyperbolic groups by how many ideal vertices (i.e. at infinity) the fundamental simplex has:

space	number of groups with n ideal vertices
	0	1	2	3	4	5	6
H3	9	9	9	2	3
H4	5	5	2	2	0	0
H5	0	4	3	2	1	1	1
H6	0	3	0	0	0	0	0
H7	0	4	0	0	0	0	0
H8	0	4	0	0	0	0	0
H9	0	1	1	1	0	0	0

This distribution surprises me. Perhaps I've erred. —Tamfang (talk) 06:01, 5 January 2011 (UTC)

Cool table. I've never seen such a thing, or understood if I did!

Source: James E. Humphreys, Reflection Groups and Coxeter Groups, Cambridge studies in advanced mathematics, 29 (1990), p141-144 [3] (Googlebook copy, but skips needed pages) I'll check my list one more time from the book.

If you want a 238 group listing on hyperbolic Dynkin diagrams, here's one that claims completeness.http://arxiv.org/abs/1003.0564] Dynkin has directed branches and disallows edge orders besides 3,4,6 (and some affine ones). Tom Ruen (talk) 07:01, 5 January 2011 (UTC)

p.s. Anton, Here's a paper that shows some infinite (noncompact) hyperbolic tilings (alternate colored fundamental domains), [4] - 9 familes: (∞,3,2)...(∞,∞,∞). It would be good to get some hyperbolic tiling images in these families. Do you know a way to generate them? Tom Ruen (talk) 05:26, 6 January 2011 (UTC)

What I do is define three mirrors, find the hyperboloid coordinates of each pixel, and count how many reflections it takes to get into the 'template' triangle. —Tamfang (talk) 08:17, 6 January 2011 (UTC)

Results of Tom's question can be seen at commons:User:Tamfang. —Tamfang (talk) 05:36, 16 March 2011 (UTC)

Template optimisations

Noticing that this page takes a long time to load I had a look at the template, {{CDD}}, which is creates the diagrams used on the page, and saw it uses a quite large 'if' block for such a simple task. This is probably unavoidable though given the limitations of the parser. Looking to improve this I thought of redoing it in Lua. I first wrote some documentation: Template:CDD/doc, to familiarise myself with it, and today got round to creating a module.

The module is here

Module:CDD

and is quite simple and straightforward for a Lua module. I used the sandbox

Template:CDD/sandbox

to test it; that is even more straightforward. And tested it first on the testcase page

Template:CDD/testcases

and then on a copy of this page to compare performance.

User:JohnBlackburne/CDD (deleted as module is live)

It seems to work fine and is faster, though not massively so. On comparing speeds this page has CPU and Real time usage of 27.078 and 30.972, while the copy of this page has times 15.561 and 20.797. So it takes about 2/3 the time with much less CPU load. Not as big a difference as I hoped, probably as the number of instances of the template is as significant as its complexity. But big enough to be noticeable and so worth it I think.

The other benefit is it's far more maintainable: Module:CDD is much simpler and so easier to maintain, while the Lua system's error checking is much easier to work with. This will make it easier to add other features or adapt it for other uses, should that be needed in the future.

I would suggest therefore updating {{CDD}} from its sandbox to the main template.--JohnBlackburne^words_deeds 22:13, 3 December 2013 (UTC)

Hi John, outside my knowledge, but if it works, sounds good to me! Tom Ruen (talk) 22:17, 3 December 2013 (UTC)

I've gone ahead and updated the template from the sandbox version: [5]. By far the greatest use of it is on this page, which I tested the template on by copying the page. To do this for many more pages would be tedious and create a lot of unwanted test pages needing tidying up; better to update the template and keep an eye open for any problems or issues. Hopefully though there are none: it's not that complex a template and is so heavily used on this page that it seems likely any problems would show up here.--JohnBlackburne^words_deeds 23:08, 9 December 2013 (UTC)

Sounds good. Are there instruction for how to edit and "recompile" the new code? Tom Ruen (talk) 01:07, 10 December 2013 (UTC)

I think it works like parser functions: when the page is changed, or previewed, or purged, it runs the code, after which it's cached. I don't think it immediately does it when included templates are changed but they seem to propagate at some point so it should be reflected in all pages sooner or later. If you preview a page the templates used are listed below so you can see it's being used.

The code is the first link above: Module:CDD. I've tried to format it nicely and added code comments (two things that are much trickier with parser functions). It's not locked or protected so anyone can edit it. I'd not recommend that to anyone unfamiliar with both Lua and modules, though anyone who had got their head around the arcane world of parser functions should find Lua very straightforward.--JohnBlackburne^words_deeds 01:41, 10 December 2013 (UTC)

Cool. So the same could be done for Template:Dynkin, used widely at Dynkin diagram. Tom Ruen (talk) 02:59, 10 December 2013 (UTC)

Yes, and I finally got around to doing it, see Module:Dynkin. Much easier as it was mostly copy and paste from {{CDD}} with quick tests and documenting as I went along. Is there a list of parts, i.e. instances of File:dyn-, so I can add them to the documentation or do I have to look them up (I think I compiled the list for {{CDD}} from Commons)?--JohnBlackburne^words_deeds 01:03, 23 April 2014 (UTC)

Thanks John! I've not worked with them for a while, but there are not nearly as many elements since no markups. Tom Ruen (talk) 05:06, 23 April 2014 (UTC)

I've done it now; not too hard except for remembering how – Commons has a 'download this files' link in one of its popup menus which downloads wget.exe and a list of file paths, which you can then convert to a list of table entries using search and replace. Good to have them documented in one place, and if I make a note now of how it was done if it's needed again I'll have a reference.--JohnBlackburne^words_deeds 14:04, 23 April 2014 (UTC)

Thanks John. I'm curious if something changed recently with the CDD template, that is this {{CDD||node}} cases problems now, but didn't befor, shows as "". The extra pipe isn't needed, and cases can be cleaned up, but if your script can just ignore that case, just as well. Tom Ruen (talk) 20:31, 24 April 2014 (UTC)

Fixed it. One could argue it would be better to clean them up but it's an easy enough fix. If cleaning up is an issue so e.g. there's a problem with many instances of it then it would be easy to add a tracking category to the module, so it e.g. puts all instances with missing/broken params into a category as happens with citation template errors. The nice thing about Lua is such changes are straightforward to do.--JohnBlackburne^words_deeds 21:11, 24 April 2014 (UTC)

Missing information

Unfortunately I don't have the background to add it, but there seems to be a great amount of detail missing on the actual use/meaning of the symbology in the diagrams, used extensively throughout the geometry pages; Mostly notably the ring and hole node symbols. Hoping this note catches the attention of some with the proper skills 74.213.201.51 (talk) 16:40, 22 March 2014 (UTC)

There's information in this section Coxeter-Dynkin_diagram#Application_with_uniform_polytopes. Tom Ruen (talk) 19:22, 22 March 2014 (UTC)

Error in definition of affine type of Schläfli matrix

There is a contradiction in: "The eigenvalues of the Schläfli matrix determines ... affine type (all non-zero, at least one is zero) ... ." (Unless the affine type does not exist!)

Over on Coxeter group, the statement is: "... (non-negative, at least one zero) ...", which I think is right - but I'm not expert enough to do this edit.

Perhaps someone can suggest a reference for this definition which can be added to both pages.

Stephen.G.McAteer (talk) 01:21, 14 January 2015 (UTC)

Thanks for the catch. Nonnegative definitely makes more sense. I'll check for some references. Tom Ruen (talk) 01:32, 14 January 2015 (UTC)

k-face in "section Application with uniform polytopes"

Read:

Two rings correspond to the edges of simplex ... . In general k-rings generators are on k-faces of the simplex, ...

Article "k-face" says:

• 4-face – the 4-dimensional 4-polytope itself
• 3-faces – 3-dimensional cells (polyhedral faces)
• 2-faces – 2-dimensional faces (polygonal faces)
• 1-faces – 1-dimensional edges
• 0-faces – 0-dimensional vertices

So, Two rings must correspond to 2-dimensional face, but not to 1-dimensional edge

Jumpow (talk) 22:05, 29 September 2015 (UTC)

It is a bit confusing, wording should be clarified. The fundamental simplex is different from the polytope generated. The faces of the fundamental simplex don't correspond to faces of the polytope. Looking at a tiling, {4,4} is a square tiling polytope with a 45-45-90 fundamental simplex (triangle). It has Coxeter diagram . With one ring, the vertex at one corner of the fundamental simplex. Then , a truncated square tiling, has its vertex on one of the edges (legs) of the 45-45-90 triangle simplex, and has the vertex on the hypotenuse edge. Finally , 3 rings has the vertex in the interior of the fundamental triangle. Tom Ruen (talk) 01:32, 30 September 2015 (UTC)

A chart like this shows it on a fundamental triangle: Tom Ruen (talk) 01:35, 30 September 2015 (UTC)

Explanation do not understand... With one ring, the vertex at one corner of the fundamental simplex - dimension of point is 0 or 1? Two rings = edge, dimetion is 1 or 2? With 3 rings dimension is 3? Symplex is triangle, so has dimention 2. Or 3, according your explanation? Jumpow (talk) 15:08, 6 October 2015 (UTC)

Yes, if the generator point is on the corner of the fundamental simplex, there is one ring (one active mirror). But maybe part of the confusion is dimensions. Its easier to see in tilings than polyhedra. So a convex polyhedron can be seen as a tiling of the sphere, and the fundamental simplex is a triangle. Tom Ruen (talk) 16:17, 6 October 2015 (UTC)

No. Point has dimention 0, line - dimetion 1. So Point MUST be 0-face = 0 rings. In your example of tilings fundamental simplex is triangle, and its corners has dimention 1? And edges dimesion 2? Jumpow (talk) 16:56, 6 October 2015 (UTC)

There's no such thing as "zero rings". A ring means a generator point is OFF the mirror. There's no way for a generator to be off ALL mirror boundaries of a triangle. If its at the corner, its ON two mirrors and OFF one mirror, so one active ring. Tom Ruen (talk) 17:15, 6 October 2015 (UTC)

According sentence In general k-rings generators are on k-faces of the simplex, 1-ring generator is on 1-face, on edge, not on corner. So sentence in article is very confusing. It must be removed or transformed (or expalained). Jumpow (talk) 17:34, 6 October 2015 (UTC)

I see, I corrected as k-rings generators are on (k-1)-faces of the simplex Tom Ruen (talk) 17:46, 6 October 2015 (UTC)

Another small question... Word nontrianglar - may be it must be nontriangular? (engish is not my native language, sorrry). Jumpow (talk) 16:56, 6 October 2015 (UTC)

Fixed typo.

Another confusing sentence... or prisms or other polytopes with all edges having dihedral angles as π/n for n=2,3,4.... In article Dihedral angle: It is the angle between two hyperplanes. So, how we measure dihedral angle between edges? Jumpow (talk) 17:34, 6 October 2015 (UTC)

Every edge (for 3D fundamental domains) represents the intersection of two hyperplanes. The dihedral angle is the angle between hyperplanes sharing that edge. Tom Ruen (talk) 17:40, 6 October 2015 (UTC)

Viberg - misspelling?

in Hyperbolic Coxeter groups:

and infinitely many finite-volume Viberg polytopes for dimension up to 19

May be Vinberg? Jumpow (talk) 15:49, 5 October 2015 (UTC)

Fixed it. Tom Ruen (talk) 16:07, 5 October 2015 (UTC)

two small changes for the references and further readings sections.

The link in further readings to the Coxeter and Dynkin interview was broken, but here is a corrected link

      https://ecommons.cornell.edu/handle/1813/17339

The variant references (3. and 7.) to Lanner F. and to Folke Lanner seems confusing.

thanks, 71.186.130.243 (talk) 21:22, 30 March 2016 (UTC)

Assessment comment

The comment(s) below were originally left at Talk:Coxeter–Dynkin diagram/Comments, and are posted here for posterity. Following several discussions in past years, these subpages are now deprecated. The comments may be irrelevant or outdated; if so, please feel free to remove this section.

The content of the page is good. However the notation was (for me) rather non-standard. In the book "Combinatorics of Coxeter groups" by Bjorner and Brenti (Springer texts in Mathematics) the irreducible Coxeter systems are given in Appendix A1. I believe their notations are much more standard in the literature. For the finite cases they use A_n, B_n, D_n for the families and E_6, E_7, E_8, F_4, G_2, H_3, H_4, I_2(m) for the others. The affine diagrams are \tilde{A}_1, \tilde{A}_{n-1}, \tilde{B}_n, \tilde{C}_n, \tilde{B}_n for the families and \tilde{E}_6, \tilde{E}_7, \tilde{E}_8, \tilde{F}_4, \tilde{G}_2 for the exceptional cases. I think that using a standard notation, or at the very least making references to standard textbooks, would improve the page considerably. Best regards, 140.105.47.81 10:08, 22 May 2007 (UTC)

Last edited at 10:08, 22 May 2007 (UTC). Substituted at 01:56, 5 May 2016 (UTC)

Branches labels

The articles says that "Branches of a Coxeter–Dynkin diagram are labeled with a rational number p". Is this correct? Shouldn't labels be rational integers (or infinity)? Fcesi (talk) 13:53, 14 June 2016 (UTC)

Noninteger rational numbers are allowed, like 5/2, . I agree this needs explaining somewhere in this article. These groups define the regular star polygons. Coxeter uses these groups for his uniform star polyhedron constructions. The rank 3 point groups are based on Schwarz_triangles. The rank 4 point groups are defined by Goursat tetrahedra, and create the 10 regular star 4-polytopes. Tom Ruen (talk) 22:37, 14 June 2016 (UTC)

Disappearing contents

I just undid an earlier edit, which was meant to simply amend one statement in the Description section which had garbled syntax. Unfortunately, for reasons not clear to me, all page content except that section disappeared! :-( So I've just undone the change that lost the content. The net effect of both edits is just to correct that garbled grammar. Sorry if the briefly missing content caused anybody any confusion or other grief. yoyo (talk) 15:00, 23 June 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Coxeter–Dynkin diagram. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20051016143215/http://math.u-bourgogne.fr/IMB/crisp/injart.ps to http://math.u-bourgogne.fr/IMB/crisp/injart.ps

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:24, 14 August 2017 (UTC)