Wythoff program with Conway notation operation construction

[Adrian Rossiter]

Hi Roger

I have finally updated the repository with your changes. I also pushed
a couple of fixes of off_util -u and poly_weave to work on non-closed
input.

I have also added a new program called wythoff, which is a version
of poly_weave that is better suited to making tilings (I have
therefore moved poly_weave to unsupported programs.)

I have simplified the constructive notation, and the Conway
operators now have a fairly short implementation. Here is the
list for the named "normal" operators on the Wikipedia page

https://en.wikipedia.org/wiki/Conway_polyhedron_notation

Op Description Tiling Pattern
d dual [F]0V,0E
a ambo [E]0V,0F
S seed [V]0E,0F
j join [F,V]0_1E
k kis [F,V]0_1v1v,1E
t truncate [VE]0v0e,0V,0E
n needle [V,F]0_1f1f,1E
z zip [EF]0e0f,0F,0E
e expand [VF]0v0f,0V,0F
o ortho [V,E,F]1_0e1_2e
g gyro [F,VE,V]1_0F1_2V1E,1E
s snub [VEF]0V,0E,0F,0V0E0F
b bevel [VEF]0v0e,0e0f,0f0v
m meta [V,E,F]*0_1_2
c chamfer [V,VF]1F,0_1v1f
u subdivide [V,E]1F,0_1e1e
l loft [V,VF]1F,0_1v1_0v,0E
q quinto [V,E,EF]2F,0_1_2e2_1e
L0 joined-lace [V,EF2]1F,1e1_0e,1_0E
L lace [V,EF2]1F,1e1_0e,1_0v0v,0E
K stake [V,EF2,F]0_1_2e1e,1_0v0v,0E
M3 edge-medial-3 [F,V,VE]0_2_1e2e,2_0v2v
M0 joined-medial [F,V,EF]*0_1_2,1_2E
m3 edge-medial-3 [F,V,VE]*0_1_2,2_0v2v
b3 bevel3 [VEF,E2F]1_0e0v,0e0f,*1_0f0_1f,1E
o3 ortho3 [V,VF,VE]2_0e2_1e,1F,1_2v2_1v,2E
X cross [V,E,F,VF]3_1v3_2v,*0_1_3


The program handles a larger class of base tilings than those
derived from polyhedron, as the "edge" element can have more than
four 'meta'-triangles around it. You can see an example in the
following Wythoff construction snub

antiview wythoff_:3_5/3_5/2

It has three different coloured polygons (along with the white
snub triangles) and therefore does not correspond to the snub of
some polyhedron.

This has implications for creating more general Conway operator
implementations, as they need to ensure that edges which are
symmetrical about an edge centre are generated as digons. Similarly,
'seed' is now an operator! If the input is an polyhedron then 'seed'
returns the polyhedron but with digons along the edges, if the
input is a uniform triangle tiling to pe operated on directly then
'seed' creates triangles for the "edges" (the base tiling cannot be made
from another tiling by the meta operator).

The program works on open or closed orientable surfaces. I should
probably add something somewhere to generate hyperbolic tilings
with Schwarz triangles, as wythoff will also process these.

The nature of the program is that once the 'meta' tiling has been
made the V, E and F elements have equivalent properties (like the
angles in a Wythoff symbol) and so I have included an option to
permute them. This is interesting as it reveals that seed, dual
and join are really the same fundamental operation, and the snub
operation is symmetric wih respect to element reordering. I should
look at developing some maths relating to the notation.

There is more information and examples on the program help page.

I think I can implement the semi- operators (from the Wikipedia
page) by simply reversing the colour/sign of triangles around
alternate elements (V, E or F) which can be 2-coloured (having even
valence/sided isn't enough to guarantee the 2-colourability in
the general case, e.g. unitile2d -s t -S 0,1| off_color -f P | antiview ).

Subdivision could be done by a generating the corresponding pattern.

I'll see if I can make a snaphot next week.

Adrian.
--
Adrian Rossiter
adr...@antiprism.com
http://antiprism.com/adrian

[Adrian Rossiter]

Hi Roger

On Sat, 30 Sep 2017, Adrian Rossiter wrote:
> Op Description Tiling Pattern
> d dual [F]0V,0E
> a ambo [E]0V,0F
> S seed [V]0E,0F
> j join [F,V]0_1E

> permute them. This is interesting as it reveals that seed, dual
> and join are really the same fundamental operation, and the snub

That should have said seed, dual and *ambo* are the same fundamental
operation.

With Conway notation ambo seems different because it produces two
kinds of face, but with constructive notation 'seed' and 'dual' also
produce two kinds of face.

> Subdivision could be done by a generating the corresponding pattern.

In case it isn't clear, this refers to generating the pattern text.

[Adrian Rossiter]

Hi Roger

On Sun, 1 Oct 2017, Adrian Rossiter wrote:
> That should have said seed, dual and *ambo* are the same fundamental
> operation.
>
> With Conway notation ambo seems different because it produces two
> kinds of face, but with constructive notation 'seed' and 'dual' also
> produce two kinds of face.

A quick review of the wythoff Conway patterns shows that
truncate, zip and expand are equivalent operations

t truncate [VE]0v0e,0V,0E
z zip [EF]0e0f,0E,0F
e expand [FV]0f0v,0F,0V

wythoff -c t -r VEF cube | antiview
wythoff -c t -r EFV cube | antiview
wythoff -c t -r FVE cube | antiview


kis, needle and subdivide are also equivalent operations

k kis [F,V]0_1v1v,1E
n needle [V,F]0_1f1f,1E
u subdivide [V,E]0_1e1e,1F

wythoff -c k -r VEF cube | antiview
wythoff -c k -r FEV cube | antiview
wythoff -c k -r EFV cube | antiview


The following are all symmetric with respect to element types

s snub [VEF]0V,0E,0F,0V0E0F
m meta [V,E,F]*0_1_2
b bevel [VEF]0v0e,0e0f,0f0v

[Roger Kaufman]

Hi Adrian,

On the commands in your last note I am getting different results for the
sets of 3 wythoff commands. Are they similar in other ways?

A quick run of the commands found some odd looking result on join,
chamfer and L0.

wythoff -c j cube | antiview
wythoff -c c cube | antiview
wythoff -c L0 cube | antiview

I am wondering conway could utilize from wythoff? I don't see why not.
It seems like those operators would just wrap these, but be able to do
successive operations. Some of the operators like kis and meta are
allowed to do N iterations. This would also be taken care of within the
conway program as it is now. Looking at the Conway Notation page, Tom
Ruen added *several dozen* operations!

I wondered if it could do tiles. Looks like you took care of that. Very
nice!

unitile2d 10 | antiview -v 0.05
unitile2d 10 > 3-4-6-4.off

wythoff -c a 3-4-6-4.off | antiview -v 0.1
wythoff -c d 3-4-6-4.off | antiview -v 0.1

Roger

P.S. I found a paper which talks about efficient processing for
polyhedron boolean operations. I will start a thread on it later.

[Adrian Rossiter]

Hi Roger

On Sun, 1 Oct 2017, Roger Kaufman wrote:
> On the commands in your last note I am getting different results for the sets
> of 3 wythoff commands. Are they similar in other ways?

The commands used one Conway operation pattern to produce the other
two Conway operations. To have three Conway operation patterns
produce the same result:

truncate, zip, expand -> truncate

wythoff -c t -r VEF cube | antiview

wythoff -c z -r FVE cube | antiview
wythoff -c e -r EFV cube | antiview

kis, needle and subdivide -> kis

wythoff -c k -r VEF cube | antiview

wythoff -c n -r FEV cube | antiview
wythoff -c u -r FVE cube | antiview

The last one has different colours because of the tile order in
the 'u' pattern. I have since updated the list so that operations
with equivalent patterns appear next to each other, and have the
patterns written consistently.

> A quick run of the commands found some odd looking result on join, chamfer
> and L0.
>
> wythoff -c j cube | antiview
> wythoff -c c cube | antiview
> wythoff -c L0 cube | antiview

This is because the vertices are laid out on the original surface, so
faces that surround a cube edge are fairly distorted. You can see what
is happening in the following command [image attached]

wythoff -c o cube | wythoff -c o | wythoff -c o | wythoff -c j | antiview

All the points are laid out on a cube, and the skew edge diamonds
are displayed with a triangulation crease "arbitrarily" on the long
or short diagonal.

> I am wondering conway could utilize from wythoff? I don't see why not. It
> seems like those operators would just wrap these, but be able to do
> successive operations. Some of the operators like kis and meta are allowed to
> do N iterations. This would also be taken care of within the conway program
> as it is now. Looking at the Conway Notation page, Tom Ruen added *several
> dozen* operations!

I will provide functions for a conway operator pattern lookup and
for processing a model with a pattern. It will be easy to generate
patterns for kisN and metaN.

I won't initially provide any way to apply operations only to selected
elements, e.g truncating only vertices with order-4. My first thought
was to have two patterns, one for base triangles where the V vertex
was selected, which would incude a tile around V, and one for where
it was not, where the adjacent tile would include the V point in its
path. However, I can see issues with this as a general solution, as
some pattern paths will need to be matched between the different
triangles, and other paths will not.

[Roger Kaufman]

Hi Adrian,

On 10/2/2017 5:26 AM, Adrian Rossiter wrote:

I won't initially provide any way to apply operations only to selected
elements, e.g truncating only vertices with order-4. My first thought

Currently the only operators in the conway program to take an N is Kis and Truncate.

It can use your truncate algorithm (in off_util) or do it the "dkd" style of classic Conway Notation. This implies that Kis take an N based on faces of N size, which I think is the dual operation of Truncate on vertices of N valance.

If need be, that option could be removed and the program could just call the built in truncate function all the time. It could report that tN resolves to dkNd, but not actually execute it that way.

I will provide functions for a conway operator pattern lookup and
for processing a model with a pattern. It will be easy to generate
patterns for kisN and metaN.

Also you mention kis along with meta using N. Does that mean that kisN would be a higher subdivision (like m3 is to meta) and not be the N of number of face sides?

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 3 Oct 2017, Roger Kaufman wrote:
> On 10/2/2017 5:26 AM, Adrian Rossiter wrote:
>> I won't initially provide any way to apply operations only to selected
>> elements, e.g truncating only vertices with order-4. My first thought
>
> Currently the only operators in the conway program to take an N is Kis and
> Truncate.
>
> It can use your truncate algorithm (in off_util) or do it the "dkd" style of
> classic Conway Notation. This implies that Kis take an N based on faces of N
> size, which I think is the dual operation of Truncate on vertices of N
> valance.
>
> If need be, that option could be removed and the program could just call the
> built in truncate function all the time. It could report that tN resolves to
> dkNd, but not actually execute it that way.

...

>> I will provide functions for a conway operator pattern lookup and
>> for processing a model with a pattern. It will be easy to generate
>> patterns for kisN and metaN.
>
> Also you mention kis along with meta using N. Does that mean that kisN would
> be a higher subdivision (like m3 is to meta) and not be the N of number of
> face sides?

I said kisN by mistake, I won't initially be adding in kisN as it has
the same issues as tN.

the operations I meant were the N versions for m3 and M3, in this table

https://en.wikipedia.org/wiki/Conway_polyhedron_notation#Extended_operators

I have already added them in. e.g. the pattern generated for M7 is

wythoff -p [F,V7,V5E2,V3E4,VE6]0_2_1e2e,*0_2_3,*0_3_4,4_0v4v,4E cube | antiview

I'll also add in oN (and eN can probably be generated with the same
function), and also look at uN and wN.

[Roger Kaufman]

Hi Adrian,

On 10/3/2017 12:21 PM, Adrian Rossiter wrote:
> I said kisN by mistake, I won't initially be adding in kisN as it has
> the same issues as tN.

If kN or tN were N>1 it could use the current built in methodology. When
N=1 it could use your calls.

I was looking at the conway code and what changes would happen. I think
this is enough of a paradigm shift that the current conway program
should be moved to unsupported as "conway_hart". Almost all the conway
calls use the substitution concept, while your new paradigm would do
direct calls for each operator. For example, a verbose output of join
does ambo and then dual...

conway -v jC | antiview

jC resolved to: daC
ambo
planarizing ...
dual
planarizing ...
done.

Yours would be a simple call:

wythoff -c j cube | canonical -p m | antiview

Or, to show substitution works one could just have this, where wythoff
would be the conway calls daC and planarization would happen inter-step
within conway.

wythoff -c a cube | canonical -p m | wythoff -c d | canonical -p m |
antiview


The infrastructure of the program would stay the same. The -d option
could be removed, or its action could be reversed and substitution
theory could be added. -t could be eliminated unless it was found to be
needed.

The only option I don't see is propeller. If this can't be generated by
wythoff, the current Hart code could stay for that. Reflect is a
transformation.

I could being transforming a new conway program if you think it is
ready? That way you could test new combinations of operators more
easily. I would have to know how the calls are done.

>
> the operations I meant were the N versions for m3 and M3, in this table
>
> https://en.wikipedia.org/wiki/Conway_polyhedron_notation#Extended_operators

The N for meta was my suggestion to Tom Ruen and seems to have filtered
into the page! But I didn't suggest the big M operator and he added
that. A quick look... he also has N for K,L,b,g,l,o,e,u,w. Even snub as
has N! And below are Coxeter and so much new work I haven't read it all!
I wonder if Tom is still adding things?

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 3 Oct 2017, Roger Kaufman wrote:

> I was looking at the conway code and what changes would happen. I think this
> is enough of a paradigm shift that the current conway program should be moved
> to unsupported as "conway_hart". Almost all the conway calls use the
> substitution concept, while your new paradigm would do direct calls for each
> operator. For example, a verbose output of join does ambo and then dual...
>
> conway -v jC | antiview
>
> jC resolved to: daC
> ambo
> planarizing ...
> dual
> planarizing ...
> done.
>
> Yours would be a simple call:
>
> wythoff -c j cube | canonical -p m | antiview

Next time I push an update I will include the relevant functions
for conway to call so you can experiment and see how it works out.

> The only option I don't see is propeller. If this can't be generated by
> wythoff, the current Hart code could stay for that. Reflect is a
> transformation.

I will add in propeller. The pattern I will use is

