Challenge Accepted... Challenge Met
Posted on May 26, 2025 at 03:23:50 AM by Craig G
Extreme Tech Talk Advisory - wise to skip.
With jai-alai theory, there's a little problem. When somebody posts some study or figures, how do you know they are valid? What is there to test against?
In this case, I see some number, 43,187,908, representing the total number of unique points sequences leading to a win in spec 9 games. Sans playoffs.
Well, I could go back to my original assembly code from years go, try to decipher it, and run it again.
Here's what ChatGPT says about assembly code:
Maintainability - Low — very cryptic, even to the original author
Debugging ease - Very difficult — register-level sleuthing
So do I really wanna burn my last few working neurons on such a tough task that is of interest to virtually nobody? Nope. And guess what, if there was an error in the original code, I'll just be repeating it.
OTOH, I do like the challenge of independently deriving that number, and possible verifying it, with a radically different technique.
So here goes.
My coolest design for the rotation and scores is like this.
Intel introduced a very interesting CPU instruction in 2006.
PSHUFB - we could think of it as P-SHUF-B, because the meaning is parallel shuffle (of) bytes. This instruction might as well have been specifically designed for jai-alai.
There are some extra registers known as XMM, which are 128 bits wide. They can also be used as 2 64-bits regs. Or 4 32-bit regs. Or 8 16-bits ones, or finally, what jai-alai loves, 16 8-bit values. Think about it. 8 posts + 8 scores = sixteen values.
We can set up an XMM reg like this { 1, 2, 3, 4, 5, 6, 7, 8, 0, 0, 0, 0, 0, 0, 0, 0 }, representing the rotation and scores at the start of a game.
The wonderful PSHUFB instruction allows us to use a 'mask' to shuffle (relocate) those 16 values any which-way we desire. So, yes, server wins, we shuffle this way, receiver wins , we shuffle the other way. A special trick I use is to shuffle so as to keep the post order and scores positionally in synch. This works well because the server or winner of the previous point is always going to be at byte 0, while the score to be updated and tested is always at byte 8.
So, assuming we created the required s_wins and r_wins shuffle masks, the code for the main loop of the game before playoffs might look like this:
while (true)
{
bool server_wins = get_random_bit(); // your RNG source
state = _mm_shuffle_epi8(state, server_wins ? server_wins_mask : server_loses_mask);
state = _mm_add_epi8(state, pt_value == 1 ? point_1 : point_2);
pt_ctr++;
if (pt_ctr >= 7) pt_value = 2;
if(_mm_extract_epi8(state, 8) >= 7)
break;
}
Basically, we are rotating the queue and updating the scores with just two stinking instructions. How ya gonna beat that?
Bottom line is that I used a design like this (but not the random part) to rediscover the number of Spec 9 pathways to victory and they once again add up to 43,187,908.
8 2
9 6
10 24
11 96
12 256
13 502
14 974
15 1856
16 3508
17 7704
18 21168
19 50908
20 81228
21 130850
22 209554
23 337158
24 569294
25 1174184
26 2272028
27 2728818
28 3119718
29 3608772
30 4085578
31 4703526
32 6386584
33 7325042
34 5050882
35 1131632
36 186056
Total 43,187,908
Tiger's Jai-Alai Chalk Talk
