Brick product [Split from "Johnsonian Polytopes"]

Discussion of tapertopes, uniform polytopes, and other shapes with flat hypercells.

Brick product [Split from "Johnsonian Polytopes"]

Postby Keiji » Mon Jan 02, 2012 1:15 am

On the brick product:

When P is a convex polytope, you can simply split the vertices of P into those of a sequence of hypercuboids (each centred at the origin), make Cartesian products of the operands scaled by the edge lengths of those hypercuboids, and then take the convex hull to get the result of the brick product.

This is not new information, however it is important to realize that the brick product is still well defined even if P isn't convex or if it has curved elements, but using the "convex hull" technique described above doesn't work in the general case.
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Johnsonian Polytopes

Postby quickfur » Mon Jan 02, 2012 8:16 pm

Keiji wrote:On the brick product:

When P is a convex polytope, you can simply split the vertices of P into those of a sequence of hypercuboids (each centred at the origin), make Cartesian products of the operands scaled by the edge lengths of those hypercuboids, and then take the convex hull to get the result of the brick product.

OK, so if P is a square, then the brick product is the same as the Cartesian product?

This is not new information, however it is important to realize that the brick product is still well defined even if P isn't convex or if it has curved elements, but using the "convex hull" technique described above doesn't work in the general case.

Well, the first thing is to understand what happens when P is, say, a diamond instead of a square. Hopefully that will help me understand what exactly the brick product does with the points in P, which will hopefully lead to a workable definition of the brick product for general P.
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Johnsonian Polytopes

Postby Keiji » Tue Jan 03, 2012 1:05 pm

quickfur wrote:OK, so if P is a square, then the brick product is the same as the Cartesian product?


Yes. The other two special cases are the diamond which gives the tegum/SUM product and the circle which gives the crind/RSS product.

quickfur wrote:Well, the first thing is to understand what happens when P is, say, a diamond instead of a square. Hopefully that will help me understand what exactly the brick product does with the points in P, which will hopefully lead to a workable definition of the brick product for general P.


For a diamond you would simply orient one copy of each operand in perpendicular spaces and take the convex hull; that's a special case of the convex hull method since the diamond's vertices can be split into two perpendicular digons centred at the origin.
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Johnsonian Polytopes

Postby quickfur » Tue Jan 03, 2012 8:07 pm

Keiji wrote:[...]
For a diamond you would simply orient one copy of each operand in perpendicular spaces and take the convex hull; that's a special case of the convex hull method since the diamond's vertices can be split into two perpendicular digons centred at the origin.

Hmm. I'm starting to get the impression that the brick product doesn't really do anything with P as a set of points, but rather with the way P was constructed. This is the impression I'm getting from what you wrote above, and also what you said before about how a torus can be factored in 2 different ways, each of which produces a different brick product.

But this can't possibly be true, because it would mean that the brick product is not well-defined for arbitrary P. So obviously I'm missing something here. But I still can't figure out what.

On another note, the standard constructions for the icosahedron/dodecahedron, if I'm not mistaken, have brick symmetry (the coordinates are taken as all changes of sign over some permutation of coordinates). What then does the brick product correspond with if P is, say, an icosahedron?
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Brick product [Split from "Johnsonian Polytopes"]

Postby Keiji » Tue Jan 03, 2012 9:12 pm

quickfur wrote:Hmm. I'm starting to get the impression that the brick product doesn't really do anything with P as a set of points, but rather with the way P was constructed.


Nope, it's just that the convex hull method arises from the fact that if you take a finite set of vertices, then take the convex hull, then use it as the value of P in a brick product, the result is the same as if you take a finite set of vertices, then do your operand placement, then take the convex hull. It doesn't work for curved shapes because these require an infinite set (though I guess you could still just about do it with analogy and considering limits to infinity for e.g. n-gon -> circle), and it doesn't work for concave shapes because a convex hull will destroy them in the process.

This is the impression I'm getting from what you wrote above, and also what you said before about how a torus can be factored in 2 different ways, each of which produces a different brick product.


The thing with the torus is simply because the torus does not produce identical orthographic projections (up to post-projection rotation) from all coordinate angles (there is the "top view" and the "side view"). You will find that the hexagon has the same issue: hexagon{A,B} is not the same as hexagon{B,A} unless A=B, yet the hexagon is convex and not curved anywhere so you can use the convex hull method for it.