[V,VEF]1F,1_0V1E1F,1E

I started with a pattern like on the Wikipedia page,

[V,VE]1F1_0e1v,1E,1F

But I didn't visually like the result as much

wythoff -p [V,VE]1F,1F1_0e1v,1E cube | antiview
unitile2d -s t 2 -l 24 -w 8| wythoff -p [V,VE]1F,1F1_0e1v,1E| antiview
unitile2d -s t 2 -l 24 -w 8| wythoff -p [V,VE]1F,1F1_0e1v,1E -M | antiview

Compared to

wythoff -p [V,VEF]1F,1_0V1E1F,1E cube | antiview
unitile2d -s t 2 -l 24 -w 8| wythoff -p [V,VEF]1F,1_0V1E1F,1E| antiview
unitile2d -s t 2 -l 24 -w 8| wythoff -p [V,VEF]1F,1_0V1E1F,1E -M| antiview


I also looked at the snub-antiprism pattern:

[VEF2,VEF]0F,0e1v0F,0f1E1v,0e1V1f,-1E,-1V

Here it is being applied to a dihedron (with face centres lifted to give
it some volume)

polygon dih 6 | wythoff -f 0.5 -p [VEF2,V2E2F]0F,0e1v0F,0f1E1v,0e1V1f,-1E,-1V -a | antiview

And here the 2-fold edges (magenta and tan) in the previous model
have become triangles

unitile2d -s t 2 -l 24 -w 8| wythoff -p [VEF2,VEF]0F,0e1v0F,0f1E1v,0e1V1f,-1E,-1V -M| antiview


I could probably output a pattern for any polyhedron that is
processed by to_nfold (projecting it onto a dipyramid). Probably,
more of an academic exercise, although interesting that the different
primary-axis polyhedron types can be encoded in a short string.

It may also be possible for the symmetry triangle of polyhedron. However,
I think it would be tough to recognise a pattern on a general surface.

[Roger Kaufman]

Hi Adrian,

On 10/4/2017 2:24 PM, Adrian Rossiter wrote:
> Next time I push an update I will include the relevant functions
> for conway to call so you can experiment and see how it works out.

The George Hart code wouldn't have to be thrown away. Instead a switch
could be added to use Hart algorithms where available. This makes it
still useful to compare to Hart legacy online generator.

I was looking at why I added the -t switch. Comparisons show identical
output so I will remove that and use the Hart truncate for that mode,
but continue to use the off_util truncate when tN > 1. (and Wythoff
truncate for tN=1).

It will have to use the Hart kis algorithm for when kN>1


In a conversation I had with Tom Ruen, he told me that Conway Notation
was something that George Hart went forward with. But before GH, there
is little if any history, and John Conway seemed to drop the subject. He
doesn't cover it in any book. There is some evidence he suggested it in
the old archive. Sometimes I wonder if he is even aware anyone went
forward with it!

So the point is, the Wikipedia article for Conway Notation is held up by
its own bootstraps. Normally Wikipedia want solid references and so far
hasn't flagged the page. I decided to keep the GH code is as a mode, and
I should suggest to Tom Ruen to make a link to the Antiprism conway
notation help page as further evidence it is a real thing. Since we will
add many of the operations he has on the page will be of help this way.

Roger

[Adrian Rossiter]

Hi Roger

I have just pushed an update of wythoff. I added a library call
(documented in base/tiling.h), e.g

wythoff_make_tiling(out_geom, seed_geom, "a", true);

I have added M, m and o as patterns taking a general integer. The
general 'oN' operator has different kinds of pattern for even
or odd N: even N has a vertex at a face centre, odd N has a polygon
around a face centre. I haven't implemented a Class I frequency
operator (yet?) as it has three distinct patterns and it is quite
tedious to generate the wythoff patterns. Looking at the centre of
the following divisions, the centre is a vertex, aligned triangle,
or opposite aligned triangle

geodesic -M p -f 3 pol3 | antiview -v 0.01
geodesic -M p -f 4 pol3 | antiview -v 0.01
geodesic -M p -f 5 pol3 | antiview -v 0.01

I notice that L0 is the "square barrel" pattern

wythoff -M -c L0 schwarz_2_2_5p | canonical | antiview

I now assign all the final model coordinates first, which avoids a
merge. I also added vertex colours according to which elements are
involved in the pattern coordinates. All the colours can be seen with

wythoff -c o8 cube | antiview -e 0.01 -v 0.05

Adrian.

P.S. I also pushed your recent changes with a fix for an antiprism_rk
header.

[Roger Kaufman]

Hi Adrian,

o.k. I will look at this next week.

On 10/13/2017 3:07 PM, Adrian Rossiter wrote:
> P.S. I also pushed your recent changes with a fix for an antiprism_rk
> header.

I finally did what I should have and add an include path in my
development makefile! This shouldn't be a problem going forward.

I was looking at wythoff.cc and I noticed the table for
schwarz_triangles_verts was reformatted by clang. I put clang statements
around the nicely formatted table from version 0.24. Then when I tested
clang format on wythoff.cc it re-indented other code. If you changed the
table from previous versions (it doesn't appear you did) let me know.
Otherwise I will push the formatted one.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 13 Oct 2017, Roger Kaufman wrote:
> I was looking at wythoff.cc and I noticed the table for
> schwarz_triangles_verts was reformatted by clang. I put clang statements
> around the nicely formatted table from version 0.24. Then when I tested clang
> format on wythoff.cc it re-indented other code. If you changed the table from
> previous versions (it doesn't appear you did) let me know. Otherwise I will
> push the formatted one.

There shouldn't be any changes, so that sounds good. If you wanted,
while you were looking at this, you could also run 'make format_all'
for the same commit.

I am thinking about making a release, maybe in a couple of weeks time,
just to get out recent changes. I will be removing the old SWIG based
Python module code. (The new module code uses pybind11, but I haven't
had chance to move this forward much. It isn't very tightly integrated
and will be easy to add in when it is ready for use.) I will also
see if I can complete the face number label changes for stellate
(these turned out to be a bit fiddly), and then make a snapshot.

Adrian.

[Roger Kaufman]

Hi Adrian,

On 10/14/2017 5:57 AM, Adrian Rossiter wrote:
> There shouldn't be any changes, so that sounds good. If you wanted,
> while you were looking at this, you could also run 'make format_all'
> for the same commit.

I ran this today and found programs formatted that I thought were
already formatted! I also found what I think was miller.1 and stellate.1
were pushed at some time as empty files. So these should be right now. I
pushed todays result.

>
> I am thinking about making a release, maybe in a couple of weeks time,
> just to get out recent changes. I will be removing the old SWIG based
> Python module code. (The new module code uses pybind11, but I haven't
> had chance to move this forward much. It isn't very tightly integrated
> and will be easy to add in when it is ready for use.) I will also
> see if I can complete the face number label changes for stellate
> (these turned out to be a bit fiddly), and then make a snapshot.
>

I don't foresee the conway.cc changes being severe and hopefully can be
done by the end of next week. However, since this is also testing the
new calls unexpected things could happen.

I will eventually work on an offbool program but that will take months
so that won't be for this release.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/13/2017 3:07 PM, Adrian Rossiter wrote:

> I have just pushed an update of wythoff. I added a library call
> (documented in base/tiling.h), e.g
>
>    wythoff_make_tiling(out_geom, seed_geom, "a", true);

I pushed a preliminary version of conway which utilizes the Wythoff
operators. It isn't complete as it doesn't yet utilize N for Wythoff
operations. Which operators can utilize N? Currently GHart only utilized
N for kis and truncate (or for seeds P, A, Y).

The changed options no longer has -t. -d has been changed to -s and -g
has been added.

  -s        apply Conway Notation string substitutions
  -g        use George Hart algorithms (sets -s)

The original GHart code had only ambo, dual, gyro, kis, propellor.
Chamfer and whirl were added by us. All other operations were done by
substitution.

If -g is specified, substitutions are enforced. Any available GHart
function is executed. If there isn't one then the Wythoff operators can
execute so -g mode will still work with the new operators.

If the truncate operator has N it uses the Antiprism function instead of
the Wythoff operator.

The x (null) operation was removed. It wasn't in the original design and
I've never used it. It was to allow for a planarization step without any
other changes.

Planarization was a problem on some models and was solved by orienting
the result from wythoff_make_tiling(). wythoff_make_tiling has geom for
both seed and result and I hope this won't cause a problem.

Todo:
The only new operator added to input checking is 'q'. I have to come up
with a way adding these easier.
Verbose() has to have an entry for every operator. I think table driven
operations table would help with this and input checking.
Testing and unknown issues.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/15/2017 1:39 PM, Roger Kaufman wrote:
> Todo:
> The only new operator added to input checking is 'q'. I have to come
> up with a way adding these easier.
> Verbose() has to have an entry for every operator. I think table
> driven operations table would help with this and input checking.
> Testing and unknown issues.

I pushed a version of conway which I am testing. There are still some
bugs and some planarization is failing. For example seed starts
collapsing the cube with 1 iteration of planarization. Yet with -i 0, SC
and C are visually identical models!

./conway -v SC -i 1 | antiview

I used a table for the operators. Since the program doesn't take 2
character operators, those are processed as special cases. This is what
I have as far as N goes. The boolean variables are. 1) N is allowed and
2) if it is also a GHart operator.

Is m3 medial-3 or meta-3? The verbose operation calls that meta(3), but
it is because meta may take any N. L was a problem because stand alone L
is allowed, where stand alone M is not. This has been patched.

t and k with N>1 need to use the GHart code. whirl, w, uses the existing
function in all cases.

propellor was spelled with an 'or' in G Hart's code and is that way on
the Wiki page. It is an semi-accepted alternative spelling, but in some
circles the 'or' is a verb while the 'er' is the actually object (noun).

I will have to add the new operators to the help. The program is getting
more useful.

 ConwayOperator conway_operator_list[]{
    {"a",  "ambo",          false, true  },
    //{"b3", "bevel3",        false, false }, // allows only 3
    {"b",  "bevel",         true,  false },
    {"c",  "chamfer",       false, true  },
    {"d",  "dual",          false, true  },
    {"e",  "expand",        false, false },
    {"g",  "gyro",          false, true  },
    {"j",  "join",          false, false },
    {"k",  "kis",           true,  true  },
    {"K",  "stake",         false, false },
    //{"L0", "joined-lace",   false, false }, // allows only explicit 0
    {"L",  "lace",          true,  false },
    {"l",  "loft",          false, false },
    //{"M0", "joined-medial", false, false }, // allows only explicit 0
or 3
    //{"M3", "edge-medial-3", false, false },
    {"M",  "medial",        true,  false },
    //{"m3", "medial-3",      false, false }, // allows any N
    {"m",  "meta",          true,  false },
    {"n",  "needle",        false, false },
    //{"o3", "ortho3",        false, false }, // allows any N
    {"o",  "ortho",         true,  false },
    {"p",  "propellor",     false, true  },
    {"q",  "quinto",        false, false },
    {"r",  "reflect",       false, false },
    {"S",  "seed",          false, false },
    {"s",  "snub",          false, false },
    {"t",  "truncate",      true,  false },
    {"u",  "subdivide",     false, false },
    {"w",  "whirl",         false, true  },
    {"X",  "cross",         false, false },
    {"z",  "zip",           false, false },
};

Roger

[Adrian Rossiter]

Hi Roger

On Sun, 15 Oct 2017, Roger Kaufman wrote:
> Planarization was a problem on some models and was solved by orienting the
> result from wythoff_make_tiling(). wythoff_make_tiling has geom for both seed
> and result and I hope this won't cause a problem.

Reusing the geom shouldn't be a problem.

Regarding orientation, several operators have to produce non-oriented
polyhedra for wythoff, this is so that tiles of the same kind can be
coloured the same. E.g. producing an oriented result for meta needs
two tiles rather than one

wythoff -c m tet | antiview
wythoff -c [V,E,F]0_1_2,-2_1_0 tet | antiview

Adrian.

[Adrian Rossiter]

Hi Roger

On Mon, 16 Oct 2017, Roger Kaufman wrote:
> I pushed a version of conway which I am testing. There are still some bugs
> and some planarization is failing. For example seed starts collapsing the
> cube with 1 iteration of planarization. Yet with -i 0, SC and C are visually
> identical models!
>
> ./conway -v SC -i 1 | antiview

The wythoff result of S has digon faces, if you strip these then the
model behaves correctly

opts.print_status_or_exit(
wythoff_make_tiling(geom, geom, wythoff_op, true));

vector<int> dels;
for(int i=0; i<(int)geom.faces().size(); i++) {
if(geom.faces(i).size() < 3)
dels.push_back(i);
}
geom.del(FACES, dels);

I don't think you have the current wythoff, as this has a bug that
deletes the digons (geom.del(VERTS...) deletes faces with fewer than
three sides, even when deleting free vertices). I will be pushing an
updated version, after a bit more testing.

> Is m3 medial-3 or meta-3? The verbose operation calls that meta(3), but it is
> because meta may take any N.

I don't know. The first wikipedia table as 'm' as meta medial. In a
later table 'm3' is medial-3.

> propellor was spelled with an 'or' in G Hart's code and is that way on the
> Wiki page. It is an semi-accepted alternative spelling, but in some circles
> the 'or' is a verb while the 'er' is the actually object (noun).

I'll change it to 'propellor'.

I missed the question on your other message about the operators that can
take an N value. I have listed the ones that wythoff handles at the end
of 'wythoff -c list'. There are some others mentioned on the Wikipedia
page like e, b, u, etc. I don't know which of these I will implement.

I am not sure about the o/e numbering. S could be o1, o is o2, and
o3 is o3, then d is e0, e is e1 and e3 is e2. This means that the
numbers look like they match the results and, as a general result

o(N) = de(N-1) = e0e(N-1)

The e numbers could all be shifted up by 1, but it seems better that
the o numbers should be shifted back by one, then the special cases
have index 0, S=o0, d=e0, the normal operators have index 1, e=e1, o=o1,
and o3/e3, which are the next in the sequence, would be o2/e2, and,

oN = deN = e0eN

Adrian.

[Roger Kaufman]

Hi Adrian

