General Approach--can 3D methods be generalized?

[student5]

Hmmm... Even though a lot of them turned out to be EKF, I'd say that bilbiro-ing and thawro-ing are still techniques that could produce further families of CRFpolychora. Like creating two "eggshells" that a brute force program could further try to connect. But then again, this will go into ex-family territory and thus get a combinatorial explosion.
Anyways, Quickfur, could you maybe share your program? I'd be interested to take a look at it and maybe make it more user-friendly (I'm into GUI's these days )

[quickfur]

Hmmm... Even though a lot of them turned out to be EKF, I'd say that bilbiro-ing and thawro-ing are still techniques that could produce further families of CRFpolychora. Like creating two "eggshells" that a brute force program could further try to connect. But then again, this will go into ex-family territory and thus get a combinatorial explosion.
Anyways, Quickfur, could you maybe share your program? I'd be interested to take a look at it and maybe make it more user-friendly (I'm into GUI's these days )

Which program are you talking about? Polyview? That's the only program I have right now, and the only thing it does is to make (convex) polytopes from input coordinates and render them using POVRay. I don't have any working prototype of a program that can do brute-force searching of CRFs, or even do EKF operations. In the past I had to manually construct the CD diagrams and lace cities and then manually construct explicit coordinates for them, before Polyview could render them.

I believe Keiji actually has a working instance of Polyview (an older version) running somewhere on this site, or at least on a personal server. I have since rewritten Polyview in another language and added some features (and perhaps introduced some new bugs ), but the core functionality remains the same. You need to have explicit coordinates to construct a polytope before it can render it. Though I did add a lot of syntactic sugar for the input: you can use permutation operators like ±, apacs, epacs, etc., and you can even delete vertices from the current set of coordinates (to make it easier to construct e.g. diminishings of the 600-cell). But there's currently no way of generating a polytope from a CD diagram or lace tower / lace city directly, you have to expand it by hand first.

[student5]

D4.3.1 and D4.3.2 are really cool: I couldn't find anything EKF-like from them.

I see it as an EKF (i.e., modified Stott expansion) of some faceted prism of an icosahedral family polyhedron.

In this lace tower configuration here, I found it difficult to "see" the bilibiro's, but they are on the sides:

Code: Select all

x2x    x2o       x2o
o2F    o2f       o2f
f2o <- f2(-x) <- f2o
o2F    o2f       o2f
x2x    x2o       x2o


Ah yes, now I see it: The bilbs are expanded along the square, so the original shape is a dodecahedral-prism kind of thing:

Code: Select all

x5o3x    x5o3o                   x5o3o
o5o3F    o5o3f                   o5o3f
f5o3o <- f5o3(-x) <- f5(-x)3x <- o5x3o
o5o3F    o5o3f                   o5o3f
x5o3x    x5o3o                   x5o3o


Notice that we have to swap twice to get back to a non-faceted something. However, this is not anything as far as I can see... The ikes don't show up, because the faceting doesn't work out... I can't find it as an ekf now...

Made me think that the stott-expanded version may actually be an EKF that then gets stott-contracted:

Code: Select all

x5x3x    x5x3o       x5x3o
o5x3F    o5x3f       o5x3f
f5x3o <- f5x3(-x) <- f5o3x
o5x3F    o5x3f       o5x3f
x5x3x    x5x3o       x5x3o


This does look like it may be CRF.. Indeed it's part of rox:

Code: Select all

x3o5o
o3x5o
F3o5o
o3f5o
f3o5x
o3x5x <-
f3x5o <-
V3o5o (V=2f)
x3o5f <-
f3x5o <-
o3x5x <-
...


[student5]

And D.4.16: Could it be derived from an EKF?
from the wiki: xfox-2-oxfo-3-ooox&#xt

Code: Select all

x2o3o   x2o3x
f2x3o    f2x3x
o2f3o <- o2f3x
x2o3x    x2o3u


nope...

The mibdies are in this case on directly visible in the lace tower:

Code: Select all

mibdi:
x2o
f2x
o2f
x2o
lace city:
    o o
   x   x
     f
    o o


compare to ike:

Code: Select all

x2o
o2f
f2x
o2f
x2o


