## Counting edges in polychora

Discussion of known convex regular-faced polytopes, including the Johnson solids in 3D, and higher dimensions; and the discovery of new ones.

### Counting edges in polychora

So, I asked a couple times in Quickfur's renders thread how he got 216 edges in the bixylodiminished hydrochoron while I got 228.

The method I used is outlined below and I'd really appreciate it if anyone could point out where my error or negligence lies:
• Tridiminished icosahedron (hereafter teddy) has four types of edges, which, using Quickfur's terminology for its face types, I call "top to pen" (joining the top triangle to each pentagon), "pen to pen" (joining two pentagons), "pen to lat" (joining a pentagon to a lateral) and "lat to bot" (joining each lateral to the bottom triangle).
• I notice, from his images, that in the whole polychoron, the "top to pen", "pen to lat" and "lat to bot" edges all become the same type of edge, because the three cells around it are oriented such that one cell uses the edge for a "top to pen" configuration, the next for a "pen to lat" configuration, and the last for a "lat to bot" configuration; in total there are 3 cells around this type of edge, which I now call the "top-pen-lat-top loop", or just "the loop" for short.
• The remaining edge type, "pen to pen", doesn't merge with anything, and there are 4 cells around each instance of the edge.
• The teddy contains 15 edges, including 3 of the "pen to pen" type, leaving 12 of the other types which merge into the "loop" type.
• The cells of the whole polychoron are 48 teddies, so that means 3×48 = 144 "pen to pen" edges, and 12×48 = 576 "loop" edges.
• But because each "pen to pen" edge has 4 teddies around it, that means there are only actually 144÷4 = 36 "pen to pen" edges, similarly, there are only 576÷3 = 192 edges.
• That makes 228 edges in total, not 216.

Keiji

Posts: 1968
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

### Re: Counting edges in polychora

I'm an idiot. Why didn't I think of this earlier: use my viewer's capability to assign different textures to different elements, to do a render of the different types of edges it found? Anyway, here's the result:

The light orange/dark yellow edges have 4 cells surrounding them, whereas the black edges have 3. This render shows a single cell, so that it's clear which edges are where on the cell. As you can see, there are 6 edges per cell that have 4 cells surrounding them. Due to the chirality of the polychoron, the arrangement of these edges on a cell does not have reflective symmetry! I think this is probably the source of your calculation discrepancy.

Anyway, for completeness' sake, here's another render showing the rest of the cells on the near side of the polychoron. I skipped the far side 'cos otherwise it's too tangly and confusing; but hopefully this should be enough to show how these edges correspond between different cells.

quickfur
Pentonian

Posts: 2813
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

### Re: Counting edges in polychora

quickfur wrote:[...] As you can see, there are 6 edges per cell that have 4 cells surrounding them. Due to the chirality of the polychoron, the arrangement of these edges on a cell does not have reflective symmetry! I think this is probably the source of your calculation discrepancy.
[...]

IOW, 3 of the pen-to-lat edges are actually equivalent to the pen-to-pen edges (of adjacent cells), so there are actually 6 edges of the kind with 4 cells around it, and 9 edges of the kind with 3 cells around it.

Running it through your calculations again: 6 edges * 48 cells / 4 cells per edge = 72 edges with 4 cells around each; 9 edges * 48 cells / 3 cells per edge = 144 edges with 3 cells around each. Total = 216 edges.
quickfur
Pentonian

Posts: 2813
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

### Re: Counting edges in polychora

Aha, figures that it would be that step. Once again, I'm quite surprised at the structure of this shape.

Glad to know the rest of my method works out; is there a formal proof that this works in general (i.e. for arbitrary polychora) anywhere? It's one of those things that seems intuitive and like it doesn't need a proof, but I'd like to have some reassurance.

Keiji

Posts: 1968
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

### Re: Counting edges in polychora

Keiji wrote:Aha, figures that it would be that step. Once again, I'm quite surprised at the structure of this shape.

Yeah I had a moment of epiphany when its spiralling structure dawned on me.

Glad to know the rest of my method works out; is there a formal proof that this works in general (i.e. for arbitrary polychora) anywhere? It's one of those things that seems intuitive and like it doesn't need a proof, but I'd like to have some reassurance.

I'm the wrong person to ask, since I suck at counting things, but you may be able to find something if you look up Euler characteristic and the related topics.
quickfur
Pentonian

Posts: 2813
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

### Re: Counting edges in polychora

The surest way clearly is a correct visualization and a mere counting. But that would be hard both for huge numbers as well as in dimensions beyond 3D.