On another note, the standard constructions for the icosahedron/dodecahedron, if I'm not mistaken, have brick symmetry (the coordinates are taken as all changes of sign over some permutation of coordinates). What then does the brick product correspond with if P is, say, an icosahedron?


Firstly, for an icosahedron (as with any 3D shape) you'd need 3 operands. You can use the convex hull method, going by this picture. There are two important scalar values in the figure: the length and width of each of the rectangles. I'll refer to these as L and W respectively.

I'll use pentagon, hexagon, octagon for the three operands in this example. The resulting shape would then be 2D+2D+2D = 6D.

Let's say that the pentagon corresponds with the long side of the purple face in the diagram (the "up-down" direction from our perspective), the hexagon with the long side of the dark green face, and the octagon with the long side of the light green face (it doesn't matter due to the symmetry of the icosahedron, but it helps for working through the example).

We must also assign resultant axes to axes in the diagram. Since all operands are 2D, that means two resultant axes per source axis. We'll assign x,y for the pentagon, z,w for the hexagon and φ,σ for the octagon. When we construct our Cartesian products (duoprisms), the component figures will always be oriented in those assigned axes, regardless of which Cartesian product they are a part of (the Cartesian products will intersect each other).

For the purple face, we construct a 5,8-duoprism. The hexagon plays no part because the purple face has no thickness along the hexagon's assigned direction (which is perpendicular to the purple face). We must scale each operand by the size of the hypercube in the operand's assigned direction, so the duoprism is constructed as the Cartesian product of a pentagon scaled by L, and an octagon scaled by W. We place this 5,8-duoprism in the axes x,y,z,w.

For the dark green face, we construct a 5,6-duoprism. The pentagon is scaled by W, and the hexagon by L. This 5,6-duoprism is placed in the axes x,y,φ,σ.
For the light green face, we construct a 6,8-duoprism. The hexagon is scaled by W, and the octagon by L. This 6,8-duoprism is placed in the axes z,w,φ,σ.

Finally, we take the convex hull of the resulting figure. All p,q-duoprisms have pq vertices, so our figure has 5*8 + 5*6 + 6*8 = 118 vertices. You should hopefully be able to work out the rest of the structure of the shape from the description I've provided above if you really want to, I'm not about to go calculating a 6D convex hull, 4D is hard enough already :nod:
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Johnsonian Polytopes

Postby quickfur » Tue Jan 03, 2012 11:06 pm

Thanks for the very insightful description of the brick product with an icosahedron. I think I'm starting to get an idea of how it could be precisely defined, and why P must have brick symmetry.

So here's my first stab at a definition for a brick product Q = P{A1,A2,A3,...,An}. If I understand it correctly, P must be n-dimensional, right?

For simplicity, I'm also going to assume that P is convex for now.

Definition 1

For each point x=(x1,x2,...xn) in P, the brick symmetry guarantees that (-x1,x2,...xn) is also in P. This means the line segment (x1,x2,...xn) -> (-x1,x2,...xn) is also in P, and has length 2*x1. In fact, for any 1≤i≤n, P contains a line segment between (x1...xi...xn) and (x1...-xi...xn), by definition of brick symmetry and convexity of P, each with length 2*xi. Collect these lengths into an array L(x)=(L1,L2,...Ln) = (2*x1, 2*x2, ... 2*xn).

So for each point x=(x1,x2,...xn), we form the Cartesian product A1|L1 * A2|L2 * A3|L3 * ... An|Ln, where the notation Ai|Li means the operand Ai scaled by the length Li.