trying to expand into lace city:

Code: Select all

   o3o o3o
  x3o   x3o
     f3o
   o3x o3x <- where does this x come from?


Original thread describing the process which indeed needs some brute-forcing to find the mysterious x, which quickfur did by hand. Also, it is not EKF-derived! (not proven)
I still have this hunch that it is some contraction and diminishing of trigonally-expanded ex.../rhombochoron, trying to expand:

Code: Select all

   o3x o3x
  x3x   x3x
     f3x
   x3o x3o <- what to do here?


It doesn't seem to be part of this: lace city source

Code: Select all

                x3o               
                                 
        o3x   x3f F3o   x3x       
                                 
                                 
x3o x3f   F3x       o3F
                                 
   F3o       x3F   f3x o3x
                                 
                                 
x3x   o3F f3x   o3x

        o3x


[Klitzing]

D4.7: Can be augmented undocumented but probably some EKF?

Cf. https://bendwavy.org/klitzing/incmats/id=srid=F-ike=ti.htm.

--- rk

[Klitzing]

However, just found an other old one (http://hi.gher.space/forum/viewtopic.php?p=21746#p21746) which wasn't so far on my CRF or EKF pages.
In fact the true EKF (starting from ex = 600-cell) within A2 x A2 subsymmetry here is:

Code: Select all

ABCDEFGHIJ   ABCDEFGHIJ   ABCDEFGHIJ   ABCDEFGHIJ
-------------------------------------------------
fFoxffooxo 3 foFfxofxoo 2 oxofofxFof 3 ooxofxfoFf &#zx  (ex)
fFo(-x)ffoo(-x)o 3 foFFxofxxo 2 oxofofxFof 3 ooxofxfoFf &#zx  (D1+I1 rewrite)
FAxoFFxxox 3 foFFxofxxo 2 oxofofxFof 3 ooxofxfoFf &#zx  (first node expanded -> already contained EKF)

FAxoFFxxo. 3 foFFxofxx. 2 oxofofxFo. 3 ooxofxfoF. &#zx  (J-level diminished = student5's/Quickfur's above mentioned, but so far missing find)

.AxoFFxxo. 3 .oFFxofxx. 2 .xofofxFo. 3 .oxofxfoF. &#zx  (A+J-levels diminished = todays new find!)


Btw. did you already know of the facet totals of that old one?
Those were:

• 18 ikes
• 9 mibdies (J62)
• 54 squippies (J1)
• 84 tets
• 6 thawroes (J92)
• 12 trips

And the facet totals of my new one then are:

• 18 gyepips (J11)
• 9 mibdies (J62)
• 54 squippies (J1)
• 6 teddies (J63)
• 54 tets
• 6 thawroes (J92)
• 12 trips

--- rk

[Klitzing]

Just found a further CRF:
FxFox 5 xFoFx 2 xofox 5 oxofx &#zx
Its facet totals are:

• 50 bilbiroes (J91)
• 10 dips
• 10 paps
• 10 pips
• 50 squippies (J1)

Code: Select all

                 x5x           x5x                 
                        F5o                       
                                                   
            o5F                     o5F           
     x5x                                   x5x     
                        F5x                       
                 x5F           x5F                 
                                                   
     F5o                                   F5o     
            F5x                     F5x           
                                                   
x5x                                             x5x
                                                   
            x5F                     x5F           
     o5F                                   o5F     
                                                   
                 F5x           F5x                 
                        x5F                       
     x5x                                   x5x     
            F5o                     F5o           
                                                   
                        o5F                       
                 x5x           x5x                 


The decagonal periodic -dip-{10}-dip- ring clearly is obvious here. Then there is an orthogonal, alternating -pip-{5}-pap-gyro{5}-gyropip-gyro{5}-pap-{5}-pip- ring. And, what is quite notable, the pentagons of the bilbiroes just connect two of those each. In fact the latter ones get squeezed between those 2 orthogonal rings, while the squippies just fill in the remaining gaps. Note that it does not use any tetrahedra (nor triangular prisms or any other "usual" small stuff).

Code: Select all

FxFox5xFoFx xofox5oxofx&#zx

o....5o.... o....5o....     & | 100  *   * |  1   2   2   1   0   0   0 |  2  1   3  1   2   0   0  0  0  0 |  1  1  3  0  0
..o..5..o.. ..o..5..o..     & |   * 50   * |  0   0   0   2   4   0   0 |  0  0   0  1   4   2   2  0  0  0 |  0  0  4  1  0
....o5....o ....o5....o       |   *  * 100 |  0   0   0   0   2   2   2 |  0  0   0  0   1   2   2  1  2  2 |  0  0  2  2  2
------------------------------+------------+----------------------------+-----------------------------------+---------------
..... x.... ..... .....     & |   2  0   0 | 50   *   *   *   *   *   * |  2  0   0  1   0   0   0  0  0  0 |  0  1  2  0  0
..... ..... x.... .....     & |   2  0   0 |  * 100   *   *   *   *   * |  1  1   1  0   0   0   0  0  0  0 |  1  1  1  0  0
oo...5oo... oo...5oo...&#x    |   2  0   0 |  *   * 100   *   *   *   * |  0  0   2  0   1   0   0  0  0  0 |  1  0  2  0  0
o.o..5o.o.. o.o..5o.o..&#x  & |   1  1   0 |  *   *   * 100   *   *   * |  0  0   0  1   2   0   0  0  0  0 |  0  0  3  0  0
..o.o5..o.o ..o.o5..o.o&#x  & |   0  1   1 |  *   *   *   * 200   *   * |  0  0   0  0   1   1   1  0  0  0 |  0  0  2  1  0
....x ..... ..... .....     & |   0  0   2 |  *   *   *   *   * 100   * |  0  0   0  0   0   1   0  1  1  1 |  0  0  1  1  2
..... ..... ....x .....     & |   0  0   2 |  *   *   *   *   *   * 100 |  0  0   0  0   0   0   1  0  1  1 |  0  0  1  1  1
------------------------------+------------+----------------------------+-----------------------------------+---------------
..... x.... x.... .....     & |   4  0   0 |  2   2   0   0   0   0   0 | 50  *   *  *   *   *   *  *  *  * |  0  1  1  0  0
..... ..... x....5o....     & |   5  0   0 |  0   5   0   0   0   0   0 |  * 20   *  *   *   *   *  *  *  * |  1  1  0  0  0
..... ..... xo... .....&#x  & |   3  0   0 |  0   1   2   0   0   0   0 |  *  * 100  *   *   *   *  *  *  * |  1  0  1  0  0
..... x.o.. ..... .....&#x  & |   2  1   0 |  1   0   0   2   0   0   0 |  *  *   * 50   *   *   *  *  *  * |  0  0  2  0  0
ooooo5ooooo ooooo5ooooo&#xr   |   2  2   1 |  0   0   1   2   2   0   0 |  *  *   *  * 100   *   *  *  *  * |  0  0  2  0  0
..... ..o.x ..... .....&#x  & |   0  1   2 |  0   0   0   0   2   1   0 |  *  *   *  *   * 100   *  *  *  * |  0  0  1  1  0
..... ..... ..... ..o.x&#x  & |   0  1   2 |  0   0   0   0   2   0   1 |  *  *   *  *   *   * 100  *  *  * |  0  0  1  1  0
....x5....x ..... .....       |   0  0  10 |  0   0   0   0   0  10   0 |  *  *   *  *   *   *   * 10  *  * |  0  0  0  0  2
....x ..... ....x .....     & |   0  0   4 |  0   0   0   0   0   2   2 |  *  *   *  *   *   *   *  * 50  * |  0  0  0  1  1
....x ..... ..... ....x     & |   0  0   4 |  0   0   0   0   0   2   2 |  *  *   *  *   *   *   *  *  * 50 |  0  0  1  0  1
------------------------------+------------+----------------------------+-----------------------------------+---------------
..... ..... xo...5ox...&#x    |  10  0   0 |  0  10  10   0   0   0   0 |  0  2  10  0   0   0   0  0  0  0 | 10  *  *  *  *  pap
..... x.... x....5o....     & |  10  0   0 |  5  10   0   0   0   0   0 |  5  2   0  0   0   0   0  0  0  0 |  * 10  *  *  *  pip
FxFox ..... ..... oxofx&#xt & |   6  4   4 |  2   2   4   6   8   2   2 |  1  0   2  2   4   2   2  0  0  1 |  *  * 50  *  *  bilbiro (tower: 21435)
..... ..o.x ..... ..o.x&#x  & |   0  1   4 |  0   0   0   0   4   2   2 |  0  0   0  0   0   2   2  0  1  0 |  *  *  * 50  *  squippy
....x5....x ....x .....     & |   0  0  20 |  0   0   0   0   0  20  10 |  0  0   0  0   0   0   0  2  5  5 |  *  *  *  * 10  dip


--- rk

[mr_e_man]

Nice find, Klitzing!
It is interesting, how the bilbiros fit together.

I encountered that vertex figure (2 dip + 2 squippy + 2 bilbiro/thawro/pocuro) in my search, but I didn't dwell on it, as I was focusing on 7-gons etc. rather than 10-gons.

[mr_e_man]

Here are my thoughts on the general approach for n>4 dimensions, as it doesn't appear to be explicitly spelled out anywhere.


([j, k]-subpolytopes are defined here.)

Assuming we've enumerated all CRH polytopes in the previous dimension, these are the possible [-1, n-1]-spyts (i.e. faces, using Wendy's terminology) of any CRH polytope in n dimensions.