The best way I would recomment are incidence matrices. Incidence matrices not in the way those were used in the past, i.e. by using mere 0-1-matrices between just 2 adjacent subdimensions, but those of all subelements. More easy, when used in symmetrical equivalence grouping. There al symmetry equivalent elements of any dimension have to be listed as rows respectively as columns. If available as Dynkin sub-symbols those could be provided as clue in addition, but the possibility of being describable as Dynkin symbol is not necessary here.

Just to provide an easy example. Consider THO, the tesseractihemioctachoron. It is a faceting of HEX (hexadecachoron = aerochoron), but uses hemifacets. I cant see asuitable Dynkin graph representation for THO. But this doesnt matter at all with respect to its incidence matrix. so we consider:
Code: Select all
`vertices   | 8 |  6 | 12 | 4 3-----------+---+----+----+----edges      | 2 | 24 |  4 | 2 2-----------+---+----+----+----triangles  | 3 |  3 | 32 | 1 1-----------+---+----+----+----tetrahedra | 4 |  6 |  4 | 8 *octahedra  | 6 | 12 |  8 | * 4`

As you can see, I note as matrix element m_i,j (i<>j) the number of j-elements incident to an i-element. For additional overview I guide the view by additional dimensional groupings using horizontal resp. vertical bording lines. The entries of the diagonal blocks are kind of special. If used in the same way as given so far those just would be Kronecker-deltas: non-equivalent elements surely would not be (completely co-)incident, while equivalent ones surely are. But we need the absolute counts of elements under the action of the used symmetry additionally. Thus I have chosen to display those absolute counts in that diagonal instead. The non-diagonal elements of the diagonal blocks, as mentioned above should be zero. But in order to depict that they never can be full-dimensional coincident I use an asterix instead.

This type of incidence matrix has some interesting properties. Those can be used to get all those numbers in a consistent way. (In fact, this is the true reason to outline all this under the topic of consideration!)

Firstly, the sub-diagonal entries of the matrix rows represent the total counts of the element represented there, i.e. if the incidence matrix of that thingy would be set up, they would be its diagonal elements.
Next, the super-diagonal entries of the matrix rows represent the total counts of the -figure elemnts of the there represented elements, i.e. of the vertex figure, edge figure etc. (Wendys "around")
The diagonal elements, as already said, are the total counts of the polytope under consideration.
Any of the above 3 count numbers are subject to the Euler equation: -1 + sum of vertex counts - sum of edge counts + ... +- 1 = 0 (at least as long as no holes etc. have to be considered)
You would have: m_i,j * m_i,i = m_j,j * m_j,i (for any i>j) - Note, that this relation form, which is rather easy to remember, makes use of having those absolute counts within the diagonal!

That is, having a figure in consideration, generally a lot of those numbers are more or less obvious - or at least: more easy to get. Others are not so obvious - as your edge counts in this thread-topic. But all those useful relations could help to fiddle them out!

--- rk

PS: more could be found at: http://bendwavy.org/klitzing/explain/incmat.htm
Klitzing
Pentonian

Posts: 1613
Joined: Sun Aug 19, 2012 11:16 am
Location: Heidenheim, Germany

### Re: Counting edges in polychora

Yes, I love incidence matrices

My problem however was ascertaining what the imat was in the first place. Once I have the imat, though, it's easy to read off the information I need to know.

Indeed, the reason this topic was created was because I had mistaken the structure of the polytope in question.

Keiji

Posts: 1968
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

### Re: Counting edges in polychora

Keiji wrote:Yes, I love incidence matrices

You are wellcome!

My problem however was ascertaining what the imat was in the first place. Once I have the imat, though, it's easy to read off the information I need to know.

Indeed, the reason this topic was created was because I had mistaken the structure of the polytope in question.

What I had in mind when telling you about incmats, exactly was that very purpose:
once you are piling up an actual incmat, all those relations between the individual numbers provide lot of guidance to the correct structure.

In fact, even myself am proceding that way: using the calculation of an incmats as a much more interesting variant of a (possibly giant) sudoku! I.e. starting with the "obvious" numbers, and then filling in one by one the less obvious ones, heavily making use of all those relations... - Possibly some non-fulfilled relations thereby might give clues on wrong assumptions!

BTW, those 1000s of incmats in my website are all calculated manually. I don't have any type of calculation engine for that purpose. In fact, it is not so much that I am too lazy to program one, it is rather that constant sudoku-like challange to be met thereby.

--- rk
Klitzing
Pentonian

Posts: 1613
Joined: Sun Aug 19, 2012 11:16 am
Location: Heidenheim, Germany