You could taper the sphere to circle, too, by simply taking spherinder and cutting away... (imagine circle->line in this way, the intermediate shapes are not ellipses, but circles "with ends cut")
PWrong wrote:You could taper the sphere to circle, too, by simply taking spherinder and cutting away... (imagine circle->line in this way, the intermediate shapes are not ellipses, but circles "with ends cut")
I don't like the idea of that at all. There are several ways to turn a circle into a line, so I don't think we should pick one arbitrarily.
It looks like we've got some problems with the taper operation.
1. It's not associative.
2. It's obviously not commutative.
3. It's not defined for some pairs of objects.
4. We get four uninvited guests in 3D, and one in 2D.
We can't solve these problems by only tapering to a point. Maybe we need a different operation that will produce a cone. For instance, take any line through the origin in the xy plane, and rotate it around the y axis. This produces the double cone, which in some ways is more natural than the cone.
moonlord wrote:Umm, can anyone explain the tapering process in more detail? When none of the elements is a point, I don't understand it at all...
A line is NOT a special case of a circle. It is a special case of an ellipse. A circle is also a special case of an ellipse. Therefore it is possible to determine a single way to taper from a circle to a line.
It looks like we've got some problems with the taper operation.
1. It's not associative.
2. It's obviously not commutative.
How are these problems?
Then again, exponentiation isn't defined when the LHS is negative and the RHS is a non-integer. We don't go around trying to improve exponentiation.
Define an "uninvited guest"...
Also, there is a problem with the "double cone" as you call it. It is self-intersecting. So the circle at one end has positive area while the circle at the other has negative area. This means the object has zero volume. We can't have objects with zero volume.
The "circle with ends cut" thing is definitely not arbitrary
PWrong wrote:The "circle with ends cut" thing is definitely not arbitrary
It's arbitrary in the sense that it's not the only object of which circle and line are a special case. It's not enough to simply "occur frequently".
Given two objects A and B, there may be infinitely many ways to continuously transform A into B.
PWrong wrote:Rob wrote:A line is NOT a special case of a circle. It is a special case of an ellipse. A circle is also a special case of an ellipse. Therefore it is possible to determine a single way to taper from a circle to a line.
But a line and a circle are also special cases of the "circle with ends cut" that Marek suggested. So there is no unique way to taper from circle to line. I think it's best that we don't define circle->line at all. Similarly, the line is not a special case of a square, it's a special case of a rectangle. Unfortunately, this doesn't mean we can exclude the triangular prism, because it's an extruded triangle.
PWrong wrote:Rob wrote:PWrong wrote:It looks like we've got some problems with the taper operation.
1. It's not associative.
2. It's obviously not commutative.
How are these problems?
Well, I suppose it actually can be commutative, since point->circle is just an upside down cone. But not being associative is a problem because we have to write brackets every time we want to taper twice.
PWrong wrote:Rob wrote:Then again, exponentiation isn't defined when the LHS is negative and the RHS is a non-integer. We don't go around trying to improve exponentiation.
Actually, that's essentially why the complex numbers were invented. But in this case, we want to enumerate the possible cones in nD. Normally we would use our notation to write out all the possible shapes. But if some shapes aren't valid, we have to investigate each one individually.
PWrong wrote:Rob wrote:Define an "uninvited guest"...
When we were trying to count torii before, we had objects like circle#square and "a pair of concentric cylinders" cropping up. All we wanted was the torus, so these other objects were uninvited guests.
Now we're trying to include the cone in our list of shapes, and we're getting another long list of 3D objects that noone asked for. Personally, I don't want to include triangles, pyramids, prisms and wedges.
PWrong wrote:Rob wrote:Also, there is a problem with the "double cone" as you call it. It is self-intersecting. So the circle at one end has positive area while the circle at the other has negative area. This means the object has zero volume. We can't have objects with zero volume.
Even if the other circle had a negative radius, the area is pi r^2 which is always positive. Anyway, the volume of a cone doesn't become negative just because you turned it upside down.
I don't see the problem with this. The wedge is a rather interesting object to me anyway, and besides, I'd like to be able to visualize more objects in the 4th dimension (tesseracts are boring )
Wedge vs plough: In the plough, you shrink the base of the triangle. In the wedge, you shrink the height instead - this gives you two curved faces...
Care to tell me what you think of my proposed tapering notation?
PWrong wrote:Wedge vs plough: In the plough, you shrink the base of the triangle. In the wedge, you shrink the height instead - this gives you two curved faces...
I said the wedge is a cross-section of cone -> line, which means we shrink the base. So my wedge is the same as your plough. I don't mind which name we use, but I think we should reject the one with curved faces.
Care to tell me what you think of my proposed tapering notation?
It seems a bit too long. It's good for precisely defining an object, but we usually want to describe the object in general, ignoring the parameters.
What about this?
Use ordinary RNS notation, but to taper an object, put an asterisk over the parameter you want to reduce to zero. If it's a radius, put the asterisk next to the brackets.
I think we shouldn't, because it is a valid object, and certainly isn't self-intersecting.
Ok, we'll use that. I was thinking of changing the star to something else anyway. I have a further suggestion though. When we use the xyz notation instead of numbers, maybe we should put letters in the superscripts. So the cone is (xy)<sup>z</sup> and tetrahedral prism is x<sup>yz</sup>w.Here it is: One star is 1, two stars is 2, etc. As in superscript.
I've also given names to your x->y shapes, and have also included the extra torii that you forgot about (e.g. the triangular torus).
Finally, the cylinder->circle and the torus->sphere have no expression and are invalid.
Note that the sum of all the numbers still equals the dimensionality of the shape. Also, note how the number of tapertopes in the nth dimension is 3n-1.
Now I have two suggestions. One, can we get rid of the square brackets? If they are present they always start at the beginning of the expression, and are unnecessary if we simply evaluate the expression from left to right.
Two, these "tapertopes" as I have named them are a superset of the rotopes. Can we therefore extend RNS notation to include these taperings, and replace rotopes on the Wiki with tapertopes?
PWrong wrote:Ok, we'll use that. I was thinking of changing the star to something else anyway. I have a further suggestion though. When we use the xyz notation instead of numbers, maybe we should put letters in the superscripts. So the cone is (xy)<sup>z</sup> and tetrahedral prism is x<sup>yz</sup>w.Here it is: One star is 1, two stars is 2, etc. As in superscript.
PWrong wrote:I've also given names to your x->y shapes, and have also included the extra torii that you forgot about (e.g. the triangular torus).
Would that be circle # triangle? If we include that one, we should probably include the square torus (circle#square) as well. I don't think that's a good idea.
PWrong wrote:Finally, the cylinder->circle and the torus->sphere have no expression and are invalid.
What's wrong with them? cylinder->circle is the same as triangle x circle, and it's expression is 21<sup>1</sup>. Torus->sphere may self-intersecting, but otherwise it's ok, and you've already included it in your list, under the name "toroidal pyramid".
PWrong wrote:Note that the sum of all the numbers still equals the dimensionality of the shape. Also, note how the number of tapertopes in the nth dimension is 3n-1.
That's a surprisingly simple formula, if it's correct. I think we'll have to check the 5D tapertopesNow I have two suggestions. One, can we get rid of the square brackets? If they are present they always start at the beginning of the expression, and are unnecessary if we simply evaluate the expression from left to right.
So cube pyramid would be 111<sup>1</sup>, while triangular diprism is 1<sup>1</sup>11. What would 11<sup>1</sup>1 be?
PWrong wrote:Two, these "tapertopes" as I have named them are a superset of the rotopes. Can we therefore extend RNS notation to include these taperings, and replace rotopes on the Wiki with tapertopes?
I was thinking we might redefine "rotopes" to include the tapertopes, and restrict tapertopes to objects that use the taper operation at least once. So the cone is a tapertope, but a cylinder isn't. That way tapertope has a similar definition to toratope.
Then, there are the spherated versions, as in (21123). As someone pointed out, their number is the number of the base bodies.
We decided to scrap my idea for tapering, and use PWrong's, which -is- tapering to a point.
PWrong wrote:We decided to scrap my idea for tapering, and use PWrong's, which -is- tapering to a point.
Again, it's more complicated. Every object has at least one arbitrary parameter that can be tapered.
Users browsing this forum: No registered users and 2 guests