Of course this also determines the possible [j, n-1]-spyts for all j (the vertex figures and edge figures etc. of the faces), including the [n-4, n-1]-spyts, which can be considered as spheric polygons.

Then any [n-4, n]-spyt can be considered as a spheric polyhedron, with faces from that known set of polygons. So we try to build polyhedra in 3D spheric space. By Cauchy's rigidity theorem, the polyhedron's dihedral angles are determined by its arrangement of faces. These angles are the [n-2, n]-spyts.

So we know the possible [-1, n-1] and [n-4, n]-spyts. Then we need to fit these subpolytopes together, matching the [n-4, n-1]-spyts between the two types, to build the whole polytope. This task could be broken down further: First enumerate the [n-4, n]-spyts, then enumerate the [n-5, n]-spyts using the known [n-5, n-1] and [n-4, n]-spyts, then enumerate the [n-6, n]-spyts using the known [n-6, n-1] and [n-5, n]-spyts, and so on. In other words, at each step (expanding dimensionally downward), consider faces and verfs to determine the whole subpolytope.


The point is that all the flexibility is confined to 3D. The rest of the problem is discrete/combinatorial.

[mr_e_man]

Assuming we've enumerated all CRH polytopes in the previous dimension

Of course we need to understand "enumerate" loosely, since we've seen that there are more than 10^64 different polychora derived from the o5o3o3o family. For example we could say "classify" instead.