On 10/16/2017 8:39 AM, Adrian Rossiter wrote:
> I missed the question on your other message about the operators that can
> take an N value. I have listed the ones that wythoff handles at the end
> of 'wythoff -c list'. There are some others mentioned on the Wikipedia
> page like e, b, u, etc. I don't know which of these I will implement.

It appears that M works with N  when N != 1. There is no stand alone M,
and it must always have an integer attached.

wythoff -c M0 cube | antiview
wythoff -c M1 cube | antiview
wythoff -c M2 cube | antiview

But with L, there is a stand alone L and L0 (zero) but no other L in the
series.

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 16 Oct 2017, Roger Kaufman wrote:

'wythoff -c list' isn't clear on this, and I will update it. The general
N is for numbers 3 and above, and any numbers below 4 for an operator are
specifically listed.

L0 isn't part of a series according to the Wikipedia page, so perhaps
it shouldn't be called L0. The LN refers to L on faces of N sides.

What do you think about breaking with Wikipedia for some of the numbering?
In particular for o/e

o0 = S, e0 = d
o1 = o, e1 = e
o2 = Wiki o3, e2 = Wiki e3

meta/medial

m0 = k
m1 = m
m2 = Wiki m3
m3 = Wiki m4

bevel

b0 = z
b1 = b
b2 = Wiki b3

With e, o, b, m numbered like this the 0 is a "lower level" operation
and the base operation has number 1.

I don't know why M0 has number 0, for MN to match m it could have numbers

M1 = ortho
M2 = Wiki M3

[Roger Kaufman]

Hi Adrian,

Would it be helpful to get Tom Ruen to weigh in? He's the author of the
CN page.

I can try.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/16/2017 11:20 AM, Adrian Rossiter wrote:

> The LN refers to L on faces of N sides.

LN gives back the same message for any N other than 0.

wythoff: error: option -c: Conway operator 'L4' not known

Will this be made available?

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 16 Oct 2017, Roger Kaufman wrote:
> Would it be helpful to get Tom Ruen to weigh in? He's the author of the CN
> page.
>
> I can try.

I would be interested in why Tom chose the numbering scheme he did.

[Adrian Rossiter]

Hi Roger

On Mon, 16 Oct 2017, Roger Kaufman wrote:

I have no immediate plans to add it, because LN works like kN.
L0 is a different operator to L in the same way that j is a
different operator to k.

[Roger Kaufman]

Hi Adrian,

On 10/16/2017 1:47 PM, Adrian Rossiter wrote:
> I have no immediate plans to add it, because LN works like kN.
> L0 is a different operator to L in the same way that j is a
> different operator to k.

I put out an invite to Tom Ruen to join the group. I forwarded the
questions you had about numbering.

In the mean time, the version of conway pushed at this time has M as
allowing 0, 2 through N. (just that, it misses 1 seems like 0 should be 1!)

With that it does all the operators you have in wythoff. I just have to
add the additional operators the the help. Otherwise there isn't much
more I have to do to it.

I noticed you have an implementation for whirl. Do you plan one? In the
mean time conway uses the function for it.

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 16 Oct 2017, Roger Kaufman wrote:

> I noticed you have an implementation for whirl. Do you plan one? In the mean
> time conway uses the function for it.

I'll add in w, the pattern can be

wythoff -p [VF,VE,V]0F,0_1E1_2fe1_0ev,1E dod | antiview

I might do the wN = w(N, N-1) general pattern, as there is only one kind
of pattern. Again, I think it would be better to be wN = w(N+1, N),
then w0 = S and w1 = w.

[Roger Kaufman]

Hi Adrian,

I added a line to verbosity in conway if after a step: non-orientable
geometry if that is the case.

I noticed with b3 produced this. Upon further observation I noticed that
some of the faces where duplicates.

wythoff -c b3 cube | off_report

wythoff -c b3 cube | antiview -n f

wythoff -c b3 cube | off_util -M vef |  off_report

With the duplicate faces it doesn't report as a polyhedron so I suppose
it follows it is non-orientable. In any case leaving it like that, any
further operation fails. I places a sort merge in after the wythoff call
in conway.

I noticed you had updated Antiprism, so I have caught up before I
retested this. I've also pushed conway. When you add whirl and recompile
it, whirl will work in conway. Still working on the help, conway -H.

Roger

[Adrian Rossiter]

Hi Roger

On Tue, 17 Oct 2017, Roger Kaufman wrote:
> I added a line to verbosity in conway if after a step: non-orientable
> geometry if that is the case.
>
> I noticed with b3 produced this. Upon further observation I noticed that some
> of the faces where duplicates.
>
> wythoff -c b3 cube | off_report

The b3 issue was previously hidden because I was merging everything. The
edge rectangle tile is naturally repeated by "rotation", and doesn't need
to be "mirrored", which is what leads to the extra copies. Leaving out
the * the pattern works fine

wythoff -p [VEF,E2F]1_0e0v,0e0f,1_0f0_1f,1E cube | antiview -n f

> With the duplicate faces it doesn't report as a polyhedron so I suppose it
> follows it is non-orientable. In any case leaving it like that, any further
> operation fails. I places a sort merge in after the wythoff call in conway.

The wythoff call for Conway operators should produce orientable output
for any orientable input. So it may be that the sort merge isn't
needed. However, for general input it is possible to produce double
wound output

wythoff -c s schwarz_2_2_5/2p | antiview -n f
wythoff -c s schwarz_2_2_5/2p | off_report
...
oriented = no
orientable = yes
connectivity = polyhedron, closed, even, known

[Roger Kaufman]

Hi Adrian,

On 10/17/2017 6:31 AM, Adrian Rossiter wrote:
> The wythoff call for Conway operators should produce orientable output
> for any orientable input. So it may be that the sort merge isn't
> needed. However, for general input it is possible to produce double
> wound output
>
>    wythoff -c s schwarz_2_2_5/2p | antiview -n f
>    wythoff -c s schwarz_2_2_5/2p | off_report
>       ...
>       oriented = no
>       orientable = yes
>       connectivity = polyhedron, closed, even, known
>

In the lastest push I commented out the sort merge. However, I am
wondering if it should be added as an optional switch for inter-step
processing considering it isn't impossible it can be needed.

I added the new operators in the help. I added in summary rules for n.

I think the conway help should list the Hart substitution rules. It
could also list other known equivalencies such as the ones you are finding.

I should add a note that the new operators can work on tilings. But warn
that the Hart functions cannot work on them.

I found some cases where planarization caused a models to shrink to 0
volume, so the planarization step resizes models to an average vertex
radius of 1.

For Hart substitutions a patch had to be added such that while e.g. o ->
jj but o3 cannot be. This is the case for b, o and m.

For the string parser, for M, it needed to add a patch such that M
requires a number! It is the only such case.

The web page lists some seeds for tilings. It might be interesting to
add them but would probably have to be hard coded off files.

I noticed he has some operators x, y and v which are combinations of
other operators. These could be forced to substitute if needed. Then he
has whirl with an n,m type format (if implemented, the parser is going
to love that!)

Roger

[Roger Kaufman]

HI Adrian,

On 10/16/2017 11:20 AM, Adrian Rossiter wrote:

> What do you think about breaking with Wikipedia for some of the
> numbering?
> In particular for o/e
>
> o0 = S,         e0 = d
> o1 = o,         e1 = e
> o2 = Wiki o3,        e2 = Wiki e3
>
> meta/medial
>
> m0 = k
> m1 = m m2 = Wiki m3
> m3 = Wiki m4
>
> bevel
>
> b0 = z
> b1 = b
> b2 = Wiki b3
>
> With e, o, b, m numbered like this the 0 is a "lower level" operation
> and the base operation has number 1.
>
> I don't know why M0 has number 0, for MN to match m it could have numbers
>
> M1 = ortho
> M2 = Wiki M3

I now list the Hart substitutions in the help.

I am now looking at a list of known equivalencies. They are listed here
and there on the wiki page.

As far as the above, I think I am with you, and if these things are
equivalent it is a stronger system.

The only special operators I list in Verbose are L0 and M0. Everything
else I have like m(2) k(3) etc. Even b(3). (the verbose output isn't
that important).

As for other operations like M3, if they have names I can list those as
aliases in the help.

I can list the above relations in the help. If there are other operators
that can be derived from current operators I can add a Wythoff
substitution system.

For example:

x (exalt) -> kdkd or dtkd
y (yank) -> dkdk or dktd
v (volute) -> dwd

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 16 Oct 2017, Adrian Rossiter wrote:
> I'll add in w, the pattern can be
>
> wythoff -p [VF,VE,V]0F,0_1E1_2fe1_0ev,1E dod | antiview

This works for a polyhedron meta tiling, but is not correct for other
kinds of base tiling. One segment of the hexagonal face (Tile 1) winds
the wrong way around the E vertex, which has the effect of merging faces

Original pattern:
unitile2d -s t 2 -w 6 -l 24 | wythoff -M -p [VF,VE,V]0F,0_1E1_2fe1_0ev,1E | antiview

Tiling pattern: [VF,VE,V]0F,0_1E1_2V1_0ev,1E
Tile Counts:
0 : 64
1 : 64
2 : 64

Correct pattern:
unitile2d -s t 2 -w 6 -l 24 | wythoff -M -p [VF,VE,V]0F,0_1vf1_2fe1_0ev,1E | antiview

Tiling pattern: [VF,VE,V]0F,0_1vf1_2fe1_0ev,1E
Tile Counts:
0 : 64
1 : 192
2 : 64

[Adrian Rossiter]

Hi Roger

On Tue, 17 Oct 2017, Roger Kaufman wrote:
> On 10/16/2017 11:20 AM, Adrian Rossiter wrote:
>> What do you think about breaking with Wikipedia for some of the numbering?
>> In particular for o/e
>>
>> o0 = S,         e0 = d
>> o1 = o,         e1 = e
>> o2 = Wiki o3,   e2 = Wiki e3
>>
>> meta/medial
>>
>> m0 = k
>> m1 = m m2 = Wiki m3
>> m3 = Wiki m4
>>
>> bevel
>>
>> b0 = z
>> b1 = b
>> b2 = Wiki b3
>>
>> With e, o, b, m numbered like this the 0 is a "lower level" operation
>> and the base operation has number 1.
>>
>> I don't know why M0 has number 0, for MN to match m it could have numbers
>>
>> M1 = ortho
>> M2 = Wiki M3

...

> As far as the above, I think I am with you, and if these things are
> equivalent it is a stronger system.
>
> The only special operators I list in Verbose are L0 and M0. Everything else I
> have like m(2) k(3) etc. Even b(3). (the verbose output isn't that
> important).

Thanks for the emails you sent. It seems then that the Wikipedia operator
numbers were chosen based on edge divisions, and this has led to the base
operator tending to correspond to N=2. I think it would be more natural to
have the base operator as 1, and I have just pushed the changes for this.

I have also added in bN and eN. Apart from M0 and L0, every operator
that takes a number is now generated, including when N is 0 and 1.
The models for 0 follow the general pattern for their operator
and have no special handling to produce the lower level operation.

Ideally, M0 would have a different name, then M3 could be M = M1,
and M0 could be the lower level operator ortho. For now I have
M0 = M0, M1=o, M2=Wiki M3.

[Adrian Rossiter]

Hi Roger

On Thu, 19 Oct 2017, Adrian Rossiter wrote:
> I have also added in bN and eN. Apart from M0 and L0, every operator
> that takes a number is now generated, including when N is 0 and 1.
> The models for 0 follow the general pattern for their operator
> and have no special handling to produce the lower level operation.

Just to note that the printed pattern in the wythoff report is
created from the internal representation of the pattern, and will
print pairs of reflections as a rotation where possible.

Hence, the generated central face of bN is:
b6: 0_1_2_3v2_1_0e
b4: 0_1_2v1_0e
b2: 0_1v0e
b0: 0ve

But in b0, the v and e reflections are no longer separated by a point,
and the printout reports this face as 0F.

Apart from tile order, the b0 pattern is identical to z

wythoff -c b0 cube | antiview

Tiling pattern: [EF]0e0f,0F,0E
Tile Counts:
0 : 8
1 : 6
2 : 12

wythoff -c z cube | antiview

Tiling pattern: [EF]0e0f,0E,0F
Tile Counts:
0 : 8
1 : 12
2 : 6

[Roger Kaufman]

 Hi Adrian,

On 10/19/2017 7:42 AM, Adrian Rossiter wrote:
> Thanks for the emails you sent. It seems then that the Wikipedia operator
> numbers were chosen based on edge divisions, and this has led to the base
> operator tending to correspond to N=2. I think it would be more
> natural to
> have the base operator as 1, and I have just pushed the changes for this.

Tom Ruen was working on a way to generate the Goldberg polyhedra with
conway notation. I think this was the motivation for some of the new
operators.

I had suggested G(n,m) with the motive that Antiprism already has code
to generate them. But this would treat the problem as making Goldberg's
seed input. In retrospect, this was cheating!

It looks like he also went another way to using a two parameter whirl
operation. I don't know if he came up with a blanket solution.

> I have also added in bN and eN. Apart from M0 and L0, every operator
> that takes a number is now generated, including when N is 0 and 1.
> The models for 0 follow the general pattern for their operator
> and have no special handling to produce the lower level operation.

I will be able to come up with more general code to handle the symbol 0
in the string . While the stand alone operator is like operator(1).

> Ideally, M0 would have a different name, then M3 could be M = M1,
> and M0 could be the lower level operator ortho. For now I have
> M0 = M0, M1=o, M2=Wiki M3.

I think we have artistic license to change these now. I would go ahead
and use another letter. When Tom gets back around to working on this
page, he can change the operators as per working code. I'll also ask him
to add the antiprism's conway notation help page to the links.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/19/2017 7:42 AM, Adrian Rossiter wrote:

> Ideally, M0 would have a different name, then M3 could be M = M1,
> and M0 could be the lower level operator ortho. For now I have
> M0 = M0, M1=o, M2=Wiki M3.

Just to note, wythoff won't take M but it will take M1. I have a patch
in conway which I've updated for today.

wythoff -c M cube | antiview

wythoff -c M1 cube | antiview

Roger

[Vortex Swirling]

I noticed the word negative was misspelled in a wythoff error message