The union of these Cartesian products over all points x in P (including internal points, though most of them won't contribute much) yields the brick product. In other words:

P{A1,A2,...An} = union over all (x1,x2,...xn) in P of the Cartesian product A1|L1 * A2|L2 * A3|L3 * ... An|Ln.

Evaluation

So let's see if my attempted definition makes sense. If P is an n-cube, say with vertices (±½,±½,...,±½), then L(x)=(1,1,1,...) for all vertices x, and so we have the union of Cartesian products A1*A2*...*An, which is just the Cartesian product itself. Internal points of P, say (½,0,0,0,...) yield the Cartesian product A1|½*A2*...*An, which don't contribute to the final product because it lies inside the bulk of the latter.

If P is an n-cross, say with vertices apacs(½,0,0,0,...), then L(xi) = (0,0,...,1,...0,0) for xi=(0,0,...½,...,0,0). This gives the Cartesian product as 1*1*...Ai...*1*1, where 1 is an abuse of notation to indicate a 0-dimensional point, so the Cartesian product is actually just equal to Ai. Take the union of all such products, and you get A1...An oriented in their respective hyperplanes, with convex hull taken. I assume this would correspond with the tegum product?

Now interestingly, an n-cross also contains points such as (¼,¼,0,0,...), which give rise to the Cartesian product A1|½*A2|½*1*1*1*... . But the resulting shape lies internal to the convex hull of the tegum product, so it doesn't contribute anything more.

Definition 2

So far, all seems good (provided I'm not totally off and just fooling myself), except that we haven't accounted for the case where P is non-convex. Although strictly speaking definition 1 also works for non-convex P (by simply assigning the L=2*(x1,x2,x3,...) for any point (x1,x2,x3,...) regardless of whether the line segment between (x1,x2,...) and (-x1,x2,...) is completely inside P), I don't think it actually corresponds with the real brick product, because any "holes" won't show up in the product, since a point like (±1,0,0,0...) will produce a Cartesian product that completely covers over any hole between, say, (±½,0,0,0...).

But the problem itself suggests a simple solution: if a point (x1,x2,...xn) gives rise to a line segment between (±x1,x2,...xn) and there's a hole in P between (±x1',x2,...xn), where x1' < x2, then we simply subtract the Cartesian product corresponding with points in the hole from the result, instead of adding it to the union.

So what this amounts to is that every time we take the Cartesian product, we hollow out the interior so that only the surface of the Cartesian product remains. Then we take the union of all of these Cartesian products where they correspond with a point in P, and leave it out otherwise. If P is convex, then the internal points of P will "fill out" the bulk of the Cartesian product, so it becomes solid. Otherwise, there will be some holes inside, corresponding to where P has holes (the inside will only be filled out as much as there are points in P, and some spaces will be left hollow where points are missing from P).

In other words:

P{A1...An} = union over all (x1...xn) in P of the surfaces of the Cartesian products A1|L1 * A2|L2 * ... An|Ln.

Evaluation

If P is a torus, then the resulting shape will have holes corresponding to the torus's hole, because the internal points of the Cartesian products will be missing. For all points in the torus (including internal points), the Cartesian products will generate concentric shells that fill out the result up to where the torus hole is. IOW, it automatically "fills in the hull" and works around the impossibility of making convex hulls work with nonconvex P.

Now it should be clear why P must have brick symmetry: if it doesn't, then the scaling factor L=(L1...Ln) wouldn't make any sense.

It is also clear why the hexagon gives rise to two different brick products: its orientation determines which of the operands its long/short axes are bound to (as implied by the order of the Cartesian products). Same with the torus. In fact, all even polygons give rise to two different brick products depending on their orientation (e.g. if the octagon is "resting on an edge" or "standing on a vertex"). That is also why P=square is different from P=diamond.

Definition 2 allows us to form brick products over arbitrary P, including nonconvex P, and even pathological P such as Cantor-set-like amorphous clouds of points (as long as they have brick symmetry). The result will consist of the surfaces of Cartesian products spaced along disconnected points in each coordinate axis, with an infinite number of holes in between. I submit that it is very good definition on that basis. :)

Provided, of course, that I'm not totally deluding myself here about what exactly the brick product is. :P
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Johnsonian Polytopes

Postby Keiji » Wed Jan 04, 2012 2:08 am

Great work! It took me a while to understand it all, but everything in your post so far is consistent with my understanding of the brick product.

There's just one little problem... even your second definition doesn't work with self-intersecting shapes such as an {8/3} octagram, since for a self-intersecting shape the test for whether a point is "inside" the shape is meaningless. However, the brick product is still well-defined in these cases; I believe I have some images that Bowers rendered and sent me of some powertope where P={8/3}.

Regardless, I do very much like your second definition, it is a big step up from the current understanding which could deal with only convex shapes through the convex hull method.
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Johnsonian Polytopes

Postby Keiji » Wed Jan 04, 2012 2:22 am

Actually, now that I think about it some more, that one's solved too: if you think of the self-intersecting shape as being its surface, one dimension lower, and use your second definition, you'd get the correct result. Mainly my mistake here for treating bounding space as net space, which it is not. :)
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Johnsonian Polytopes

Postby quickfur » Wed Jan 04, 2012 6:53 am

Keiji wrote:Great work! It took me a while to understand it all, but everything in your post so far is consistent with my understanding of the brick product.

Thanks! It's good to know that I wasn't just completely deluding myself.

