137 posts
• Page **5** of **5** • 1, 2, 3, 4, **5**

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 )

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 )

- student5
- Dionian
**Posts:**48**Joined:**Tue Feb 18, 2014 2:48 pm

student5 wrote: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.

- quickfur
- Pentonian
**Posts:**2984**Joined:**Thu Sep 02, 2004 11:20 pm**Location:**The Great White North

student5 wrote:quickfur wrote: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: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...

- Code: Select all
`x5o3x x5o3o x5o3o`

o5o3F o5o3f o5o3f

f5o3o <- f5o3(-x) <- f5(-x)3x <- o5x3o

o5o3F o5o3f o5o3f

x5o3x x5o3o x5o3o

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
- Dionian
**Posts:**48**Joined:**Tue Feb 18, 2014 2:48 pm

And D.4.16: Could it be derived from an EKF?

from the wiki: xfox-2-oxfo-3-ooox&#xt

nope...

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

compare to ike:

trying to expand into lace city:

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:

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

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

- student5
- Dionian
**Posts:**48**Joined:**Tue Feb 18, 2014 2:48 pm

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

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

--- rk

- Klitzing
- Pentonian
**Posts:**1639**Joined:**Sun Aug 19, 2012 11:16 am**Location:**Heidenheim, Germany

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:

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

Those were:

And the facet totals of my new one then are:

--- rk

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
- Pentonian
**Posts:**1639**Joined:**Sun Aug 19, 2012 11:16 am**Location:**Heidenheim, Germany

Just found a further CRF:

FxFox 5 xFoFx 2 xofox 5 oxofx &#zx

Its facet totals are:

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

--- rk

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

- Klitzing
- Pentonian
**Posts:**1639**Joined:**Sun Aug 19, 2012 11:16 am**Location:**Heidenheim, Germany

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.

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
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

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.

([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
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

mr_e_man wrote: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.

Last edited by mr_e_man on Mon Jan 29, 2024 2:04 am, edited 1 time in total.

ΓΔΘΛΞΠΣΦΨΩ αβγδεζηθϑικλμνξοπρϱσςτυϕφχψωϖ °±∓½⅓⅔¼¾×÷†‡• ⁰¹²³⁴⁵⁶⁷⁸⁹⁺⁻⁼⁽⁾₀₁₂₃₄₅₆₇₈₉₊₋₌₍₎

ℕℤℚℝℂ∂¬∀∃∅∆∇∈∉∋∌∏∑ ∗∘∙√∛∜∝∞∧∨∩∪∫≅≈≟≠≡≤≥⊂⊃⊆⊇ ⊕⊖⊗⊘⊙⌈⌉⌊⌋⌜⌝⌞⌟〈〉⟨⟩

ℕℤℚℝℂ∂¬∀∃∅∆∇∈∉∋∌∏∑ ∗∘∙√∛∜∝∞∧∨∩∪∫≅≈≟≠≡≤≥⊂⊃⊆⊇ ⊕⊖⊗⊘⊙⌈⌉⌊⌋⌜⌝⌞⌟〈〉⟨⟩

- mr_e_man
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

Marek14 wrote:JMBR wrote: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.

JMBR wrote: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
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

Also, I have a conjecture:

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

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

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

ℕℤℚℝℂ∂¬∀∃∅∆∇∈∉∋∌∏∑ ∗∘∙√∛∜∝∞∧∨∩∪∫≅≈≟≠≡≤≥⊂⊃⊆⊇ ⊕⊖⊗⊘⊙⌈⌉⌊⌋⌜⌝⌞⌟〈〉⟨⟩

- mr_e_man
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

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:

Currently open questions:

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!

- 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!

- student5
- Dionian
**Posts:**48**Joined:**Tue Feb 18, 2014 2:48 pm

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.

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

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

student5 wrote: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
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

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

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

Last edited by mr_e_man on Mon May 06, 2024 8:27 pm, edited 1 time in total.

ℕℤℚℝℂ∂¬∀∃∅∆∇∈∉∋∌∏∑ ∗∘∙√∛∜∝∞∧∨∩∪∫≅≈≟≠≡≤≥⊂⊃⊆⊇ ⊕⊖⊗⊘⊙⌈⌉⌊⌋⌜⌝⌞⌟〈〉⟨⟩

- mr_e_man
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

mr_e_man wrote:

- 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!).

Last edited by mr_e_man on Mon May 06, 2024 8:57 pm, edited 1 time in total.

ℕℤℚℝℂ∂¬∀∃∅∆∇∈∉∋∌∏∑ ∗∘∙√∛∜∝∞∧∨∩∪∫≅≈≟≠≡≤≥⊂⊃⊆⊇ ⊕⊖⊗⊘⊙⌈⌉⌊⌋⌜⌝⌞⌟〈〉⟨⟩

- mr_e_man
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

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:

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.

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:

mr_e_man wrote:

- 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.

ℕℤℚℝℂ∂¬∀∃∅∆∇∈∉∋∌∏∑ ∗∘∙√∛∜∝∞∧∨∩∪∫≅≈≟≠≡≤≥⊂⊃⊆⊇ ⊕⊖⊗⊘⊙⌈⌉⌊⌋⌜⌝⌞⌟〈〉⟨⟩

- mr_e_man
- Tetronian
**Posts:**520**Joined:**Tue Sep 18, 2018 4:10 am

137 posts
• Page **5** of **5** • 1, 2, 3, 4, **5**

Users browsing this forum: No registered users and 1 guest