[Adrian Rossiter]

Hi Roger

All I did was to move the M numbering back 2, but maybe it is better
to make M consistent now. I have therefore just pushed a change that:
renames M0 to J, adds in M as M1, starts the M sequence at 0 (M0 = ortho).

I also rewrote some tile orders so that, for example, e1 has the same
colours as e

I also corrected the spelling mistake, thanks.

[Roger Kaufman]

Hi Adrian,

On 10/20/2017 7:08 AM, Adrian Rossiter wrote:

All I did was to move the M numbering back 2, but maybe it is better
to make M consistent now. I have therefore just pushed a change that:
renames M0 to J, adds in M as M1, starts the M sequence at 0 (M0 = ortho).

I haven't seen the update yet but will try later.

I added a section to the extended help for equivalent operations which now looks like this. If Tom Ruen changes the wiki page, only the top line would be needed.

b0 = z        e0 = d        o0 = S        m0 = k        M0 = o
b1 = b        e1 = e        o1 = o        m1 = m        M1 = M
b2 = Wiki b3  e2 = Wiki e3  o2 = Wiki o3  m2 = Wiki m3  M2 = Wiki M3

I could add these, but they are just above it in the Hart substitution rules

e  -> aa
b  -> ta
o  -> jj
m  -> kj
t  -> dk
j  -> dad
s  -> dgd

The wiki page talks of 3 tiling seeds

• Q = Quadrille = Square tiling
• H = Hextille = Hexagonal tiling = dΔ
• Δ = Deltille = Triangular tiling = dH

I looked into compiling in tilings, thinking that instead of Q and H, it could be Zn where n was 1 to 11 for regular tilings. That would require too much in a library for this one thing.

Instead, I add lines into the extended help

Note: Antiprism Extensions will work on tilings. Hart algorithms (-d) will not
e.g.: unitile2d 3 | conway p -i 0 | antiview -v 0.1 (-i 0 for no planarization)

Next I realized for seeds P, A and Y which are limited to 3 and above, could actually be 2. But what I've found is that it is really a squashed prism and has faces of 0 area (not digons). This causes problems.

What would be better is to have a polygon seed. The e will expand to a tiling. I am wondering what capital letter I should use for that. P is already used. T (for tile) is already tetrahedron. It might be safe to use something like Z.

I think adding polygons is a more comprehensive solution.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 20 Oct 2017, Roger Kaufman wrote:
> On 10/20/2017 7:08 AM, Adrian Rossiter wrote:
>> All I did was to move the M numbering back 2, but maybe it is better
>> to make M consistent now. I have therefore just pushed a change that:
>> renames M0 to J, adds in M as M1, starts the M sequence at 0 (M0 = ortho).
>
> I haven't seen the update yet but will try later.

I am not sure what happened, but it is pushed now.

> I looked into compiling in tilings, thinking that instead of Q and H, it
> could be Zn where n was 1 to 11 for regular tilings. That would require too
> much in a library for this one thing.

I want to extend the schwarz_ models to also work for planar and
hyperbolic triangles. For something like schwarz_3_3_3p the model
would be a "suitably" sized tiling of equilateral triangles

https://en.wikipedia.org/wiki/Schwarz_triangle#Triangles_for_the_Euclidean_plane

The plane versions I could do first, as they are straightforward.
You would be able to convert schwarz_4_4_2p to squares and
schwarz_6_3_2p to hexagons (and schwarz_3_3_3 to larger triangles!)
by the wythoff "Seed" operation.

The hyperbolic tilings are harder, as besides calculating the
coordinates, the tiling has to be expanded from the centre
algorithmically.

> Instead, I add lines into the extended help
>
> Note: Antiprism Extensions will work on tilings. Hart algorithms (-d) will
> not
> e.g.: unitile2d 3 | conway p -i 0 | antiview -v 0.1 (-i 0 for no
> planarization)

This is useful anyway, as it allows some control over the base tiling.

> Next I realized for seeds P, A and Y which are limited to 3 and above, could
> actually be 2. But what I've found is that it is really a squashed prism and
> has faces of 0 area (not digons). This causes problems.
>
> What would be better is to have a polygon seed. The e will expand to a
> tiling. I am wondering what capital letter I should use for that. P is
> already used. T (for tile) is already tetrahedron. It might be safe to use
> something like Z.
>
> I think adding polygons is a more comprehensive solution.

I didn't follow this very well.

Are the seed numbers currently working? I tried this from the help

conway t5dA5
conway: error: Unexpected character in position 5: 5

[Roger Kaufman]

Hi Adrian,

On 10/20/2017 10:43 AM, Adrian Rossiter wrote:

Next I realized for seeds P, A and Y which are limited to 3 and above, could
actually be 2. But what I've found is that it is really a squashed prism and
has faces of 0 area (not digons). This causes problems.

What would be better is to have a polygon seed. The e will expand to a tiling. I am wondering what capital letter I should use for that. P is already used. T (for tile) is already tetrahedron. It might be safe to use something like Z.

I think adding polygons is a more comprehensive solution.

I didn't follow this very well.

Are the seed numbers currently working? I tried this from the help

   conway t5dA5
   conway: error: Unexpected character in position 5: 5

That was a bug I found last night. Also I found a bug in the base/canonic.cc where the stop percentage was hard coded to 80 percent, and a warning was printed. This happened because the length of a dypyramid to its width could trigger this percentage. For the wrapper calls to planarization and canonicalization, they are meant to be controlled by maximum iterations only. I have made a note of this in the comments and pushed the change.

I tried operating on prism and pyramid of n=2 and it is just too problematic, that has been set back to a minimum of 3. So instead I added a proposed Z operand (or seed) for polygons. If a polygon is used, planarization is set to 0 and George Hart mode is disabled (and warning flagged)

This would act on a pentagon

conway e2Z5 | antiview

I thought this could produce tilings, but the expansion really on works on Z4! So I guess it can produce square tilings.

conway e6Z4 | antiview -v 0.02
conway e6Z6 | antiview -v 0.02

Also it has a problem with dual

conway dZ5 | antiview

wythoff -c d pol5 | antiview

I have pushed the latest version.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 20 Oct 2017, Roger Kaufman wrote:

> On 10/20/2017 10:43 AM, Adrian Rossiter wrote:
> I tried operating on prism and pyramid of n=2 and it is just too problematic,
> that has been set back to a minimum of 3. So instead I added a proposed Z
> operand (or seed) for polygons. If a polygon is used, planarization is set to
> 0 and George Hart mode is disabled (and warning flagged)

...

> Also it has a problem with dual
>
> conway dZ5 | antiview
>
> wythoff -c d pol5 | antiview

It is tough to dualise a single face(!), but the geometry is
empty because wythoff will discard a face if it can't complete
the circuit, and then the free vertices are deleted at the end.

There are a couple of possibilities for processing dihedra with
wythoff. One is to lift the face centres

polygon dih 5 | wythoff -f 0.8 -c e | antiview

And the other is to use a ready made spherical 'meta' tiling for
the base

wythoff -M -c e schwarz_2_2_5p | antiview

You could use this second approach to get some volume into the flat
constructions. For example, the following command applies 'expand' to
a digonal pyramid (to produce a gyrobifastigium!)

wythoff -c m pyr3 | off_trans -C | off_util -S | to_nfold 2 | wythoff -M -c e | antiview

The easiest approach might be to hardcode the digonal base tilings of
the models of interest, and I could add a flag for the wythoff call
to indicate that the base model is a 'meta' tiling.

[Roger Kaufman]

Hi Adrian,

On 10/20/2017 3:21 PM, Adrian Rossiter wrote:
> There are a couple of possibilities for processing dihedra with
> wythoff. One is to lift the face centres
>
>    polygon dih 5 | wythoff -f 0.8 -c e | antiview

This doesn't work on many of the operations.

polygon dih 5 | wythoff -f 0.8 -c j | antiview

> And the other is to use a ready made spherical 'meta' tiling for
> the base
>
>    wythoff -M -c e schwarz_2_2_5p | antiview

I'm not sure what the -M operations means as the meta (m) operation
produces near correct results. see below.

> You could use this second approach to get some volume into the flat
> constructions. For example, the following command applies 'expand' to
> a digonal pyramid (to produce a gyrobifastigium!)
>
>    wythoff -c m pyr3 | off_trans -C | off_util -S  | to_nfold 2 |
> wythoff -M -c e | antiview

Thats cool!

> The easiest approach might be to hardcode the digonal base tilings of
> the models of interest, and I could add a flag for the wythoff call
> to indicate that the base model is a 'meta' tiling.

The main ones which would be useful is the triangular, square, and hex
tilings (as defined on the page) because all the other regular tilings
can then be produced. Originally conway notation was developed (at a
minimum) as a way to produce all the Platonic and Archimedian forms. So
hard coding might be appropriate for these. Or it could just rely on
unitile2d, but there is no way to detect its a tiling. In that case
maybe a -t switch for tiling mode might help.

It follows that all regular tilings could be produced this way from
elementary seeds.