Or we could just enumerate the vertex figures, not bothering with the whole polychora, and use this data to enumerate the edge figures of polytera.

[mr_e_man]

Hello again. If I can remember it well, one of the steps of enumerating johnson solids involved the vertex angle defect.
In 2 dimensions, the exterior angles of every non-self-intersecting polygon sum up to 2π because it seems like they can be deformed into a circle. The case in 3 dimensions sums up to 4π, equivalent to a sphere. My question is: is there an equivalent of that in 4 dimensions? The complete theorem is the Gauss-Bonnet theorem, but when I tried to find such relation, I drowned in heavy calculus. So I was curious to know if someone found this result.

If it's equivalent to hypersphere, then it would be 2π^2.

But if that's the case, there's some kind of angle defect which has this sum. What would it be? Dihedral angles and vertex solid angles are not comensurable with π, except for the cube (which can tile the space alone) and, maybe, truncated octahedron. https://en.wikipedia.org/wiki/Platonic_solid#Geometric_properties
That led me to question if this invariant even exists, which it does because of that theorem.

The duals of the verfs must exactly cover the sphere. (The dual of the whole polytope is a discrete version of the Gauss map of a smooth surface.) In particular, their (n-1)-dimensional measures must add up to exactly the measure of the sphere. That is the generalization of polyhedron vertex angle deficits adding up to 4π.

But the Gauss-Bonnet theorem generalizes in a different way, only to even dimensions. I don't know much about that.