[...] Regardless, I do very much like your second definition, it is a big step up from the current understanding which could deal with only convex shapes through the convex hull method.

What is the "current understanding"? I thought Bowers himself always knew what it was, just that he didn't really explain it in a way that your general average person could understand.

Keiji wrote:Actually, now that I think about it some more, that one's solved too: if you think of the self-intersecting shape as being its surface, one dimension lower, and use your second definition, you'd get the correct result. Mainly my mistake here for treating bounding space as net space, which it is not. :)

Hmm, that is certainly an interesting way of making things work with self-intersecting shapes. Although if you want to preserve the self-intersecting nature of the product, you'd want a more careful definition (i.e., take the union of the Cartesian products involving each surtope separately, so that at the points of self-intersection you actually have two copies of the Cartesian product, instead of everything melting into the same union). The resulting shapes would physically occupy the same points, though, so this distinction is really just academic.
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Johnsonian Polytopes

Postby quickfur » Wed Jan 04, 2012 7:02 am

P.S. Assuming my definition is correct, it still takes some work to make it into an actual, usable algorithm. Taking an infinite union (because P contains an infinite number of points) is all fine and dandy mathematically, but it's not exactly practical.

For polytopes P, it suffices to look at the extremal cases, that is, work in terms of vertices. With a bit of care, the non-convex case should work out in terms of vertices as well. But what about curved surfaces, like P=torus? Although now we have a definition that at least in theory gives a result, it would require some extra work to actually make it computable.

Obviously, we can't possibly enumerate algorithms for all possible P; but at least we can try to tackle the simplest cases, like the rotatopes and toratopes. I'd love to work out some representative cases as brick product examples, for instance.
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby Keiji » Wed Jan 04, 2012 3:32 pm

Just so you know, I reverted your "improved" notation because it's rather bad form (not to mention confusing) to say that a vertices coordinates are half of its representative vector's values, and similarly, if we are treating a shape A as a set, the notation xA where x is a scalar ought to refer to some operation that doubles the cardinality of A, which scaling does not.
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby quickfur » Wed Jan 04, 2012 3:47 pm

Keiji wrote:Just so you know, I reverted your "improved" notation because it's rather bad form (not to mention confusing) to say that a vertices coordinates are half of its representative vector's values, and similarly, if we are treating a shape A as a set, the notation xA where x is a scalar ought to refer to some operation that doubles the cardinality of A, which scaling does not.

Argh, you better clean up the whole section, 'cos i made more edits while you were at it, so the whole thing is messed up now.
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby quickfur » Wed Jan 04, 2012 3:49 pm

But I have to say that I really dislike my original notation for scaling because the vertical bar is used with another meaning in set notation, which makes it very confusing. A better notation needs to be worked out that doesn't induce squinting.
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby Keiji » Wed Jan 04, 2012 4:00 pm

Hmm, I think it looks fine since it's rendered smaller than the bar used in set construction. I can't think of any better notation to use for it.
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby quickfur » Wed Jan 04, 2012 4:28 pm

Keiji wrote:Hmm, I think it looks fine since it's rendered smaller than the bar used in set construction. I can't think of any better notation to use for it.

What about using * for scaling since we're using × for Cartesian product?
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby quickfur » Wed Jan 04, 2012 6:38 pm

Alright, regardless of notation, I'd like to explore some of the base cases for the brick product.

point{} = point (not the empty set; see below for explanation)
digon{point} = point
digon{A} = scale(A, len(digon)), for all A with dimension ≥1.
square{point,point} = point
square{point,digon} = scale(digon,edgelen(square)) = digon{digon}
square{digon,digon} = square
square{digon,A} = prism(A)
square{A,B} = A×B
diamond{point,point} = point (diamond = 2-cross)
diamond{point,digon} = scale(digon,diameter(diamond)) = digon{digon}
diamond{digon,digon} = diamond
diamond{digon,square} = octahedron Changed from square pyramid ~Keiji
diamond{digon,A} = bipyramid(A)
diamond{A,B} = general tegum product of A and B
circle{point,point} = point
circle{point,digon} = scale(digon,diameter(circle)) = digon{digon}
circle{digon,digon} = circle
circle{digon,circle} = sphere
circle{circle,circle} = glome Changed from duocylindrical crind (i think?) ~Keiji
circle{digon,square} = (square) crind
circle{square,square} = tesseractic crind
circle{A,B} = general crind product of A and B
ellipse1{digon,ellipse2} = ellipsoid (with axes derived as some combination of ellipse1's and ellipse2's axes - probably some kind of product?)