I found a way to almost create a hex tiling. But it can't get rid of all
the pentagons. off_util -T 0.05, 2 segfaults (I didn't expect it to work!).

conway cqZ6 | antiview -v 0.02

Then the meta (m) operation will almost produce the tiling on the Conway
Notation page.

conway mcqZ6 | antiview -v 0.02

What is missing in the concept is, while inter-step planarization is
meaningless with tilings, an inter-step "make faces as close to regular
as possible" would be helpful. I think making minmax -a u as a form or
planarization something I once considered? It was.

conway cqZ6 | minmax -a u | antiview -v 0.02
conway tcqZ6 | minmax -a u | antiview -v 0.02
conway mcqZ6 | minmax -a u | antiview -v 0.02

Roger

[Roger Kaufman]

Hi Adrian,

On 10/20/2017 4:04 PM, Roger Kaufman wrote:
> I think making minmax -a u as a form or planarization something I once
> considered? It was.

I gave this a quick shot and it works in principle! It straightens out
hexagonal tilings quite nicely (the few outer pentagons remain seem to
be benign). conway doesn't have to do anything except force -p u when
tilings are detected, or use -t for external input.

When working with other polyhedra using -p u makes some very freakish
shaped models! I have a screenshots of

conway -v accqZ 6 -p u | antiview -v 0.02 (the tiling)
conway -v accqA6 -p u | antiview -v 0.02

I haven't pushed this. In order to port the function for -p u, I had to
place the class iter_params in base. Then I placed a wrapper around the
function for -p u.

I think minmax would work fine without the iter_params class, and the
code could be changed just a bit to look like the other programs, in
particular canonical which I just worked on. It has -L having a limit of
16 instead of 12. I think this might be my doing.

The only thing is if I go to this extend of coding it will take me a
couple of weeks to complete and I know you want to do a release soon.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 20 Oct 2017, Roger Kaufman wrote:

> On 10/20/2017 3:21 PM, Adrian Rossiter wrote:
>> There are a couple of possibilities for processing dihedra with
>> wythoff. One is to lift the face centres
>>
>>    polygon dih 5 | wythoff -f 0.8 -c e | antiview
>
> This doesn't work on many of the operations.
>
> polygon dih 5 | wythoff -f 0.8 -c j | antiview

It should work on all the operations. The problem is that not all
the results are easy to display. If you process the result of the
command above with 'kis' you can see that wythoff did create the
five skew quads when it applied 'j'

polygon dih 5 | wythoff -f 0.8 -c j | wythoff -c k | antiview

>> And the other is to use a ready made spherical 'meta' tiling for
>> the base
>>
>>    wythoff -M -c e schwarz_2_2_5p | antiview
>
> I'm not sure what the -M operations means as the meta (m) operation produces
> near correct results. see below.

The wythoff program doesn't act directly on a polyhedron. Instead
it first makes a triangle tiling like the meta operation, and applies
the pattern to that. The -M option indicates that the base model is a
suitable triangle tiling, and so the pattern is applied directly to
it. Compare

polygon dih 5 | wythoff -f 0.8 -c e | antiview

wythoff -M -c e schwarz_2_2_5p | antiview

and

polygon dip 10 | wythoff -c e | antiview
wythoff -c e schwarz_2_2_5p | antiview

Besides helping open out models, another reason for -M is that a
wythoff pattern can be applied to tilings that cannot be made by
applying meta to a polyhedron. E.g.

unitile2d -w 6 -l 24 -s t 2 | wythoff -M -c s | antiview

The snub polygons derived from "edge" elements are triangles,
not digons/edges as they would be for the snub of a polyhedron.

>> The easiest approach might be to hardcode the digonal base tilings of
>> the models of interest, and I could add a flag for the wythoff call
>> to indicate that the base model is a 'meta' tiling.
>
> The main ones which would be useful is the triangular, square, and hex
> tilings (as defined on the page) because all the other regular tilings can

This is something different, I was explaining how to give some volume to
the flat 2-fold versions of conway seed models. Using -f doesn't help
with models with digons (which are considered unorientable, although
they could be oriented by a rule, but the digon meta triangles would be
in coincident pairs and so not very good geometrically). E.g. the far
half of the following model is missing

off_util pyr2 | wythoff -f 0.5 -c e -a | antiview

[Roger Kaufman]

Hi Adrian,

On 10/20/2017 9:07 PM, Roger Kaufman wrote:
> The only thing is if I go to this extend of coding it will take me a
> couple of weeks to complete and I know you want to do a release soon.

I'm going to be away for the last half of next week. What I'm going to
do instead is make a copy of the function and parameterize it. I will
make a note of where it came from.

Then I won't alter minmax. But I will put a note in minmax that the
function also exists in canonic.cc.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 20 Oct 2017, Roger Kaufman wrote:

> I haven't pushed this. In order to port the function for -p u, I had to place
> the class iter_params in base. Then I placed a wrapper around the function
> for -p u.
>
> I think minmax would work fine without the iter_params class, and the code
> could be changed just a bit to look like the other programs, in particular
> canonical which I just worked on. It has -L having a limit of 16 instead of

...
[On Sat, 21 Oct 2017, Roger Kaufman wrote:]

> I'm going to be away for the last half of next week. What I'm going to do
> instead is make a copy of the function and parameterize it. I will make a
> note of where it came from.

The iter_params was a start at making the iteration functions more
consistent, and the reporting scheme clearer. Also, for a library
function that is reporting, it is better if the file stream is
configureable, which means another parameter for the iterating
function if something like iter_params isn't used. (I have previously
gone through the library to remove all the references to stderr in
base/*.cc that aren't related to debugging, but I need to review
this again).

[Roger Kaufman]

Hi Adrian

On 10/22/2017 5:08 AM, Adrian Rossiter wrote:
> The iter_params was a start at making the iteration functions more
> consistent, and the reporting scheme clearer. Also, for a library
> function that is reporting, it is better if the file stream is
> configureable, which means another parameter for the iterating
> function if something like iter_params isn't used. (I have previously
> gone through the library to remove all the references to stderr in
> base/*.cc that aren't related to debugging, but I need to review
> this again).

I checked /base and found that canonic.cc is probably has the most
stderr statements in it. It has the progress reporting, if that is set.
But there are also a couple of error messages. I just got rid of an
unnecessary one and push the result along with another bug fix.

The other error message could be passed as a char *. But I am not sure
how to approach the progress reporting which has always gone to stderr.

After having looked at what I did to port the minmax algorithm, I
realized the changes I am making are too severe for the minmax program.
However, the copy of the core loop will do. I use the paradigm of having
unsigned cnt, and then if num_iters is -1 it runs until it breaks out.
Or causes divergent behavior. This is different than in minmax where
num_iters must be set.

The canonic algorithms usually break out. But there are cases where the
accuracy never increases, and the program just begins to thrash. One
solution would be that if num_iters is -1, then take a sample every
(maybe) 10,000 iterations. If the next_sample is greater than
prior_sample - 1e8(?) then break out with "accuracy not increasing". If
it is thrashing, eventually this would break it out. This would need a
lot of testing so i'll put this on a todo list.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/21/2017 6:30 AM, Adrian Rossiter wrote:
> It should work on all the operations. The problem is that not all
> the results are easy to display. If you process the result of the
> command above with 'kis' you can see that wythoff did create the
> five skew quads when it applied 'j'
>
>    polygon dih 5 | wythoff -f 0.8 -c j | wythoff -c k | antiview

I played around with this, but I ended up working with 2d tilings.
Having made a port of the minmax -a code for "planarization" or perhaps
tile straightening, I was able to experiment with commands to generate
triangular and hex tilings form a seed polygon.

Now that it is in, take a look at these strings and see if the concept
is valid.

 Triangular:

I couldn't find anything that would expand a triangle beyond one step.
These three are "stuck".

conway L0Z3 | antiview -v 0.05
conway mZ3 | antiview -v 0.05 (will dual back to a single hexagon)
conway uZ3 | antiview -v 0.05

However, if we start with a hexagon and apply quinto, we can add a
chamfer and then the dual of that to get the triangular tiling.

conway dcqZ6 | antiview -v 0.05

The tiling can be grown by added more chamfers

conway dccqZ6 | antiview -v 0.05


Hexagonal:

just take the dual of the triangular tiling above.

conway ddcqZ6 | antiview -v 0.05

After that more layers can be added with chamfers

conway cddcqZ6 | antiview -v 0.05

Interestingly, the more duals we add, we lose layers and so eventually
the core returns to a hexagon and the dissolves completely!

conway dddddddccddcqZ6 | antiview -v 0.05

Note: what I intuitively thought should have worked was cZ6, thus
chamfering a hexagon. If that worked then the triangular tiling would be
generated by dual.


The solution for square tilings is easy, but I haven't found any other
operator than ortho > 0 that generates a tiling from a single polygon.

conway oZ4 | antiview -v 0.05
conway o2Z4 | antiview -v 0.05

Roger

[Roger Kaufman]

Hi Adrian,

On 10/22/2017 1:09 PM, Roger Kaufman wrote:
> Hexagonal:
>
> just take the dual of the triangular tiling above.
>
> conway ddcqZ6 | antiview -v 0.05
>
> After that more layers can be added with chamfers
>
> conway cddcqZ6 | antiview -v 0.05
>
> Interestingly, the more duals we add, we lose layers and so eventually
> the core returns to a hexagon and the dissolves completely!
>
> conway dddddddccddcqZ6 | antiview -v 0.05
>
> Note: what I intuitively thought should have worked was cZ6, thus
> chamfering a hexagon. If that worked then the triangular tiling would
> be generated by dual.

As a rule I have to account for dual evaporating one outer layer of tiling.

I found an easier starting seed for the hexagonal tile. The truncation
of kis. Then add layers by chamfer. Now it doesn't have to use quinto.

conway tkZ6 | antiview -v 0.05
conway ctkZ6 | antiview -v 0.05

Triangular follows as the dual

conway dtkZ6 | antiview -v 0.05
conway dctkZ6 | antiview -v 0.05

But kis can be also be used, so there is a "raw" way to do it.

conway ktkZ6 | antiview -v 0.05
conway kctkZ6 | antiview -v 0.05

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 23 Oct 2017, Roger Kaufman wrote:
> On 10/22/2017 1:09 PM, Roger Kaufman wrote:
>> just take the dual of the triangular tiling above.
>>
>> conway ddcqZ6 | antiview -v 0.05
>>
>> After that more layers can be added with chamfers
>>
>> conway cddcqZ6 | antiview -v 0.05

...

> I found an easier starting seed for the hexagonal tile. The truncation of
> kis. Then add layers by chamfer. Now it doesn't have to use quinto.
>
> conway tkZ6 | antiview -v 0.05
> conway ctkZ6 | antiview -v 0.05
>
> Triangular follows as the dual
>
> conway dtkZ6 | antiview -v 0.05
> conway dctkZ6 | antiview -v 0.05
>
> But kis can be also be used, so there is a "raw" way to do it.
>
> conway ktkZ6 | antiview -v 0.05
> conway kctkZ6 | antiview -v 0.05

It is interesting that the tiling can be generated this way.

I had a thought that a hexagonal section of triangle tiling
can be made like this

Geometry hex, ogeom;
hex.read_resource("pol6");
make_geodesic_planar(ogeom, hex, 10);

I also wrote a Python program that generates a hexagonal section
of triangle tiling (and also a square tiling, although that is
straightforward). The function is called make_hexagonal_tiling() (!)
and would be easy enough to convert to C++

https://github.com/antiprism/antiprism_python/blob/master/proj_dome.py

[Roger Kaufman]

Hi Adrian

On 10/23/2017 1:26 PM, Adrian Rossiter wrote:

It is interesting that the tiling can be generated this way.

I had a thought that a hexagonal section of triangle tiling
can be made like this

  Geometry hex, ogeom;
  hex.read_resource("pol6");
  make_geodesic_planar(ogeom, hex, 10);

I also wrote a Python program that generates a hexagonal section
of triangle tiling (and also a square tiling, although that is
straightforward). The function is called make_hexagonal_tiling() (!)
and would be easy enough to convert to C++

   https://github.com/antiprism/antiprism_python/blob/master/proj_dome.py

Here are my notes on the tilings. It can make 10 out of the 11 regular tilings and their duals.

(For one base layer)
Using oZ4 for square
Using tkZ6 for Hexagonal
Using ktkZ6 for triangular (kis or dual)

e.g. Snub Square
conway soZ4 | antiview -v 0.05

Duals

Since the duals are non-regular tilings, set -i 1 to minimize distortion of the tiling. They are still somewhat distorted.

(Two layers because outer perimeter will evaporate during the dual process)
Using o2Z4 for square
Using ctkZ6 for Hexagonal
Using kctkZ6 for triangular (kis or dual)

e.g.
Cairo Pentagonal
conway dso2Z4 -i 1 | antiview -v 0.05

Hopefully the table will stay fixed width below! The basic string to make the tiling is first, while other equivalent forms were found. Other operators X,L,L0,q won't make a tiling in the table, propeller p will make one for square, but not for hex or triangular.

Roger

Name	Vertex Figure	Operation	Strings…			Dual Name		Strings…
Square	4,4,4,4		oZ4	poZ4		Square		do2Z4
Truncated Square	4,8,8	truncate	toZ4			Tetrakis Square		dto2Z4
Snub Square	3,3,4,3,4	snub	soZ4			Cairo Pentagonal		dso2Z4
Triangular	3,3,3,3,3,3	kis	ktkZ6	dtkZ6		Hexagonal		ddctkZ6
Hexagonal	6,6,6		tkZ6	tdtkZ6	ztkZ6	Triangular		dkctkZ6
Trihexagonal	3,6,3,6	ambo	atkZ6	djctkZ6		Rhombille		dactkZ6	jctkZ6
Snub Trihexagonal	3,3,3,3,6	snub	stkZ6	dgctkZ6		Floret Pentagonal		dsctkZ6	gctkZ6
Truncated Hexagonal	3,12,12	truncate	ttkZ6	dnctkZ6		Triakis triangular		dtctkZ6	nctkZ6
Rhombitrihexagonal	3,4,6,4	expand	etkZ6	dotkZ6	dM0tkZ6	Deltoidal Trihexagonal		dectkZ6	octkZ6	M0ctkZ6
Truncated Trihexagonal	4,6,12	bevel	btkZ6	tatkZ6		Kisrhombille		dbctkZ6
Elongated Triangular	3,3,3,4,4		Non Wythoffian			Elongated Triangular		Non Wythoffian

[Roger Kaufman]

Hi Adrian,

On 10/23/2017 2:11 PM, Roger Kaufman wrote:
> Since the duals are non-regular tilings, set -i 1 to minimize
> distortion of the tiling. They are still somewhat distorted.

To get the dual tilings not to be distorted, the dual operation can be
done in a piped command with planarization iterations set to 0.

This gives the Floret Pentagonal tilting

conway sctkZ6 | conway d -i 0 | antiview -v 0.05

or pass to wythoff

conway sctkZ6 | wythoff -c d | antiview -v 0.05

Roger

[Roger Kaufman]

Hi Adrian,

At the bottom of the Conway Notation page there is working on Goldberg
polyhedra. There doesn't seem to be any particular method of progressing
through them and seem to be a bit of experimentation.

It has some operations that are composites of current operations and has
whirl with 2 parameters.

What are your thoughts on this?

Roger

[Roger Kaufman]

Hi Adrian,

Just a short note. I updated conway to accept face number of sides for K
and L.

Examples. The first puts cupolas on the squares. The second puts
antiprisms on the squares.

conway -v K4 u27 -p u | antiview -v 0.01
conway -v L4 u27 -p u | antiview -v 0.01

The kis operation puts pyramids on the squares

conway -v k4 u27 -p u | antiview -v 0.01

The procedure is simple. The geom is reduced to only the faces that
wythoff has to process. Then the previously subtracted faces are
appended back into the geom and merged before planarization could move
any vertices. The process would work for any face number of sides
operations.


It is easy to add that any operation be able to have a N which means
repeat that operation. If an operation doesn't take N for wythoff, it
would just repeat it in the string. I will take a look at this next week.

e.g.

a3C would expand to aaaC.

I haven't decided yet to added Tom Ruen's composite operations. He has
replied to my note, but I won't be able to converse in earnest until
next week.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/25/2017 8:59 AM, Roger Kaufman wrote:
> Examples. The first puts cupolas on the squares. The second puts
> antiprisms on the squares.
>
> conway -v K4 u27 -p u | antiview -v 0.01
> conway -v L4 u27 -p u | antiview -v 0.01

oops I forgot to put loft in for allowing n for faces. It puts prisms on
the faces, analog to L which puts antiprisms. That is pushed.

conway -v l4 u27 -p u | antiview -v 0.01

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 23 Oct 2017, Roger Kaufman wrote:

It is essentially equivalent to determing the faces in a Class III
gedesic sphere, but more work as there are (it appears) three kinds
of pattern. Modelling w(4,1), w(5,1), and w(6,1) on a cube and
looking at the 3-fold axis you can see that a small change
("rotation") in the pattern shifts the axial elements between a
hexagon, a downward Y, and an upright Y.

off_util std_geo_o_4_1_d | off_trans -y C3 | antiview -s a
off_util std_geo_o_5_1_d | off_trans -y C3 | antiview -s a
off_util std_geo_o_6_1_d | off_trans -y C3 | antiview -s a

It is certainly possible to generate the wythoff pattern for
w(n,m) and v(n,m), but is fiddly and would take a lot of
time...

It may be possible to construct the v(n,m) wythoff pattern by
converting a geodesic tiling. I have attached a 5,2 division
of four triangles, and a black and white "meta" triangle from
the central original triangle. It still requires some decisions
about which particular geodesic triangles will be included in the
wythoff pattern, especially as a pattern triangle can have its
vertices on three different meta triangles.

[Adrian Rossiter]

Hi Roger

On Wed, 25 Oct 2017, Roger Kaufman wrote:
> Just a short note. I updated conway to accept face number of sides for K and
> L.

...

> The procedure is simple. The geom is reduced to only the faces that wythoff
> has to process. Then the previously subtracted faces are appended back into
> the geom and merged before planarization could move any vertices. The process
> would work for any face number of sides operations.

Sounds good.

> It is easy to add that any operation be able to have a N which means repeat
> that operation. If an operation doesn't take N for wythoff, it would just
> repeat it in the string. I will take a look at this next week.
>
> e.g.
>
> a3C would expand to aaaC.

Maybe a^3C, as 'a' is essentially a function

https://en.wikipedia.org/wiki/Function_composition#Functional_powers

This then would also work with the operators that take a number
parameter.

[Adrian Rossiter]

Hi Roger

On Fri, 27 Oct 2017, Adrian Rossiter wrote:
>> a3C would expand to aaaC.
>
> Maybe a^3C, as 'a' is essentially a function
>
> https://en.wikipedia.org/wiki/Function_composition#Functional_powers
>
> This then would also work with the operators that take a number
> parameter.

Not suggesting you add it, but you could also have powers of
composite operations e.g. (da)^4C = dadadadaC

[Adrian Rossiter]

Hi Roger

I have just pushed a change for wythoff to reverse the pattern

wythoff -c w cube | antiview
wythoff -R -c w cube | antiview

It changes the start triangles for each tile of the pattern, so any
tile that starts from a + triangle will start from a - triangle,
and vice versa (* is left unchanged by this.)

[Adrian Rossiter]

Hi Roger

On Fri, 27 Oct 2017, Adrian Rossiter wrote:

> I have just pushed a change for wythoff to reverse the pattern
>
> wythoff -c w cube | antiview
> wythoff -R -c w cube | antiview
>
> It changes the start triangles for each tile of the pattern, so any
> tile that starts from a + triangle will start from a - triangle,
> and vice versa (* is left unchanged by this.)

This was interpreted when the tiling was made, but I thought it would
be better if it worked by modifing the pattern itself, and I have
pushed these changes. The two commands above now report different
patterns.

I have had a look at conway and I am not sure if it implements
individual operator reversal. This would be equivalent to reversing
the orientation of the base polyhedron, and restoring after the
operation. In the case of 'r', it appears that the model is
geometrically flipped, also fliping the sign of orientation. It
therefore flips all preceding operators, but also any future
operators, e.g. the following are equivalent

conway -pm wwwr cube
conway -pm wwrw cube
conway -pm wrww cube
conway -pm rwww cube
conway -pm wrwrwr cube
conway -pm rwrwrw cube

I have added pattern reversal to the library call. If you use it
to apply 'w' to a model, the reverse flag will switch between the
two directions for 'w'.


I have also changed the wythoff pattern notation slightly. The
coordinates now give the weighting value before the element, e.g.
V2E3F is now 2V3EF. It seems more natural to have it this way, 2V
is like 2 lots of V, and I was often trying to write them this way.
I had to change the hard-coded conway notation pattern strings, and
have tested the changes, but I may have missed something.

Also, I have allowed a bit more flexibility in the tile pattern,
which can now either start and/or end with a point. So the
following are both accepted, and are equivalent

wythoff -p [V]0F cube | antiview
wythoff -p [V]F0 cube | antiview

The tile patterns alternate between points and moves, and this
change means the pattern can be rotated to start with any point
or any (whole) move. If a tile pattern starts and ends with a
point there is an implied no-op move '_' beween them. The following
are equivalent

wythoff -p [V,E,F]1_0e1_2e cube | antiview
wythoff -p [V,E,F]0e1_2e1 cube | antiview

[Roger Kaufman]

Hi Adrian,

On 10/30/2017 8:19 AM, Adrian Rossiter wrote:
> I have had a look at conway and I am not sure if it implements
> individual operator reversal. This would be equivalent to reversing
> the orientation of the base polyhedron, and restoring after the
> operation. In the case of 'r', it appears that the model is
> geometrically flipped, also fliping the sign of orientation. It
> therefore flips all preceding operators, but also any future
> operators, e.g. the following are equivalent
>
>    conway -pm wwwr cube
>    conway -pm wwrw cube
>    conway -pm wrww cube
>    conway -pm rwww cube
>    conway -pm wrwrwr cube
>    conway -pm rwrwrw cube
>
> I have added pattern reversal to the library call. If you use it
> to apply 'w' to a model, the reverse flag will switch between the
> two directions for 'w'.

I'm not sure what these are supposed to look like!

The reflection is done by inversion and will invert the model at the
current stage of processing.

geom.transform(Trans3d::inversion())

Shouldn't it be that the current model would be reversed but the next
whirl would still be the same direction as before, applied to the model
that has just been reversed?

Wouldn't this also be true for snub?

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 30 Oct 2017, Roger Kaufman wrote:
> On 10/30/2017 8:19 AM, Adrian Rossiter wrote:
>> I have had a look at conway and I am not sure if it implements
>> individual operator reversal. This would be equivalent to reversing
>> the orientation of the base polyhedron, and restoring after the
>> operation. In the case of 'r', it appears that the model is
>> geometrically flipped, also fliping the sign of orientation. It
>> therefore flips all preceding operators, but also any future
>> operators, e.g. the following are equivalent
>>
>>    conway -pm wwwr cube
>>    conway -pm wwrw cube
>>    conway -pm wrww cube
>>    conway -pm rwww cube
>>    conway -pm wrwrwr cube
>>    conway -pm rwrwrw cube
>>
>> I have added pattern reversal to the library call. If you use it
>> to apply 'w' to a model, the reverse flag will switch between the
>> two directions for 'w'.
>
> I'm not sure what these are supposed to look like!

Here is an example on a snub cube, the 'w' pattern turns in a different
direction on the same snub cube

wythoff -c w snub_cube | antiview
wythoff -c w -R snub_cube | antiview

> The reflection is done by inversion and will invert the model at the current
> stage of processing.
>
> geom.transform(Trans3d::inversion())
>
> Shouldn't it be that the current model would be reversed but the next whirl
> would still be the same direction as before, applied to the model that has
> just been reversed?

The transformation reverses the direction of orientation of the faces
(w.r.t. the centre, e.g. the sign of the volume changes)

off_trans sn_cube | off_report -k
...volume = 7.8894773999753882

off_trans sn_cube -I | off_report -k
...volume = -7.8894773999753882

This means that when you construct 'w' after 'r' (assuming the
model was positively oriented when 'r' was performed) it will
be in the opposite direction. The snub (which may have been
produced by a previous 's' operation) is also reversed. You can
see this effect in the following commands, which compare the inverted
snub cube as input with the orientation set to positive and negative

off_trans sn_cube -I | off_util -O p | conway w -p m | antiview
off_trans sn_cube -I | off_util -O n | conway w -p m | antiview

> Wouldn't this also be true for snub?

Yes, for any pattern without mirror symmetry.

[Roger Kaufman]

Hi Adrian,

On 10/30/2017 10:48 AM, Adrian Rossiter wrote:
> Here is an example on a snub cube, the 'w' pattern turns in a different
> direction on the same snub cube
>
>    wythoff -c w snub_cube | antiview
>    wythoff -c w -R snub_cube | antiview

If there is more than one reflect in line, would this be like toggling
the reverse flag? Here is a command such that if I leave out the second
reflect I get the same result.

It actually a question as to when to set the reverse flag I think.

wythoff -c w cube | off_trans -I | wythoff -c w | off_trans -I | wythoff
-c w | canonical -p p | antiview -v 0.01

wythoff -c w cube | off_trans -I | wythoff -c w | wythoff -c w |
canonical -p p | antiview -v 0.01

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 30 Oct 2017, Roger Kaufman wrote:

The wythoff program gives the input polyhedron a positive orientation if
it doesn't already have one, but the output polyhedon for 'w' is not
oriented. This means that the off_trans -I here doesn't behave exactly
like current 'r'.

The results of the two commands appear to be different, if you look at
them together

wythoff -c w cube | off_trans -I | wythoff -c w | wythoff -c w > tmp.off
wythoff -c w cube | off_trans -I | wythoff -c w | off_trans -I | wythoff -c w | antiview -v 0.01 - tmp.off


I would think the natural behaviour for 'r' would be to reverse the
orientation after the inversion, then it will just reverse everything
done before it is applied.

Perhaps a separate operation modifier could apply to patterns like
'w' to reverse them. However, if 'r' maintains the orientation then
'rwr' should produce reversed w only, suggesting that an individual
operator reverse isn't especially needed.

[Adrian Rossiter]

Hi Roger

On Mon, 30 Oct 2017, Adrian Rossiter wrote:
> The wythoff program gives the input polyhedron a positive orientation if
> it doesn't already have one, but the output polyhedon for 'w' is not
> oriented. This means that the off_trans -I here doesn't behave exactly

That doesn't read very well.

The wythoff program gives the input polyhedron a positive orientation if

it is not already oriented (positive or negative).

[Roger Kaufman]

Hi Adrian,

On 10/30/2017 12:09 PM, Adrian Rossiter wrote:
> I would think the natural behaviour for 'r' would be to reverse the
> orientation after the inversion, then it will just reverse everything
> done before it is applied.

I also orient to positive orientation when starting, with a warning if
orientation isn't possible. Between steps, if the output is not
orientable a warning is issued.

I added keeping a count of reflection starting from 0. If the count is
even then the result is oriented positive, odd then reversed. The
reflect operation increments the count.

The true flag of the wythoff call is not changed.

I decided to comment out the chamfer and whirl functions from the Hart
era coding to give a consistent result. The whirl function did a Hart
gyro which is always the same direction. These are something we added in
Antiprism and not part of the original Hart generator.


Something I was thinking of doing was to add a feature where it colors
newly created faces by operation. This would have helped give the whirl
operation a way to see what was happening. But it looks like the output
of the wythoff function alters the color of the input faces. Would it be
hard to preserve the color of input faces but keep the new ones unset?

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 30 Oct 2017, Roger Kaufman wrote:

> Something I was thinking of doing was to add a feature where it colors newly
> created faces by operation. This would have helped give the whirl operation a
> way to see what was happening. But it looks like the output of the wythoff
> function alters the color of the input faces. Would it be hard to preserve
> the color of input faces but keep the new ones unset?

wythoff tiles the meta tiling for the polyhedron, and isn't considering
the original faces when it creates the tiles, and so extra tracking
would be needed.

Some tiles, like 0F, and 0v0e are obviously associate with a face.
However, surprisingly, sometimes the element that a tile is
associated with depends on the polyhedron

wythoff -p [E]0VFE geo_1_1 | off_report
wythoff -p [E]0VFE geo_2_1 | off_report
wythoff -p [E]0VFE geo_3_1 | off_report
wythoff -p [E]0VFE geo_4_1 | off_report

These have the following numbers of faces: 20, 30, 20, 12. So the tile
is associated with a vertex, a face, a vertex, an edge, depending on
the base polyhedron.

For conway operators you can probably post process the wythoff result
and colour faces by face colour if their centroid coincides with an
original face centroid.

[Adrian Rossiter]

Hi Roger

On Mon, 30 Oct 2017, Adrian Rossiter wrote:
> These have the following numbers of faces: 20, 30, 20, 12. So the tile
> is associated with a vertex, a face, a vertex, an edge, depending on
> the base polyhedron.

Whoops, that should have said a vertex, an edge, a vertex and a face.
Also of interest here is that in each case there are fewer tiles
than elements of the original polyhedron.

[Roger Kaufman]

Hi Adrian,

On 10/30/2017 1:20 PM, Adrian Rossiter wrote:
> For conway operators you can probably post process the wythoff result
> and colour faces by face colour if their centroid coincides with an
> original face centroid.

o.k. I will try this tomorrow. I believe there are times when the
original faces no longer exists. This shouldn't be a problem.

Is there any benefit of retaining the colors (converted from a map) from
the wythoff operation? If so this could be made an option.

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 30 Oct 2017, Roger Kaufman wrote:

> Is there any benefit of retaining the colors (converted from a map) from the
> wythoff operation? If so this could be made an option.

The colorings wouldn't be cumulative in a Conway notation string,
so the result would just relate to the final operation and the
polyhedron it was passed to process. If you retain them (you could
use any colour map) they are probably most intersting for previewing
the action of single operators.

Adrian.
--
Adrian Rossiter
adr...@antiprism.com

http://antiprism.com/adrian/

[Roger Kaufman]

Hi Adrian,

On 10/30/2017 2:54 PM, Adrian Rossiter wrote:
> The colorings wouldn't be cumulative in a Conway notation string,
> so the result would just relate to the final operation and the
> polyhedron it was passed to process. If you retain them (you could
> use any colour map) they are probably most intersting for previewing
> the action of single operators.

The wythoff program colors edges, but in the wythoff function call in
conway there are no edges in they geom after the call. Have they been
deleted? The conway program won't care if there are edges. The old
George Hart code didn't use them, but I don't allow the new color
methods with -g.

I was hunting around for code to color by value based on the map index
and a color map. I even thought I did this at one time but I can't find
it if I did. I ended up with this much code, but I wonder if you have
something, maybe a function call?

    const vector<vector<int>> &faces = geom.faces();
    for (unsigned int i = 0; i < faces.size(); i++) {
      Color col = geom.colors(FACES).get((int)i);
      if (col.is_index())
        geom.colors(FACES).set(i, opts.map.get_col(col.get_index()));
    }

    const vector<vector<int>> &edges = geom.edges();
    for (unsigned int i = 0; i < edges.size(); i++) {
      Color col = geom.colors(EDGES).get((int)i);
      if (col.is_index())
        geom.colors(EDGES).set(i, opts.map.get_col(col.get_index()));
    }

    const vector<Vec3d> &verts = geom.verts();
    for (unsigned int i = 0; i < verts.size(); i++) {
      Color col = geom.colors(VERTS).get((int)i);
      if (col.is_index())
        geom.colors(VERTS).set(i, opts.map.get_col(col.get_index()));
    }

Roger

[Adrian Rossiter]

Hi Roger

On Mon, 30 Oct 2017, Roger Kaufman wrote:

> On 10/30/2017 2:54 PM, Adrian Rossiter wrote:
>> The colorings wouldn't be cumulative in a Conway notation string,
>> so the result would just relate to the final operation and the
>> polyhedron it was passed to process. If you retain them (you could
>> use any colour map) they are probably most intersting for previewing
>> the action of single operators.
>
> The wythoff program colors edges, but in the wythoff function call in conway
> there are no edges in they geom after the call. Have they been deleted? The

They are digons, and are in the face list. For conway, any tile like
E0 will produce a digon, but for wythoff the base tiling isn't necessarily
generated from a polyhedron, and so this won't always be the case

Here, wythoff takes a meta tiling of a cube and applies 'seed', to
produce a polyhedron with red digons around the E elements

conway m cube | wythoff -M -c S | antiview

Here, the base tiling does not correspond to meta for a polyhedron, and
'seed' produces a polyhedron with red triangles around the E elements

unitile2d -w 6 -l 24 -s t 2 | wythoff -M -c S | antiview

> I was hunting around for code to color by value based on the map index and a
> color map. I even thought I did this at one time but I can't find it if I
> did. I ended up with this much code, but I wonder if you have something,
> maybe a function call?

You can use Coloring::v_apply_cmap(), e_apply_cmap(), f_apply_cmap().

[Roger Kaufman]

Hi Adrian,

On 10/31/2017 5:31 AM, Adrian Rossiter wrote:
> They are digons, and are in the face list. For conway, any tile like
> E0 will produce a digon, but for wythoff the base tiling isn't
> necessarily
> generated from a polyhedron, and so this won't always be the case
>

Normally I have been deleting digons. But for the new -f w coloring I
convert the digons into edges. It simply colors the same way as the
final wythoff output for convenience.

>> I was hunting around for code to color by value based on the map
>> index and a color map. I even thought I did this at one time but I
>> can't find it if I did. I ended up with this much code, but I wonder
>> if you have something, maybe a function call?
>
> You can use Coloring::v_apply_cmap(), e_apply_cmap(), f_apply_cmap().
>

Thanks. I've actually used this recently but am having short memory!

I pushed a new version of conway adding the -f w and -f o coloring
options. The -f o coloring tries to retain the face colors of previous
operations while coloring new faces by the map color for their operation
count staring from 1. The built in seeds are now colored with map color 0.

I've attached a zip file showing models compared and were colored with
-f o. The ones labeled alternate is how reflect incorporates the
negative orientation toggle, while the ones labeled positive was the way
it used to be with all positive orientation.

I've made it so that the model is sized to the radius of average
midedges (like its been canonicalized), so I had to move some code from
canonical.cc to base/canonic.cc. It makes the reciprocal of the output
be close to having crossing edges with the base.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/27/2017 10:33 AM, Adrian Rossiter wrote:
> Not suggesting you add it, but you could also have powers of
> composite operations e.g. (da)^4C = dadadadaC

The parser processes one character at a time, so I don't really want
added parents to the strings.

I like the idea ^n operator which would make it easy to push the
previous operation into the stack n times.

Tom had some composite operators and I thought of a way to get them and
still have the sort of power as string above. Since letters are scares,
it wouldn't tie them up permanently in the code.

On the command line it could add composite operators as options. e.g.

conway -c x,kt -c y,tk -c v,dwd x^2y^3v ico ...

This will be easy to implement. I'm not going to add nesting to the -c
command strings unless there would be a good reason to use it.

Roger

[Roger Kaufman]

Hi Adrian,

On 10/31/2017 10:10 AM, Roger Kaufman wrote:
> I like the idea ^n operator which would make it easy to push the
> previous operation into the stack n times.
>

> conway -c x,kt -c y,tk -c v,dwd x^2y^3v ico ...

I've added ^n repeating and user defined operation strings to the
program. Now a command like this from the wiki page works.

conway -c y,tk wyD | antiview -v 0.01

> wrwrwC_positive.off from an earlier attachment. It did reflections,
> but always had positive orientation.

Now that it is doing the orientation toggle with reflection, I don't
believe I can make this model! And now I am finding that wwwC and wrwrwC
are equivalent even though the second reflection results in negative
orientation. (Leavning one reflection out results in different models).
Does this imply that reflection+orientation pairs are unique operations?
e.g reflect=true or face orientation=positive or negative, gives 4
possible combinations?


On the wiki page, Tom colored the Goldberg polyhedra using a radial
technique. If I could identify which faces touch the symmetry axes (the
axes could go through vertices, edges or faces), I could program radial
symmetry coloring in this manor. This would help discern the Goldberg
patterns nicely.

Roger

[Roger Kaufman]

Hi Adrian,

On 11/2/2017 12:54 AM, Roger Kaufman wrote:

wrwrwC_positive.off from an earlier attachment. It did reflections, but always had positive orientation.

Now that it is doing the orientation toggle with reflection, I don't believe I can make this model! And now I am finding that wwwC and wrwrwC are equivalent even though the second reflection results in negative orientation. (Leavning one reflection out results in different models). Does this imply that reflection+orientation pairs are unique operations? e.g reflect=true or face orientation=positive or negative, gives 4 possible combinations?

I had an afterthought. I added an operator R which reflects and toggles the orientation. While small r does not toggle and keeps orientation as positive. Now it is possible to produce the old model.

conway wrwrwC -f o -v | antiview -v 0.01 - wrwrwC_positive.off

Using capital R can product the alternate version

conway wRwRwC -f o -v | antiview -v 0.01 - wrwrwC_alternate.off

If I reverse the 1 and 2 in this line of code, this last command gives a different result. So there is still more to solve. Perhaps an option to start the orientation toggle as odd might work.

  // orientation is reversed if reflected 1=positive 2=negative
  geom.orient((is_even(reflect_toggle)) ? 1 : 2);

The small r operation would be in keeping with George Harts snub operation

conway srsrsC -g -v | antiview -v 0.01 - srsrsC_positive.off
conway sRsRsC -g -v | antiview -v 0.01 - srsrsC_alternate.off

I shall sleep on this!

Roger

[Adrian Rossiter]

Hi Roger

On Thu, 2 Nov 2017, Roger Kaufman wrote:
>>> wrwrwC_positive.off from an earlier attachment. It did reflections, but
>>> always had positive orientation.
>>
>> Now that it is doing the orientation toggle with reflection, I don't
>> believe I can make this model! And now I am finding that wwwC and wrwrwC
>> are equivalent even though the second reflection results in negative
>> orientation. (Leavning one reflection out results in different models).
>> Does this imply that reflection+orientation pairs are unique operations?
>> e.g reflect=true or face orientation=positive or negative, gives 4 possible
>> combinations?
>
> I had an afterthought. I added an operator R which reflects and toggles the
> orientation. While small r does not toggle and keeps orientation as positive.
> Now it is possible to produce the old model.

If you give a positive orientation before any model is processed
by any operator then the action of the operators is a lot clearer.

It means that, if you have a snub polyhedron X and want to apply 'w'

wX : +X,+w
wrX : -X,+w
rwX : -X,-w
rwrX : +X,-w

Wythoff gives different results on based the orientation of the
input, but it doesn't orient the output. If it did, it would orient
the output same way as the input, so that repeated 'w's would produce
the same direction pattern. You probably aren't doing that in conway,
so 'w' can act differently depending on previous operations. You
can avoid this by always ensuring a positive orientation before
applying an operator.

[Adrian Rossiter]

Hi Roger

On Thu, 2 Nov 2017, Roger Kaufman wrote:

> On the wiki page, Tom colored the Goldberg polyhedra using a radial
> technique. If I could identify which faces touch the symmetry axes (the axes
> could go through vertices, edges or faces), I could program radial symmetry
> coloring in this manor. This would help discern the Goldberg patterns nicely.

If you don't geometrically change the results of the operations then
the original symmetry axes are left unchanged. Every occurence of 'r'
will invert them.

If you create an icosahedron by snubbing a tetrahedron then you will
get different results than if you start with an icosahedron, but that
is good!

I had a look if it was possible to produce a suitable colouring with
lights, but there are too many and the colour differences can barely
be seen

off_color schwarz_5_2_3 -v U -m map_0.1/0/0:0/0.1/0:0/0/0.1 | poly_kscope -s I | off_util -M a > lights_I.off
conway ccccd ico | off_color -f L -l lights_I.off | antiview

You could acheive a reasonable coloring that corresponded to the
base meta tiling by localising the lighting to a single Schwarz
triangle. The vector for the element to be coloured passes
through a particular Schwarz triangle, and the colour is a
weighted blend of the lights at the three vertices of that
triangle. A more useful solution would work with the original
meta triangles, and the final tiling being projected onto this
in some way so that the face centres become the points in
the meta triangles that determine the colour blend for each
face,

[Adrian Rossiter]

Hi Roger

On Thu, 2 Nov 2017, Roger Kaufman wrote:

> On 10/31/2017 10:10 AM, Roger Kaufman wrote:
>> I like the idea ^n operator which would make it easy to push the previous
>> operation into the stack n times.
>>
>> conway -c x,kt -c y,tk -c v,dwd x^2y^3v ico ...
>
> I've added ^n repeating and user defined operation strings to the program.
> Now a command like this from the wiki page works.
>
> conway -c y,tk wyD | antiview -v 0.01

Just to mention that a custom letter could also be assigned to a
Wythoff constructive notation pattern. However, I don't really
see anyone using the notation at the moment, and a pattern can
still be inserted into a Conway notation string via wythoff.

[Roger Kaufman]

Hi Adrian,

On 11/2/2017 5:16 AM, Adrian Rossiter wrote:
> Just to mention that a custom letter could also be assigned to a
> Wythoff constructive notation pattern. However, I don't really
> see anyone using the notation at the moment, and a pattern can
> still be inserted into a Conway notation string via wythoff.

I've always thought that things that conway can't do can be done by
piping output to other programs and then resuming conway with that
input. That would be possible here.

Roger

[Roger Kaufman]

Hi Adrian,

On 11/2/2017 3:49 AM, Adrian Rossiter wrote:
> It means that, if you have a snub polyhedron X and want to apply 'w'
>
>       wX : +X,+w
>      wrX : -X,+w
>      rwX : -X,-w
>     rwrX : +X,-w

I thought about this last night and decided that toggling the
orientation on reflection doesn't give it enough control. You could want
to change the orientation without doing a reflection.

I was going to create an orientation operator using a pair or letters,
but + and - will work. I got that idea but looking at your table! I
added this to the help:

Orientation of the input model will have an effect on chiral operations
such as
snub or whirl. The orientation is set to positive by default. Two operations
have been added to control orientation:
+ (plus sign) = positive orientation  - (minus sign) = negative orientation
Changing orientation can be placed anywhere in the operation string

I added plus and minus operators to flip the orientation mode. Once a +
or - sign occurred it wouldn't be necessary to reapply it again until a
change is wanted, but I did so in these examples.

conway wr+wr+wr+C -f o -v | off_trans -y full > wr+wr+wr+C.off
conway wr+wr+wr-C -f o -v | off_trans -y full > wr+wr+wr-C.off
conway wr+wr-wr+C -f o -v | off_trans -y full > wr+wr-wr+C.off
conway wr+wr-wr-C -f o -v | off_trans -y full > wr+wr-wr-C.off
conway wr-wr+wr+C -f o -v | off_trans -y full > wr-wr+wr+C.off
conway wr-wr+wr-C -f o -v | off_trans -y full > wr-wr+wr-C.off
conway wr-wr-wr+C -f o -v | off_trans -y full > wr-wr-wr+C.off
conway wr-wr-wr-C -f o -v | off_trans -y full > wr-wr-wr-C.off

I've attached to output of these. As far as I can see, no two of these
are congruent. If any of the reflections were left out, the number of
combinations increases quite a bit!

> I had a look if it was possible to produce a suitable colouring with
> lights, but there are too many and the colour differences can barely
> be seen

You know where the symmetry axes are in antiview. If these are known,
element intersections can be ascertained. Its a bit brute force-ish but
it could be done.

Roger

[Adrian Rossiter]

Hi Roger

On Thu, 2 Nov 2017, Roger Kaufman wrote:

> On 11/2/2017 3:49 AM, Adrian Rossiter wrote:
>> It means that, if you have a snub polyhedron X and want to apply 'w'
>>
>>       wX : +X,+w
>>      wrX : -X,+w
>>      rwX : -X,-w
>>     rwrX : +X,-w
>
> I thought about this last night and decided that toggling the orientation on
> reflection doesn't give it enough control. You could want to change the
> orientation without doing a reflection.
>
> I was going to create an orientation operator using a pair or letters, but +
> and - will work. I got that idea but looking at your table! I added this to
> the help:

...

> conway wr+wr+wr+C -f o -v | off_trans -y full > wr+wr+wr+C.off
> conway wr+wr+wr-C -f o -v | off_trans -y full > wr+wr+wr-C.off
> conway wr+wr-wr+C -f o -v | off_trans -y full > wr+wr-wr+C.off
> conway wr+wr-wr-C -f o -v | off_trans -y full > wr+wr-wr-C.off
> conway wr-wr+wr+C -f o -v | off_trans -y full > wr-wr+wr+C.off
> conway wr-wr+wr-C -f o -v | off_trans -y full > wr-wr+wr-C.off
> conway wr-wr-wr+C -f o -v | off_trans -y full > wr-wr-wr+C.off
> conway wr-wr-wr-C -f o -v | off_trans -y full > wr-wr-wr-C.off
>
> I've attached to output of these. As far as I can see, no two of these are
> congruent. If any of the reflections were left out, the number of
> combinations increases quite a bit!

If you ensure positive orientaion before applying operators you
can generate the 8 triple whirl operations by permuting w and
rwr (flipped w)

000 = www
001 = wwrwr
010 = wrwrw
011 = wrwrrwr = wrwwr
100 = rwrww
101 = rwrwrwr
110 = rwrrwrw = rwwrw
111 = rwrrwrrwr = rwwwr

The same way that rwr flips w, r(x)r flips any operation x, so
you can see the triple whirl possibilities come in four flipped
pairs

000 = www, flips to r(www)r = rwwwr = 111
001 = wwrwr, flips to r(wwrwr)r = rwwrw = 110
010 = wrwrw, flips to r(wrwrw)r = rwrwrwr = 101
011 = wrwwr, flips to r(wrwwr)r = rwrww = 100

To me, this is a lot simpler than having the extra operators +,-,R,
as it behaves in the expected way and can generate the same models
in a more natural way.

[Roger Kaufman]

Hi Adrian,

On 11/2/2017 9:04 AM, Adrian Rossiter wrote:
> If you ensure positive orientaion before applying operators you
> can generate the 8 triple whirl operations by permuting w and
> rwr (flipped w)

The input geom is oriented with geom.orient(). If that is positive
orientation then it starts out that way.

> 000 = www
> 001 = wwrwr
> 010 = wrwrw
> 011 = wrwrrwr = wrwwr
> 100 = rwrww
> 101 = rwrwrwr
> 110 = rwrrwrw = rwwrw
> 111 = rwrrwrrwr = rwwwr
>
> The same way that rwr flips w, r(x)r flips any operation x, so
> you can see the triple whirl possibilities come in four flipped
> pairs
>
> 000 = www, flips to r(www)r = rwwwr = 111
> 001 = wwrwr, flips to r(wwrwr)r = rwwrw = 110
> 010 = wrwrw, flips to r(wrwrw)r = rwrwrwr = 101
> 011 = wrwwr, flips to r(wrwwr)r = rwrww = 100

That is a nice way to look at it! The double rr's cancel out. This
should be the case with snub and gyro as well.

I tried the last one 011 and was trying to show the wrwwr is the mirror
image of rwrww. How would this be flipped? off_trans -i didn't do what I
thought it would. I want to verify I don't have a problem in the program.

> To me, this is a lot simpler than having the extra operators +,-,R,
> as it behaves in the expected way and can generate the same models
> in a more natural way.
>

Since positive orientation is the default, all the commands above have
positive orientation before any operation. Therefore what you are
showing is the way it works now.

The 'R' operator was taken out when I put in plus and minus. So the
command below can generate the opposite hand snub cube through orientation.

conway sC -f o -v | antiview
conway s-C -f o -v | antiview

I think I will continue to have plus and minus as operators although now
we may opt not to use them! I have added the orientation mode to verbose
output at the beginning of the program.

conway s-s-C -f o -v | antiview or conway ss-C -f o -v | antiview
conway s+s-C -f o -v | antiview or conway srsC -f o -v | antiview

Roger

[Roger Kaufman]

Hi Adrian,

On 11/2/2017 10:00 AM, Roger Kaufman wrote:
> I tried the last one 011 and was trying to show the wrwwr is the
> mirror image of rwrww. How would this be flipped? off_trans -i didn't
> do what I thought it would. I want to verify I don't have a problem in
> the program.

Oops! I should have tried off_trans -I (not lower case i). It inverts
properly.

Roger

[Adrian Rossiter]

Hi Roger

On Thu, 2 Nov 2017, Roger Kaufman wrote:

> On 11/2/2017 9:04 AM, Adrian Rossiter wrote:
>> If you ensure positive orientaion before applying operators you
>> can generate the 8 triple whirl operations by permuting w and
>> rwr (flipped w)
>
> The input geom is oriented with geom.orient(). If that is positive
> orientation then it starts out that way.

I think geom.orient() orients consistently with the first
face, and geom.orient(1) gives positive orientation.

> Since positive orientation is the default, all the commands above have
> positive orientation before any operation. Therefore what you are showing is
> the way it works now.

In case it isn't clear (it may be), the current geometry needs to be
positively oriented every time before an individual Conway operator
is applied, not just the seed.

I also had a thought that as you are handling plane tilings it might
might be better to implement 'r' with a mirror normal to (1,0,0), as
the inverse in the plane is a rotation. E.g. the following doesn't
change the sense of the pattern to the viewer

unitile2d 7 -w 10 -l 5 | conway S -p m | antiview -v 0.05
unitile2d 7 -w 10 -l 5 | conway r -p m | antiview -v 0.05

But this does

unitile2d 7 -w 10 -l 5 | off_trans -M 1,0,0 | conway S -p m | antiview -v 0.05

[Roger Kaufman]

Hi Adrian,

On 11/2/2017 11:22 AM, Adrian Rossiter wrote:
> I think geom.orient() orients consistently with the first
> face, and geom.orient(1) gives positive orientation.

I don't know why I didn't just make it 1 in the first place! I have it
elsewhere like that. I've added it.

> In case it isn't clear (it may be), the current geometry needs to be
> positively oriented every time before an individual Conway operator
> is applied, not just the seed.

It orients after every step. In verbose I have "orient positive mode" at
the beginning of the program. I was going to output orient at every step
but I thought knowing the mode was enough. It does output if, after a
step, the result isn't orientable.

I changed the extended help to add the word mode:

Orientation of the input model will have an effect on chiral operations
such as

snub or whirl. The orientation mode is set to positive by default.
Operations
have been added to control orientation mode. The mode will remain until
changed.

+ (plus sign) = positive orientation  - (minus sign) = negative orientation

Changing orientation mode can be placed anywhere in the operation string

I found these to be equivalent.

conway rwrwwC -f o -v > tmp.off
conway wrwwrC -f o -v | off_trans -I | antiview -v 0.01 - tmp.off
conway wrwwr-C -f o -v | antiview -v 0.01 - tmp.off (this one is set to
negative orientation mode as step 1)
conway rwrwwrC -f o -v | antiview -v 0.01 - tmp.off

This model is O symmetry and has a very hard to visualize repeat
pattern. You may see why I'd like to do the radial coloring, but I will
try that on the side and not hold up any development.

conway wrwwrC -f s -v -m rng64 | antiview -v 0.01 -s a

> I also had a thought that as you are handling plane tilings it might
> might be better to implement 'r' with a mirror normal to (1,0,0), as
> the inverse in the plane is a rotation. E.g. the following doesn't
> change the sense of the pattern to the viewer
>
>    unitile2d 7 -w 10 -l 5 | conway S -p m | antiview -v 0.05
>    unitile2d 7 -w 10 -l 5 | conway r -p m | antiview -v 0.05
>
> But this does
>
>    unitile2d 7 -w 10 -l 5 | off_trans -M 1,0,0 | conway S -p m |
> antiview -v 0.05

I added this but -t (tile mode) has to be set to use it. I don't know if
there is a way to detect a tiling as it doesn't necessarily have to be
on one nice plane. Even if it did detect it, I wouldn't want to force
-t, but it could warn.
I changed it to put out a warning if it is is tile mode. When operand Z
- polygon is used it does force tile mode. -t now allows changing the
planarize method, but it defaults to -p u if not set.

unitile2d 7 -w 10 -l 5 | conway r -v -t | antiview -v 0.05

I am pushing these changes as I send email so if you want to try commands.

Roger

[Adrian Rossiter]

Hi Roger

On Thu, 2 Nov 2017, Roger Kaufman wrote:

> I found these to be equivalent.
>
> conway rwrwwC -f o -v > tmp.off
> conway wrwwrC -f o -v | off_trans -I | antiview -v 0.01 - tmp.off
> conway wrwwr-C -f o -v | antiview -v 0.01 - tmp.off (this one is set to
> negative orientation mode as step 1)
> conway rwrwwrC -f o -v | antiview -v 0.01 - tmp.off

Looks good!

[Roger Kaufman]

Hi Adrian,

On 11/2/2017 1:23 PM, Adrian Rossiter wrote:
> Hi Roger
>
> On Thu, 2 Nov 2017, Roger Kaufman wrote:
>> I found these to be equivalent.
>>
>> conway rwrwwC -f o -v > tmp.off
>> conway wrwwrC -f o -v | off_trans -I | antiview -v 0.01 - tmp.off
>> conway wrwwr-C -f o -v | antiview -v 0.01 - tmp.off (this one is set
>> to negative orientation mode as step 1)
>> conway rwrwwrC -f o -v | antiview -v 0.01 - tmp.off
>
> Looks good!
>
> Adrian.

I've noticed that if the seed is non-chiral, as is all of the built in
seeds, whenever the first operator is reflection, as expected, it has no
effect. This isn't a problem, its just an observation.

For instance.

conway srssrC -f o -v > srssrC.off

conway srssC -f o -v | antiview - srssrC.off

Roger

[Roger Kaufman]

Hi Adrian,

I will be able to go deeper into the code later today. It breaks out on
a gyro with one edge have 4 connections.

conway gC | antiview  I wrote out the geom in question and off_report
says it is ok. The input to wythoff is oriented.

Do you see anything wrong? Should I be comparing to first and not second?

    // check for 3 faces at an edge
    auto efpairs = geom.get_edge_face_pairs(false);
    map<vector<int>, vector<int>>::const_iterator ei;
    for (ei = efpairs.begin(); ei != efpairs.end(); ++ei) {
fprintf(stderr,"ei->first = %d ei->second = %d\n",
(int)ei->first.size(), (int)ei->second.size());
      if (ei->second.size() > 2) {
        opts.warning("3 or more faces to an edge");
        break;
      }
    }

...
ei->first = 2 ei->second = 2
ei->first = 2 ei->second = 2
ei->first = 2 ei->second = 2
ei->first = 2 ei->second = 4
conway: warning: 3 or more faces to an edge


When I just do it with the wythoff, off_report says its ok.

wythoff -c g cube | off_report

Roger

[Adrian Rossiter]

Hi Roger

On Sun, 19 Nov 2017, Roger Kaufman wrote:
> I will be able to go deeper into the code later today. It breaks out on a
> gyro with one edge have 4 connections.
>
> conway gC | antiview  I wrote out the geom in question and off_report says it
> is ok.

Are you stripping digons? These would bump up the edge face-connection
count, but would disappear when written out to OFF and then read back
in again.

[Roger Kaufman]

Hi Adrian,

On 11/19/2017 9:42 AM, Adrian Rossiter wrote:
> Are you stripping digons? These would bump up the edge face-connection
> count, but would disappear when written out to OFF and then read back
> in again.

Oh yes, that seems to be it. I will strip the digons first right after
the wythoff call.

Roger

[Roger Kaufman]

Hi Adrian,

> P.S I'm going to take artistic license and add the random polyhedra
> seed to conway. I already added Z (polygons) which isn't in the format
> but it has good use. Ironically Conway was describing symmetry but C1
> is a symmetry so its not that bad!

I have added and pushed the R seed.

I have also added the following to the beginning of the extended help.

Conway Notation was described by Mathematician John Conway to George Hart in
the late 1990's for a book they planned to coauthor. Due to an illness
the book
never came to fruition and John Conway did not think there was enough a
for a
separate publication. Conway gave George Hart permission to present it in
"Sculpture Based on Propellorized Polyhedra in the Proceedings of MOSAIC
2000"
The paper can be viewed here:
http://www.georgehart.com/propello/propello.html
The project was expected to encourage more operations to be developed
which has
happened in various places including here at Antiprism. (www.antiprism.com)

Roger

[Roger Kaufman]

Hi Adrian,

If you still have the files I found that not 2 but 3 of the produced
whirl patterns are the same. Interesting those similarities but not with
other chiral operators.

They overlay like this

off_trans -I w_xrxxrC.off | off_util - w_xxrxrC.off | antiview -
w_xrxrxC.off

Then w_xxxC.off is the different one.

Roger

[Adrian Rossiter]

Hi Roger

If I have understood, this only works because the seed is a
cube, and invertible, and wouldn't be the case if the seed was
a snub cube.

[Roger Kaufman]

Hi Adrian,

On 11/22/2017 9:53 AM, Adrian Rossiter wrote:

Hi Roger

On Wed, 22 Nov 2017, Roger Kaufman wrote:

If you still have the files I found that not 2 but 3 of the produced whirl patterns are the same. Interesting those similarities but not with other chiral operators.

They overlay like this

off_trans -I w_xrxxrC.off | off_util - w_xxrxrC.off | antiview - w_xrxrxC.off

Then w_xxxC.off is the different one.

If I have understood, this only works because the seed is a
cube, and invertible, and wouldn't be the case if the seed was
a snub cube.

On Sat, 4 Nov 2017, Roger Kaufman wrote:

The snub models are all different. But for whirl, wwrwr and wrwrw are the same.

If they are the same, then wrwr = rwrw, and following

   https://en.wikipedia.org/wiki/Conway_polyhedron_notation#Chiral_hexagonal_subdivision

wrwrC = wrwC = G(7,0)C
rwrwC = r(wrw)C = rG(7,0)C = G(7,0)C

For the Tetrahedron and Dodecahedron, only two were the same. There was no mirror image model. I didn't include the models, but these were congruent. We already determined the reasoning for these, I cut and pasted a note above.

off_util w_xxrxrT.off | antiview - w_xrxrxT.off
off_util w_xxrxrD.off | antiview - w_xrxrxD.off

Roger

[Adrian Rossiter]

Hi Roger

On Wed, 22 Nov 2017, Roger Kaufman wrote:
> On 11/22/2017 9:53 AM, Adrian Rossiter wrote:
>> On Wed, 22 Nov 2017, Roger Kaufman wrote:
>>> If you still have the files I found that not 2 but 3 of the produced whirl
>>> patterns are the same. Interesting those similarities but not with other
>>> chiral operators.
>>>
>>> They overlay like this
>>>
>>> off_trans -I w_xrxxrC.off | off_util - w_xxrxrC.off | antiview - w_xrxrxC.off

...

> For the Tetrahedron and Dodecahedron, only two were the same. There was no
> mirror image model. I didn't include the models, but these were congruent. We
> already determined the reasoning for these, I cut and pasted a note above.
>
> off_util w_xxrxrT.off | antiview - w_xrxrxT.off
> off_util w_xxrxrD.off | antiview - w_xrxrxD.off

The tetrahedron doesn't map onto itself by the inversion, but if you
use an indirect isometry that maps it onto itself then it behaves
the same way as the cube, e.g.

conway wrwwrT > wrwwrT.off
conway wwrwrT > wwrwrT.off
conway wrwrwT > wrwrwT.off
off_trans -M 1,1,0 wrwwrT.off | antiview - wwrwrT.off wrwrwT.off

The dodechahedron matches the cube behaviour exactly, as it has
inversion symmetry.

[Roger Kaufman]

Hi Adrian,

On 11/22/2017 12:19 PM, Adrian Rossiter wrote:
> off_trans -M 1,1,0 wrwwrT.off | antiview - wwrwrT.off wrwrwT.off

Is off_trans -I the same as -M 1,1,1?

A few days ago I started comparing fullgen report of symmetry of
fullerene's to what Antiprism is reporting. The good news is I am
getting a 1:1 match of number on C1 and higher symmetries (and
discovered one, but just one, mistake in the file by me).

I am not sure how fullgen determines symmetry because the models are not
inflated. The discrepancy is that there are often just a few that
fullgen says are Ci that turn out to be Cs after canonical.

I included a zip file of a recent one. So I'm trying to understand Ci
and Cs symmetry, this is a good time for this.

Roger

[Roger Kaufman]

Hi Adrian,

Updated NEWS file.

Roger

[Adrian Rossiter]

Hi Roger

On Wed, 22 Nov 2017, Roger Kaufman wrote:

> On 11/22/2017 12:19 PM, Adrian Rossiter wrote:
>> off_trans -M 1,1,0 wrwwrT.off | antiview - wwrwrT.off wrwrwT.off
>
> Is off_trans -I the same as -M 1,1,1?

No. -M is reflection in a plane passing through the origin and with a
normal in the direction of the parameter. -I is reflection in a point
(the origin) and is equivalent to -S -1.

[Adrian Rossiter]

Hi Roger

On Wed, 22 Nov 2017, Roger Kaufman wrote:

> Updated NEWS file.

Ok. If there are no more changes I'll start preparing for the release.