This fact can be used to show (see here) that the number of CRH n-polytopes is finite, if the (Euclidean, regular) polygons have limited size.

[mr_e_man]

Also, I have a conjecture:

If a polytope, in n-dimensional Euclidean or spheric space with n>2, has convex faces (the [-1, n-1]-spyts) and convex vertex figures (the [0, n]-spyts), then the polytope (the [-1, n]-spyt) is convex.

Assuming this is true, we would also get the following, by induction on dimensions:

If a polytope, in n-dimensional Euclidean or spheric space with n>2, has convex [k, k+3]-subpolytopes for all k (including hedra with k = -1), then it is convex.

Thus, given an n-polytope with CRH faces, we only need to ensure that the [n-3, n]-spyts are convex (spheric) polygons, and then it should follow that the whole polytope is convex.


(But this depends on what a "polytope" even is, if it's not convex. That is a different topic.)

[student5]

I've read a bit of thingies here and started writing a program in Rust (Rust is much faster than Python @mr_e_man). So far it can:

parse ASCII coxeter-dynkin notation into a PetGraph (a graph datastructure)
Generate the first point for 3-dimensional coxgraphs based on a paper I cannot currently find back (I lost my laptop and didn't upload the pdf cuz copyright)
do the initial reflections

Currently open questions:

What is a nice sequence to do all the reflections and put them in a datastructure (actually another graph with coordinates at all vertices, but depending on whether there is an x or o on an edge, some coincide, so this involves some edge-cases, including what edges are there. Maybe a convex-hull algorithm could work, but knowing which edges lace within a polygon is useful for constructing lace towers
Further develop exxact crate so it can:

Do division, multiplication etc
do cos(pi/n) easily using DeMoivre's theorem, cuz hard-coding is boring and ugly

I have to go now, please look at the stuff and/or add your own programs/snippets to it in a different folder so we can cooperate!

[mr_e_man]

Thanks for the hint. I don't do a lot of programming. I know Python is slow, but it hasn't been a problem for me yet. Maybe I'll try Rust in the future.

Further develop exxact crate so it can:

Do division, multiplication etc
do cos(pi/n) easily using DeMoivre's theorem, cuz hard-coding is boring and ugly

See Minimal polynomial of 2cos(2π/n)

I have to go now, please look at the stuff and/or add your own programs/snippets to it in a different folder so we can cooperate!

I am focusing on arbitrary asymmetric things. CD diagrams are too specialized.

[mr_e_man]

Okay, here's the algorithm I'm using for the first part of my program.

(My data structures are based on flags. Each flag in an n-polytope has references to n other flags, and n measures (lengths or angles) associated with these connections. An edge in a multihedron is just a set of four flags, or two flags if the edge is incomplete.)

• We have a list of polygons, which are the allowed types of faces of the polyhedra we're trying to build. From this, we can make a sorted list of the angles in the polygons, etc.


• Given a multihedron (an incomplete polyhedron), find the incomplete vertex with the greatest angle sum. By convexity, any vertex angle sum must be less than 360°. The multihedron is likely to close up into a polyhedron more quickly if we work on this vertex. Of the two incomplete edges at this vertex, take the edge whose other vertex has the greater angle sum. We'll try to complete this edge, either by adding a new face there, or by connecting it to another existing incomplete edge. (It's tempting to only look at the other edge at the same vertex, but we must consider the possibility of other existing edges intruding between them. In other words, two incomplete vertices may combine.)


• Try to connect this edge to each existing edge:
• Make sure to connect them with the right orientation. I.e. don't accidentally make a Möbius band.
• Make sure the edge lengths match.
• Don't connect them if they already share a face. I.e. a single polygon shouldn't be twisted back onto itself.
• Don't connect them if a vertex will be complete but have only 2 faces around it.
• Add the angle sums at the corresponding vertices (unless they were already the same vertex). The resulting sum(s) must be less than 360°.
• Optionally, calculate some dihedral angles. If there are several ways to get an angle, the results must agree with each other.
• If it passes all these tests, accept the new multihedron, with the two edges connected. (Or perhaps I should say the two edges become one edge.) Of course there are other possible tests, but they're more complicated.
• Try to add a new face at this edge. Go through the list of all orientations of all polygons, in order of the angles in the polygons:
• Make sure the edge lengths match.
• At the vertex with the greatest angle sum, add the corresponding angle in the polygon. The result must be less than 360°. If it's not, then anything further in the list (since it's sorted) will also make the sum exceed 360°, so we can immediately stop trying new faces here.
• At the other vertex of this edge, add the corresponding angle in the polygon. The result must be less than 360°. (Note, the list can't be sorted in two ways at the same time.)
• Accept the new multihedron, with the new face.
• Now we have a list of new multihedra, each containing the original multihedron as a subset. I guess I'll call this list an "elaboration" of the multihedron. (Sometimes I think of it as opening a box and taking several smaller boxes out of it.)


• Given a list of multihedra, replace each one with its elaboration, unless it's already a polyhedron, which cannot be elaborated. This generally makes the list longer, but it may make it shorter, if some multihedron elaborates to nothing, i.e. if we find out that that multihedron just doesn't work. For a depth-first search, go through the list elaborating in front of you. For a breadth-first search, elaborate behind you and keep moving forward, and if you reach the end of the list, start again from the beginning. Either way, it's supposed to eventually boil down to a list of polyhedra. (Of course this could be done using trees instead of lists. The root of the tree is the original multihedron, and the leaves of the tree are the possible polyhedra.)

[mr_e_man]

• Try to add a new face at this edge. Go through the list of all orientations of all polygons, in order of the angles in the polygons:
• Make sure the edge lengths match.
[...]

To make this part more efficient, I suppose we could further refine the polygon data, and make a separate list for each edge length.


There's something I forgot to mention.

• Add the angle sums at the corresponding vertices (unless they were already the same vertex). The resulting sum(s) must be less than 360°.

Each vertex keeps a record of its angle sum. So when an incomplete vertex with m incident faces is combined with an incomplete vertex with n incident faces, you only need to add 2 numbers. If you don't keep these records, you need to add m+n numbers. But it probably doesn't matter much (unless you have hundreds of faces around a single vertex!).

[mr_e_man]

We need to be able to solve a polygon; to calculate all of its angles, given some of its angles and all of its edge lengths.

Thus, suppose we have an n-gon (possibly irregular or non-Euclidean), and we know all n of the edge lengths and at least n-3 of the angles. If n=3 then the trigon is easily solved by the law of cosines (after checking the triangle inequality), so suppose n>3. Then, since we know at least one vertex angle, and we also know the lengths of the two edges at this vertex, we can use the law of cosines to find the distance between the two vertices adjacent to this one. The three vertices form a trigon which we can solve. Cutting off the trigon, we get an (n-1)-gon, with all n-1 edge lengths known, and at least n-4 angles known. (If an angle in the n-gon adjacent to the original angle is known, then we can subtract an angle in the trigon, to get an angle in the (n-1)-gon.) Solve this smaller polygon, using recursion. Then the larger polygon is also solved. (If an angle in the n-gon adjacent to the original angle is unknown, then we can find it by adding an angle in the trigon and an angle in the (n-1)-gon which was just calculated.)

Also, whenever you add or subtract two angles, check that the result is between 0° and 180°. Everything is supposed to be convex.


Now let's apply this to a multihedron's verfs. Expanding on this step:

• Optionally, calculate some dihedral angles. If there are several ways to get an angle, the results must agree with each other.

We were connecting two edges. If one of the two resulting vertices is complete, and n-valent, and we know at least n-3 of the dihedral angles there, then solve the verf to get the other dihedral angles. For each edge that was updated with a dihedral angle, go to its other vertex, and try to solve that verf also. Keep doing this until no more verfs can be solved.

Whenever you solve a verf where more than n-3 of the angles were already known, you can use just n-3 of them in the calculations, and afterward compare the results with the remaining known angles. If they're unequal then the multihedron can be discarded. (Floating-point arithmetic generally would say that they're unequal, even when they're actually equal. Of course the floating-point results may be close to equal, but how close is close enough? If you use interval arithmetic instead, the test is whether the two intervals overlap.)

This can only be applied if at least one vertex somewhere is trivalent.