Some general observations so far:
  • when all operands are digons, the brick product P{...} = P, that is, the result is just P itself.
hexagon1{digon,digon} = hexagon1 (hexagon with two horizontal edges)
hexagon2{digon,digon} = hexagon2 (hexagon standing on its vertex, that is, with two vertical edges)
hexagon1{digon,square} = biaugmented cube = hexagon2{square,digon}
hexagon2{digon,square} = square bifrustum = hexagon1{square,digon}
hexagon1{digon,circle} = biaugmented cylinder (cylinder with two cones attached to its lids)
hexagon2{digon,circle} = circular bifrustum

Observations:
  • In general, the brick product is not commutative; changing the order of the operands changes the product.
  • When P is a hexagon, changing its orientation from standing on edge to standing on vertex amounts to swapping the two operands. This doesn't seem to apply for octagons, though:
octagon1{digon,digon} = octagon1 (octagon with two horizontal edges)
octagon2{digon,digon} = octagon2 (octagon standing on vertex - i.e., tetra-augmented square / tetra-augmented diamond)
octagon1{digon,square} = elongated square bifrustum
octagon1{square,digon} = elongated square bifrustum = octagon1{digon,square}
octagon2{digon,square} = augmented square bifrustum
octagon2{square,digon} = augmented square bifrustum = octagon2{square,digon}
octagon1{digon,circle} = elongated circular bifrustum (i.e., cylinder with two circular frustums attached)
octagon1{circle,digon} = elongated circular bifrustum = octagon1{digon,circle}
octagon2{digon,circle} = augmented circular bifrustum (i.e., bifrustum with two cones attached)
octagon2{circle,digon} = augmented circular bifrustum = octagon2{digon,circle}

Observations:
  • So here we see that both octagon1 and octagon2 are commutative. Upon deeper analysis, the reason for this is because both of them have the property that they are invariant under rotation by 90°. Any 4n-gon will have this property, so this means that when P is a 4n-gon, the brick product is commutative.
  • So this suggests an interesting line of investigation: what about polygons of other degrees? A simple investigation shows that (4n+2)-gons behave like hexagons: rotating the standing-on-edge polygon by 90° turns it into its standing-on-vertex counterpart, and vice versa, so swapping the order of operands is equal to switching between the two polygon orientations.
  • Since polygons of odd degree are not bricks, this covers all possible cases (I think).
  • So in summary, each 2n-gon P gives rise to two distinct brick products, corresponding respectively with two orientations of P (on-edge or on-vertex). When n is even, the brick product is commutative, and when n is odd, the brick product is anticommutative (swapping operands = swapping orientations).

I'll stop here for now. Next post I'll get into more interesting stuff, like what happens when P is 3D.

Aside: why the Cartesian product of 0 operands must be non-empty: consider the following inductive definition of the Cartesian product:
Code: Select all
cprod(∅) = {()}
cprod(A ⋃ {a}) = cprod(A) × a

Remember that the Cartesian product of two sets a' and a means the set of all ordered pairs (p',p) for each p' in a' and for each p in a. If the base case were an empty set, then a' is empty, so there is no such p' in p, and therefore there is no such pair (p',p), which means the Cartesian product of non-empty sets is empty. Which is nonsense.

So the empty Cartesian product must be non-empty. In particular, it must consist of a single element, since otherwise the Cartesian product of a single set has more elements than the set itself, which is also nonsense. Furthermore, the Cartesian product of a single set must be equal to itself, since otherwise it doesn't make sense either; so the single element must be a 0-dimensional vector, so that the concatenation (p',p) where p' is the single element, will be equal to p. Therefore, the empty Cartesian product must be equal to a singleton set containing the empty vector, that is, it is a 0-dimensional point (the only possible 0-dimensional object).

(N.B. Do not confuse the 0-dimensional point with the null polytope; the null polytope is equivalent to the empty set, which will lead to the nonsensical result that all Cartesian products are empty.)
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby Keiji » Wed Jan 04, 2012 7:46 pm

Before I read the rest of that post, I'd just like to say something about the point vs empty set topic. I know full well the Cartesian product of no operands is the point, however, you must then take the surface of that Cartesian product.

The neighborhood of the sole point in a point polytope is only going to contain the point itself. Therefore, it doesn't contain a neighbor not in the polytope, therefore, there are no points in the surface of the point, therefore, S(Point) = empty set (or null polytope).

