multiplex prop assignment
7 views
Skip to first unread message
Christian Helbling
Feb 12, 2021, 3:29:32 PM2/12/21
to juggling-interchange-format
Hi
>> Many applications like causal diagram editors or jif generators won't care about
>> props and prop permutations at all. They should not need to specify them.
>> Luckily, they can be filled in by code.
>> If we include a few rules how this prop-filling code should behave, we can
>> probably arrive at deterministic prop ids.
>> "What reasons do we have to specifiy props in jif at all then?", you ask.
>> Well, if we have a lot of multiplexes, the prop-filling code might not
>> do what we want to express.
On 10.02.21 23:02, JaCo Stuifbergen wrote:
> I think that, in multiplexes, we should make a distinction between [45] and [54].
> The definition might be that in [45], the ball that was first caught, will be thrown as 4, and a ball that was later caught, will be thrown as 5.
> Prop-filling will then be unambigous, except in the case of a multiplex catche! (2 or more catches at the same count)
> To treat multiplex catches, a solution could be:
> - to add a parameter to a limb, to specify the multiplex position
> or
> - treat multiplexes as catches/throws to additional limbs, that happen to be at the same place as another limb.
>
> My intuition is that if we can describe multiplexes, prop-filling can be done automatically.
Interesting thought, thank you.
> And we should design a way to describe multiplexes anyway... :-)
So just to be clear, we already have a way to describe multiplexes.
It's just two or more throws at the same time from the same hand, like this for [45]:
{ "time": 0, "duration": 4, "from": 0, "to": 0 },
{ "time": 0, "duration": 5, "from": 0, "to": 1 },
We can indeed define the order of the props inside a multiplex.
[54] would just have the lines swapped:
{ "time": 0, "duration": 5, "from": 0, "to": 1 },
{ "time": 0, "duration": 4, "from": 0, "to": 0 },
A deterministic ordering of props in catches can be done the same way:
use the order of the throws as well.
{ "time": 0, "duration": 4, "from": 0, "to": 0, "prop":0 }, # prop ids for illustration
{ "time": 1, "duration": 3, "from": 1, "to": 0, "prop":1 }, # would be filled in by code
{ "time": 4, "duration": 6, "from": 0, "to": 0 },
{ "time": 4, "duration": 5, "from": 0, "to": 1 },
Assuming the algorithm would do FIFO (first in, first out),
the 6 would be prop 0 as the throw of 4 would be processed/ordered first.
However, I may want to make them go out the opposite way to achieve some coloring
goal in the pattern.
> To treat multiplex catches, a solution could be:
> - to add a parameter to a limb, to specify the multiplex position
A limb can do many multiplexes in a pattern with different prop orderings in
each of them. This would limit what patterns we can express.
> or
> - treat multiplexes as catches/throws to additional limbs, that happen to be
at the same place as another limb.
If I understand correctly, this is like saying, I have two or more slots in my
hand. And instead of assigning a limb id to the hand, I assign a limb id to
every individual slot. The slots would then still need to be attached to a hand
limb id in order to define hand movements. Every slot can hold only one prop at
a time, which makes the prop assignment deterministic.
This is an interesting thought, and it has some physical analogies in that I have
different spots for balls or clubs in my hands. Those would correspond to the
slots I was talking about. I would even rearrange my props between these spots
when preparing to catch or throw something.
However, compared to our current model, it is a bit complicated to fix some rare
edge cases. If we're going to use something in this direction, it would probably
need to be implemented as an optional refinement (similar to the exact physical
throw/catch times).
I'm keeping this in mind while we're adding more pieces to the puzzle, but I'll
stick our current model for now.
Let's first clear out the juggler relabeling mess :)
Cheers
Christian
>> Many applications like causal diagram editors or jif generators won't care about
>> props and prop permutations at all. They should not need to specify them.
>> Luckily, they can be filled in by code.
>> If we include a few rules how this prop-filling code should behave, we can
>> probably arrive at deterministic prop ids.
>> "What reasons do we have to specifiy props in jif at all then?", you ask.
>> Well, if we have a lot of multiplexes, the prop-filling code might not
>> do what we want to express.
On 10.02.21 23:02, JaCo Stuifbergen wrote:
> I think that, in multiplexes, we should make a distinction between [45] and [54].
> The definition might be that in [45], the ball that was first caught, will be thrown as 4, and a ball that was later caught, will be thrown as 5.
> Prop-filling will then be unambigous, except in the case of a multiplex catche! (2 or more catches at the same count)
> To treat multiplex catches, a solution could be:
> - to add a parameter to a limb, to specify the multiplex position
> or
> - treat multiplexes as catches/throws to additional limbs, that happen to be at the same place as another limb.
>
> My intuition is that if we can describe multiplexes, prop-filling can be done automatically.
Interesting thought, thank you.
> And we should design a way to describe multiplexes anyway... :-)
So just to be clear, we already have a way to describe multiplexes.
It's just two or more throws at the same time from the same hand, like this for [45]:
{ "time": 0, "duration": 4, "from": 0, "to": 0 },
{ "time": 0, "duration": 5, "from": 0, "to": 1 },
We can indeed define the order of the props inside a multiplex.
[54] would just have the lines swapped:
{ "time": 0, "duration": 5, "from": 0, "to": 1 },
{ "time": 0, "duration": 4, "from": 0, "to": 0 },
A deterministic ordering of props in catches can be done the same way:
use the order of the throws as well.
{ "time": 0, "duration": 4, "from": 0, "to": 0, "prop":0 }, # prop ids for illustration
{ "time": 1, "duration": 3, "from": 1, "to": 0, "prop":1 }, # would be filled in by code
{ "time": 4, "duration": 6, "from": 0, "to": 0 },
{ "time": 4, "duration": 5, "from": 0, "to": 1 },
Assuming the algorithm would do FIFO (first in, first out),
the 6 would be prop 0 as the throw of 4 would be processed/ordered first.
However, I may want to make them go out the opposite way to achieve some coloring
goal in the pattern.
> To treat multiplex catches, a solution could be:
> - to add a parameter to a limb, to specify the multiplex position
A limb can do many multiplexes in a pattern with different prop orderings in
each of them. This would limit what patterns we can express.
> or
> - treat multiplexes as catches/throws to additional limbs, that happen to be
at the same place as another limb.
If I understand correctly, this is like saying, I have two or more slots in my
hand. And instead of assigning a limb id to the hand, I assign a limb id to
every individual slot. The slots would then still need to be attached to a hand
limb id in order to define hand movements. Every slot can hold only one prop at
a time, which makes the prop assignment deterministic.
This is an interesting thought, and it has some physical analogies in that I have
different spots for balls or clubs in my hands. Those would correspond to the
slots I was talking about. I would even rearrange my props between these spots
when preparing to catch or throw something.
However, compared to our current model, it is a bit complicated to fix some rare
edge cases. If we're going to use something in this direction, it would probably
need to be implemented as an optional refinement (similar to the exact physical
throw/catch times).
I'm keeping this in mind while we're adding more pieces to the puzzle, but I'll
stick our current model for now.
Let's first clear out the juggler relabeling mess :)
Cheers
Christian
JaCo Stuifbergen
Feb 12, 2021, 4:24:09 PM2/12/21
to juggling-interchange-format
Thanks Christian!
I overlooked that the current notation allows to specify multiplexes adequately.
Indeed, I was thinking of multiplex positions like slots in the hand, but I think that this destroys the notion of a multiplex.
After all, if someone were to catch a ball in the hand and another on the elbow, we wouldn't consider it a multiplex either.
So I am happy with the current notation (and I think that automatic prop-filling is possible with it).
Co Stuifbergen
=========================
in...@jacos.nl
www.jacos.nl
+31 6 13 02 44 69 (mobile)
Kloosterwei 102
2361 XN Warmond
the Netherlands
=========================
=========================
in...@jacos.nl
www.jacos.nl
+31 6 13 02 44 69 (mobile)
Kloosterwei 102
2361 XN Warmond
the Netherlands
=========================
--
You received this message because you are subscribed to the Google Groups "juggling-interchange-format" group.
To unsubscribe from this group and stop receiving emails from it, send an email to juggling-interchang...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/juggling-interchange-format/32b14ad2-db1d-7b44-f7d8-d055e5d26f8d%40helch.ch.
Reply all
Reply to author
Forward
0 new messages