Adrian G wrote:
> OK, I have a question that I've been wondering about, more to do with
> stack notation but anyway...
>
> In all the descriptions of stack notation I've read it says that it can do
> anything that siteswap can, but I've naver seen any synchronous examples.
>
> Standard stack notation wouldn't work, but has anyone made any extensions
> to it to support synch?
>
> The best I could think of would be having two 'stacks' and if there is an
> x after the number then it would cross to the other stack to normal (e.g.
> a 4x would cross but a 5x would go straight, like siteswap). so (4,2x)*
> (box) would end up something like (2,1)* because you'd count the number of
> balls thrown from each hand does that make sense?
>
> Does anyone have any other ideas?
>
> Also on the topic of stack notation, as far as I can tell, multiplexes are
> impossible, which I found quite interesting. This is because a multiplex
> pattern will always contain a squeeze catch (e.g. there is a 2 and a 3
> that are caught at the same time in [43]23 ). Stack notation doesn't allow
> two balls to be caught at once in the same hand as the ball is just
> 'inserted' into the stack (which is why all stack notation patterns are
> valid). Therefore it is impossible to notate multiplex patterns, is that
> correct?
>
A nice question, and the answer is actually simpler than you think. Well,
at least I thought that when starting to write this :-)
As the basic stack notation doesn't care about the times when the balls
are juggled, the decent way to use multiplexes and synch patterns is the
same format we use for siteswaps to determine the times of the throws and
the hands used, while letting the numbers deal with the intertwining of
the order. So to turn [43]23 into a stack sequence, we first look at how
the orbits form. Here we have our first problem, does the multiplexed 3
stay the same ball throughout the pattern or is it part of the orbit with
the 4 and 2? My preference is to look at when the balls about to be
multiplexed were last thrown. One was previously a 3 and the other was a
2, so I'd assign the higher throw to the first throw in the multiplex,
which is the 4, leaving the 2 to become the 3. So in fact the 3 is not its
own orbit (that's the pattern I'd call [34]23 if it's required to
distuinguish the two). So the orbits of [43]23 form in the same way as in
6334, if there was no multiplex. We convert this to the stack sequence
$4334 and just put the first two throws in brackets to communicate the
timing $[43]34. For the other pattern, we get
[34]34 -> 4534 -> $4434 -> $[44]34. So that's one answer.
But the problem isn't completely dealt with yet. What if we had chosen
[43]23 to have the three separate orbits? We'd have [43]23 -> 6424 ->
$4324 -> $[43]24, and [34]23 -> 5524 -> $4424 -> $[44]24. In a
siteswap-free world, who's to say how the patterns $[43]34 and $[44]24, or
the patterns $[44]34 and $[43]24, could be distinguished as being the
same? I don't have an immediate solution, so I'd just say that there's two
ways of writing the same pattern in stack notation, and allow it to
complicate things even worse for patterns with more and larger multiplexes.
Then for the synchronous stacks. Here too we could just apply the
(R,L)(R,L)* format in the same way as above for [RR]LR, but now I'm
discouraged that it would lead to worse complications than above, so let's
not get into it. At the very least it wouldn't allow for the nice rule of
writing the mirror image of a pattern by just switching the throws, like
in siteswap we can say that (8,6)(4,6) is the mirror image of (6,8)(6,4).
That property is needed to be able to use * as a shorthand for symmetric
patterns. Let's try the approach of using two stacks instead.
So each hand throws to its own stack, unless there is an x attached to
the throw. This should work, but what ambiguities does it create? For
anything without crossing throws, there is no problem, like (6,4) =
$(3,2). Or anything without throws that are simultaneously thrown to the
same stack, like (8,4)(4x,4x) = $(3,2)(2x,2x). In both these cases I'm
thinking that the bottom ball in each stack is removed (if there is no 0)
before inserting them back into place. But then there are patterns like
(8x,4)(4x,8)(8,4x)(0,4x). Since we know the siteswap, we can work out how
we'd like the stacks to look after each pair of throws and then determine
how to use stack notation to record these changes. So, using letters for
the names of the balls, the stacks should be (ABC,DE) -> (BC,EDA) ->
(C,DBAE) -> (DC,BAE) -> (DBC,AE) and then it repeats with the A and D
switched.
So here's where we have to do some thinking. Once we remove the balls
from the bottom of the stacks, the order we put them back in can now
matter since they now go in the same stack. I was first thinking we should
always put the crossing throw in first, or the one that's written first. I
now feel the best way is to put in the smaller one and then the larger one
(and neither "sees" the other ball where it was before this throw). Using
this rule the whole pattern is $(3x,2)(2x,4)(2,1x)(0,2x). This system
actually works much better than I anticipated! For example, the * can be
used for mirrored patterns, like the box becomes (4,2x)* = (4,2x)(2x,4) =
$(2,1x)(1x,2) = $(2,1x)*.
Only small gripes remain, such as two simultaneous throws to the same
position shouldn't be allowed. Like using (3x,3) never creates a pattern
that couldn't be written with either (2x,3) or (3,2x), but only causes
confusion. Also determining the number of balls in this type of
synchronous stack sequence isn't as straightforward as with normal stack
patterns.
Now that I worked that out, I want to revisit the multiplexes. Sorry for
the confusion of presenting another method of doing that in the same post
:-) This time for the multiplex, let's remove all the balls in the
multiplex from the stack before returning them in increasing order of
their values. That sounds like it should work! The states for the two
orbit [43]23 are [xx]xx, xxxx and x[xx]x. The full cycle of repeating
these with "colored balls" the is [AB]CD -> CDBA -> D[BC]A -> [BC]AD ->
ADCB -> D[CA]B -> [CA]BD -> BDAC -> D[AB]C -> [AB]CD. From that we can
read the stacks by ignoring the brackets. We now deduce that a suitable
stack sequence for these changes is $[43]34 by working out each change at
a time. Similarly for the other pattern [34]23 we derive the form $[34]34,
which is pleasantly similar to the first one. Even though we still need to
disallow same values within a multiplex, like [33], I find this method
superior to the one described above. At least now it seems that each
pattern only has one way to write it!
Mixing it together: (6x,[4x4])(2,[4x4x])* = $(4x,[2x3])(2,[3x4x])* :-)
So what do you think? Does that work? I realize I was working parts of
this out as I was typing, so do ask for clarification where needed. Now
let's see someone count the crossing in the braids for these patterns!
(That's what vanilla stack sequences can be used for.)
-Miika
--
Siteswaps of the day: skull , toast , prank