Similarly, S(S(X)) would be the empty set for any X, since S(X) would always be some manifold with no boundaries. Which means S is not a function that decreases the net space by one: it only does that the first time it's applied and if applied twice, yields the null polytope. Whether we want to change the definition of S to suit what I wrote about it, or whether we just use the current S and correct that note in the article, is something to think about.

Edit: Alright, I corrected two of the cases you listed, other than that it's all correct but stuff I already knew since the results were almost all 3D or lower. The higher dimensional ones will be much more interesting I'm sure :)
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby quickfur » Wed Jan 04, 2012 8:47 pm

Keiji wrote:Before I read the rest of that post, I'd just like to say something about the point vs empty set topic. I know full well the Cartesian product of no operands is the point, however, you must then take the surface of that Cartesian product.

The neighborhood of the sole point in a point polytope is only going to contain the point itself. Therefore, it doesn't contain a neighbor not in the polytope, therefore, there are no points in the surface of the point, therefore, S(Point) = empty set (or null polytope).

The thing is, the neighborhood of a point is taken in the ambient space, not on the manifold itself. But you're right that in 0D, there is no other point except the empty vector, so the surface must be a null polytope. My bad.

Similarly, S(S(X)) would be the empty set for any X, since S(X) would always be some manifold with no boundaries. Which means S is not a function that decreases the net space by one: it only does that the first time it's applied and if applied twice, yields the null polytope. Whether we want to change the definition of S to suit what I wrote about it, or whether we just use the current S and correct that note in the article, is something to think about.

This is not true if the neighbourhood is taken in the ambient space, which is the intention here. It has to be, because we're working with Cartesian coordinates in n-space, since the Cartesian product yields n-vectors without regard to what subset of R^n they cover, so S(X) also yields n-vectors, and so S(S(X))=S(X).

Edit: Alright, I corrected two of the cases you listed, other than that it's all correct but stuff I already knew since the results were almost all 3D or lower. The higher dimensional ones will be much more interesting I'm sure :)

Eeeek!! Did I actually write "square pyramid" when I meant "square bipyramid"?! Sheesh. I must be turning senile. I'm still too young for that!!! :( :( :(

I was thinking also of exploring non-convex P as well, although the simplest cases threaten to become quite complex, since our good friend {5/2} isn't a brick, which means that if you disregard compounds like {6/3} (which don't really produce anything interesting, just compounds of their respective brick products), the smallest regular P is {8/3}.
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby quickfur » Thu Jan 05, 2012 5:58 am

I've discovered a strange property of the brick product, as we have currently defined it, and this concerns non-convex operators P. This may be just an artifact of our current definition, or it may be something more inherent. I'll leave it up for discussion which one it is.

First, I was wrong about non-convex P being complicated: no one says we have to restrict ourselves to regular shapes. So let's start with P={4/2}, that is, two perpendicular digons. For simplicity, assume all digons have length 1 unless otherwise stated. For starters, let's orient it parallel to the coordinate axes so that one digon is horizontal and the other is vertical:

P{digon,square} = square with a digon piercing through it (like a square kebab, if you will)
P{square,digon} = same as above, except in a different orientation
P{digon,circle} = circle (or rather, disk) with a digon piercing through it. Note that a disk is formed even if the operand is a hollow circle, because as we take the Cartesian products over all points in P, we form concentric circles whose union is a disk.
P{square,square} = square with another square piercing through it -- this is a 4D configuration where the two squares lie in complementary planes, so their only intersection is the origin.
P{circle,circle} = disk with another disk piercing through it -- again, the disks lie in complementary planes and only intersect in the origin.

So far so good, right? Nothing strange (yet). Now let's rotate P so that the digons are at 45° to the coordinate axes. Call the result P'. Note that now the points in P' consist of (x,x) where x ranges from 0 to sqrt(2)/2. (Only positive x matters, since P' has brick symmetry.) Now let's pass it the same operands as before and see what happens:

P'{digon,square} = cube. Why? because as x varies from 0 to sqrt(2)/2, the point (x,x) causes the scaled Cartesian products of the digon and square to form concentric cubes, so eventually their union is a solid cube.
P'{square,digon} = cube. Technically, the cube is in a "different orientation" but we can't tell, because even though the Cartesian products have a different "orientation", they are still concentric cubes indistinguishible from the previous brick product.
P'{square,square} = tesseract. Same reason as the above: the points (x,x) as x varies form concentric tesseracts, the union of which is a solid tesseract.

In fact, no matter what you put in the operands, the brick product under P' never produces a non-convex shape, because any "missing" parts caused by points outside (x,x) yet still within the square convex hull of P' are completely papered over by the Cartesian products generated by (x,x). Therefore, brick products under P' are exactly the same as brick products with P=square.

The only way you'd be able to tell the difference is if, instead of a simple set union, you use a bag union that remembers the density of each resulting point (the density of a point is how many Cartesian products it's included in). Then you'll notice that P'{A,B} has a lower density than square{A,B}. Note that this density is not just a simple integer, because we're taking the union over uncountable sets here; it's well possible that certain points will have infinite density, and perhaps different degrees of infinite density, depending on what kind of holes are present in P.

Here's an example: let P'' be two vertical digons, i.e., line segments formed by (1,1)-->(1,-1) and (-1,1)-->(-1,-1). Then P''{A,B} is the same as square{A,B}, using our current definition. If we use a bag union instead, then we find that, for example, P''{digon,square} is a cube with infinite density on its top and bottom faces, and density 1 everywhere else, whereas square{digon,square} is a cube with infinite density on all its faces (if the square is hollow), or infinite density everywhere (if the square is filled). (Or if you want to get complicated, setting P=a half-filled cube will produce a shape with different degrees of infinite density.) On the other hand, P''{square,digon} has infinite density on its 4 lateral faces and density 1 everywhere else, so it's distinct from P''{digon,square}.

Based on these observations, I would've been inclined to say that we should modify our definition of the brick product so that the result only contains points with infinite density, since those cases best reflect the non-convexity of P, were it not for: (1) using a bag union in the definition is ugly, and seems to be adding unnecessary complexity to what should be a relatively simple definition; (2) bag unions are a pain to compute; (3) some non-empty operators P will yield empty brick products due to not reaching infinite density; and (4) the behaviour of non-convex P under the current definition isn't altogether hopeless, as I'll explain next:

So far, we've only examined the cases where P has either vertical/horizontal lines or lines at 45°. But what about, for example, P'''={6/2}? (i.e., three digons at 60° to each other). Like the hexagon, P''' has two possible orientations; if we choose the orientation with one vertical digon, for instance, then P'''{digon,square} is a square with a cuboid sticking through it, and P'''{square,digon} is square cuboid with a digon sticking through it. So some degree of the non-convexity of P''' still shows up.

So you see that points in non-convex P affect the brick product depending on what angle they lie relative to the coordinate axes. The closer they are to the coordinate axes, the more the non-convexity show up, and the further away they are, the more the non-convexity is "papered over", until when they are parallel to k*(1,1,1,1...), then they completely cover over any holes in P within the bounding hypercube of the point.

Based on this, I'm torn between whether to adopt the bag union version of the definition, or leave things the way they are. Thoughts?
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby Keiji » Thu Jan 05, 2012 10:10 am

As I understand it, P'{square, digon} should look like this:

Image

I think P'{square, square} should have four squares oriented in zw separated in xy, all tapered to the origin, forming four square pyramids joined at their apexes.

This is just going by my intuition, though; any chance the definition can be amended to produce these figures?

I don't like the idea of a bag union, though... it's an unnecessary overcomplication. :|
User avatar
Keiji
Administrator
 
Posts: 1984
Joined: Mon Nov 10, 2003 6:33 pm
Location: Torquay, England

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby quickfur » Thu Jan 05, 2012 4:29 pm

Keiji wrote:As I understand it, P'{square, digon} should look like this:

Image

You would get this figure with the current definition if instead of a solid (or hollow) square, you take only the four vertices of the square. IOW, P'{vertices(square),digon} should give you this figure.

I think P'{square, square} should have four squares oriented in zw separated in xy, all tapered to the origin, forming four square pyramids joined at their apexes.

I believe you should be able to get this if you replace one of the square operands with just the vertices of a square: P'{square,vertices{square}}.

If you replace both squares (i.e., take P'{vertices(square),vertices(square)}), you get a configuration of 8 intersecting lines corresponding with the diagonals of a tesseract.

Furthermore, if you use a hollow square in one operand, that is, only the vertices and edges without the interior, or just the edges (since vertices are included in the edges), then you get P'{vertices(square),edges(square)} = tesseract with cubic pyramids carved out of each facet, that is, the edge-skeleton of the tesseract tapered to the origin.

Using edges(square) in both operands, that is, P'{edges(square),edges(square)}, give you the 2-skeleton of a tesseract (i.e., tesseract with vertices, edges, and ridges but no cells).

If the operator is a square instead of P', then all of these products would just yield the tesseract. So I guess using various degrees of hollowed-out operands will expose more of the non-convex structure of P'.

This is just going by my intuition, though; any chance the definition can be amended to produce these figures?

I wonder if there's a consistent way of mapping the non-convex parts of P' to taking k-skeletons of the operand(s), so that instead of explicitly "skeletonizing" the operands, it's implied by the operator itself. If there is, it would solve our dilemma in a fundamental way.

I don't like the idea of a bag union, though... it's an unnecessary overcomplication. :|

Yeah, I agree. I don't like the idea of a bag union either. Let's not do that unless we absolutely have no other choice.
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North

Re: Brick product [Split from "Johnsonian Polytopes"]

Postby quickfur » Sat Jan 07, 2012 5:12 am

I'm still grappling with how to make the brick product produce more "intuitive" results when the operator is non-convex. I believe the case where the operands are non-convex are handled quite well by the current definition, because the Cartesian products handle the non-convexity quite well. The trouble that non-convex operators have strange, unexpected effects.

This, and also the explosion of complexity when you go up to 3D operators and non-trivial operands, prompted me to try to explore what I call ... brick product algebra. :D That is, ways of algebraically manipulating brick products so that they're (hopefully) easier to evaluate. Here's what I found so far:


  • (Identity) The digon behaves like an "identity" element of the product: P{digon,digon,...} = P. (We'll see below in what other ways the digon behaves like an identity.) For convenience of notation, let's denote the digon by "1".
  • (Zero) The point behaves like a "zero" element of the product. For example, point{} = null polytope, and P{point,point,...} = point. So the point tends to reduce things to itself (and in the case of point{} to the empty set).
  • (Distributivity under set union) If P=P1 union P2, then P{A1...An} = P1{A1...An} union P2{A1...An}. That is:

    (P1 union P2){A1...An} = P1{A1...An} union P2{A1...An}

    Note that P1 and P2, obviously, must themselves be bricks.
  • (Projection) P{A1,...,A(i-1),point,A(i)...,An} = proj_i(P){A1,A2,...An}, where proj_i(P) = projection of P into (n-1)-space along the i'th axis. This may seem like a useless property, but its converse may turn out to be very useful: given any brick Q whose projection along some axis maps to P, we can transform a brick product involving P into a brick product involving Q by adding a point operand: P{A1...An} = Q{point,A1...An}, for example. This may be useful in massaging the operator into a form we can use with the Reduction property (see below).
  • EDIT: Ignore what I wrote about the Reduction property. I've just realized that the so-called Reduction property is actually a form of Associativity. Basically, the way it works is like this:

    P{A1...An}{B1...Bm} = P{A1{B1...Bi},A2{B(i+1)...Bj},...An{Bk...Bm}}

    where the notation P{A1...An}{B1...Bm} means (P{A1...An}){B1...Bm}. Basically, m must be equal to the sum of the dimensions of all the Ai's, and in the factored form of the product, each Ai absorbs as many Bj's as it has dimensions. So for example, if A1 is a circle, then it will pick up B1 and B2.

    This factorization is most useful when there are lots of digons lying around: each digon among the Ai's pick up exactly one Bi, and is a no-op, so the Bi just gets copied into the factored form. If a particular Ai picks up only digons among the Bi's, then it is also a no-op, and the Ai gets copied into the factored form.

    Examples:
    - circle_bipyramid{1,1,triangle} = diamond{circle,1}{1,1,triangle} = diamond{circle{1,1},1{triangle}} = diamond{circle,triangle} = circle-triangle tegum
    - circle_bipyramid{1,triangle,1} = diamond{circle,1}{1,triangle,1} = diamond{circle{1,triangle},1{1}} = diamond{triangular_crind,1} = triangular crind bipyramid.



I'm still investigating other brick product composition/reduction properties like the above; there may be something that lets you deal with the case when two non-digons line up nicely one under the other. I'll post more when I have more results. :)

P.S. Please check the above, especially the Reduction property, for accuracy. If it doesn't work for all cases, it would be VERY nice to know under what conditions it is valid.
quickfur
Pentonian
 
Posts: 2935
Joined: Thu Sep 02, 2004 11:20 pm
Location: The Great White North


Return to Other Polytopes

Who is online

Users browsing this forum: No registered users and 25 guests

cron