4x4x4 FMC (computer and human) round 2

ch_ts said:

Welcome to 4x4x4 FMC round 2!

Time: May 15 to June 30 2015

Click to expand...

When you say June 30th, is this noon June 30th in Hawaii? Or some other specific time?

It's not a big deal probably but might as well get it right; I'd hate to submit my final
solution 20 hours after the contest ended.

OK, let's say June 30 11:59pm GMT officially, but unofficially I'll accept solutions until I check on July 1.

Results

These were incredible solutions in the computer division! Both rokicki and qq280833822 found very short solutions. Very impressive solutions! In the human division, cuBerBruce defends! Well, there were no challengers but I'm sure it would have been difficult to beat him anyway, as he was sub-80 in all his solutions.

Computer Division

rokicki: 36 (35) 36 (37) 36 => 108

qq280833822: (37) 37 37 37 (38) => 111

ch_ts: 50 (49) (1000) 1000 1000 => 2050

Human Division

cuBerBruce: (73) (79) 77 76 75 => 228

Writeup

Thanks for running the contest! I spent way too much time on it
but had a lot of fun. Here are my notes.

Two-phase solver for 4x4x4

My approach for this contest was to implement a two-phase solver
for the 4x4x4. The first phase finds optimal and suboptimal
reductions (move sequences that take the input position to the
subgroup (U, F, R, D, B, L)), and the second phase uses standard
3x3x3 optimal solvers to finish the solution. Only the first
phase is new work, so I will focus on that here.

I must open by saying this is not a practical 4x4x4 solver;
using a high-powered machine (16 cores) with a lot of memory
(256GB) running nearly non-stop for nearly two months, I was
able to directly find only 42 actual reduction solutions.
However, through the use of near-miss solves and derived
solves, I was able to generate more near-optimal reduction
solutions that helped me find shorter solutions.

Pruning Tables

My reduction solver used two large pruning tables, one for the
edges and one for the middles. Since each table was too
large to fit into memory, rather than using a subgroup indexing
approach, I instead used a hashing approach with collisions
to generate an inexact pruning table. I allocated four bits
per hash entry; the value in those four bits is always the
least value of all positions that hash to that value. Given a
maximum distance for hash table generation, I simply filled
each table with that distance plus one, then did an iterated
depth-first exploration from solved, hashing each position
solved and updating hash table entries along the way. For my
edge pruning table, I used 5GB of RAM, and for my middle
pruning table, I used 215GB of RAM. I explored edges out to
a distance of 10, and middles out to a distance of 10.
For both edges and middles, most entries of the hashtable
were unset by the search from solved to a depth of 10, so
for most random positions, the pruning table returned an
immediate lower bound on distance of 11.

For edges, if I had spent the time to complete a search
from solved of depth 11, I would have probably sped up the
program a fair bit; it would probably have taken about
four days to generate this table. In hindsight this
would probably have been wise; the search through depth
10 for edges only touched a total of 2.3B out of the 430B
hash table entries. I guess I was in just too much of a
hurry to get results. I may do this and see how performance
differs in the coming weeks; this may make the solver
significantly faster! Writing this at the end of the contest,
I'm disappointed I did not consider this earlier.

The hash function I used implicitly reduced the positions by
48 ways of symmetry. Also, the moves I considered were
restricted to keep a particular corner fixed, giving me an
additional reduction by a factor of 24. Details of the hash
function themselves are somewhat intricate and I would be
willing to write them up if anyone has interest.

My code is written to support the slice turn metric, block
turn metric, and outer block turn metric; I have focused on the
slice turn metric for this contest but am considering exploring
the other metrics as well.

The target subgroup for edges for my pruning table is that where
edges are matched and the total edge parity is even. (Note that
rotations and conjugation by rotations/mirroring does not change
the parity of the edge permutation.) The target "subgroup" for
middles was with each face a solid color (but not necessarily to
have the colors in a solved position). I put subgroup in
quotes because of course the middle positions do not form a
group because not all pieces are distinguishable.

Designing pruning tables is still somewhat more of an art than
a science. I considered generating one big pruning table that
combined edges and middles, but experiments showed that this
pruning table got too "wide" too quickly, and I could get better
average distances by using separate edge and middle pruning
tables. I did not fully implement and optimize a combined
pruning table so I do not have conclusive evidence that it would
be worse.

Initial Results

These are the initial results based on just using the simple
reduction solver and an optimal 3x3x3 solver with no additional
improvements. The input positions were as follows:

!: R2 F2 Rw' R D' Uw' L B' L' Rw2 R2 F Uw2 Fw F2 Rw2 B D B2 Rw' F2 Uw2
B' Rw R U Fw' Rw' U' Rw' B' D F2 U Fw' R2 B L2 Uw L2 U D R U2 Uw2
2: B' Fw' L' D F B2 Uw2 D2 R2 L Fw2 F R' Uw' Fw2 B2 Uw Rw2 F L R D U Rw
B Fw' R2 Rw2 L' D' B D' F' L2 Uw2 Rw F2 Rw2 F Fw2 U F' Rw' R U
3: Rw F' Rw2 L' Fw2 F2 B2 U' R' L Uw B' R' Rw2 B Fw L2 Rw' Uw2 B' L B2
Fw2 Rw' U Fw Rw2 B R' Uw2 R' B Uw2 B2 Fw2 F2 D' R' B2 U Rw F' R2 Rw2 L
4: B R F' D U' R' B2 D2 B' R B' D2 F' B L2 F' D2 F' U2 R2 Uw2 Rw2 L' B
U2 L' B2 Uw2 B' R' D2 B2 Uw Rw2 R2 D2 B2 U' Fw' Rw' B' F2 Uw U' R B2
U' R F2 U
5: F2 L2 B' U2 D2 R2 U2 F U F2 R B R2 D2 B D L' U Fw2 D Rw2 R Fw2 R
Uw2 F2 R2 D Rw2 D2 U' Fw F L' Fw2 Rw' Uw F' D2 Rw' B Uw2 B L B U' F2

For all positions but number 2, the optimal reduction was of length
19; for position 2, the optimal reduction was of length 20. (Surprisingly
position 2 is also the position we found the shortest solution for.)
An example optimal reduction for the moves is shown here:

1: 2R2 R B2 2U2 2F 2U 2B' 2R2 2U2 D' 2R2 2F' B' L 2F2 2D 2L2 L' 2F' (19*)
2: 2R2 2F 2L 2D' R' D' F' 2U' 2L' 2U' F' U 2B 2R' 2F U B 2R D 2L (20*)
3: 2F L2 R' 2D' F 2D' D L' 2F2 D 2L 2U' 2L' 2B B2 2R' U' D' 2F' (19*)
4: R' B2 U' 2B' R 2U2 U2 B R 2F' R' 2U 2R D2 2F2 U' 2B' B2 2U (19*)
5: 2R' F 2D' 2L2 2F' 2D 2R 2F2 U2 B2 2L2 L' 2F2 2D' R2 U' 2B D 2F' (19*)

The count of direct reductions we found (limited to those sequences
that do not end in a face turn):

We completed reduction search through a depth of 19, and finished
a fair fraction (maybe 30%?) of the search through depth 20.

We optimally solved all the positions remaining after reduction,
and listed the best results in the table above (the format is
the reduction length, a plus sign, the best 3x3x3 result,
an equals sign, and then the resulting best sum. We list the
best overall result in the last column. As you can see we
were able to solve all positions in 37 or fewer moves, and
three of them in only 36 moves.

The optimal reduction solutions show that four of the five
positions have an optimal reduction length of 19. This means
it is more likely than not that the median reduction length
over all 4x4x4 positions is 19.

This result gave us an average of median 3 of 36.3, and an
overall average of 36.4. But we can do better.

Near Misses

Not all positions that were obtained by solving the edges and
middles separately but simultaneously were actually reduction
solutions. For instance, in some solutions the colors for the
middles were properly paired (for instance, the white middle was
not opposite the yellow middle). In some solutions, the middles
were properly paired, but the middles were in a mirror image
position. Finally, in some solutions, the total parity of the
corners and the combined edges was odd. When one of these
conditions was true, I considered the solution a "near miss";
this happened most of the time (about 87% of the time). Early
on, I ignored these near misses as they could not be solved
by a 3x3x3 solver. But later I found a way to exploit them.

First-phase solves always came in pairs (or larger sets).
The final move of any first-phase solve was always a slice move
(if it was not a slice move, the position before the final move
would also have been a first-phase solve). When I say slice
move I mean inner slice; an outer slice move is just a face move.
If moving an inner slice brings the position to a phase one
solution, then moving the opposite inner slice the other way
*also* brought the position to a phase one solution.
There are additional ways that first-phase solves can come in
bursts but they are less frequent so we will not discuss them
further here.

Given how much CPU time I was spending to compute the phase one
solutions, I decided to see if there was a way I could obtain
additional related solutions directly from those solutions, so
I took each phase one solution, trimmed off all but the first
eight moves, and ran it through the phase one solver again.
This generated a surprising wealth of additional solutions at
distances only a bit more than the original. The additional
solutions were not the trivial ones generated by appending
face moves, but were usefully different ones that, in some
cases, generated better overall solution lengths. Further, not
just the actual reduction solves themselves but in addition
the near misses also generated actual phase one solutions that
were only slightly longer. Finally, the additional solutions
were generated in seconds, so this was an easy way to leverage
a solution or near miss into many additional phase one solutions
that let me do more probes into phase two.

This table has a count of the phase-1 solutions found
organized by input sequence and length:

With these additional probes we were able to find a
length 35 solution to input sequence 2 and a length 36
solution to input sequence 3.

Of course, with tens of thousands of candidate phase one
solutions, solving them all optimally with a 3x3x3 solver
would have taken a fair amount of CPU. But generally, once
an overall solution was known for the original 4x4x4
position, we no longer cared about longer solutions, so the
3x3x3 optimal solver could be instructed to only search to a
useful overall length, and give up if no such short solution
was found.

Let us deconstruct the two better solutions that were found
with this strategy. The length 35 solution to the second input
position was found as follows.

First, a length-20 reduction solution was found:

2R2 2F 2L 2D' R' D' F' 2U' 2L' 2U' F' U 2B 2R' 2F U B 2R D 2R

By trimming off two moves and running this through our reduction
solver again, we find the following reduction solution of length
22:

2R2 2F 2L 2D' R' D' F' 2U' 2L' 2U' F' U 2B 2R' 2F U B 2R D' L2 D2 2R

The phase one reduction is longer, but the 3x3x3 solution now is only
13 moves:

U L D R' F2 D' L2 F L F2 U' R B'

for a total of 35 moves.

For input 3, the process was as follows. We found the following
length-19 near-miss:

R' F' 2U' D' 2F2 2L2 2B 2L' F D 2R' B' L 2U2 2L2 2F 2D2 2L' 2U'

This near miss was rejected because of parity. But by trimming the
last seven moves and resolving with the reduction solver, we find the
following valid reduction of length 22:

R' F' 2U' D' 2F2 2L2 2B 2L' F D 2R' B' L2 R' 2U 2L 2F2 2R' 2F' 2R2 2F2 2L'

This has a 3x3x3 solution of only 14 moves, for a total of 36 moves:

L2 U' B2 D2 F2 R' D2 B2 D' F' U2 R' D' L2

Some questions remain that are worth exploring:

1. What is a good target subgroup for phase 1? I happened
to use one that ignored overall corner/edge parity
and middle color permutation, and it worked well, but
is there a larger subgroup that would provide more
opportunity to exploit near-misses for phase 2 probes?

2. Is there a better way to construct either separate or
combined hash functions for phase one search that
generates a higher overall depth, or that is faster
to compute?

3. What exactly is the relationship of all the solutions
generated by trimming and re-solving phase one
solutions and near-misses? Is there an alternative
or faster way to generate these that does not require
search?

4. Given the approximate nature of the pattern database,
what is the best way to compress this in order to
obtain higher average probe depth, without compromising
performance or random access?

Congratulations to Tom on his winning computer solutions!

Here are my explanations for my human solutions.

First, here is a summary of my solutions by phases:

Insertions for the 3x3x3 phases are counted against the 3x3x3 phase, regardless of where in the skeleton the insertion occurs.


In the spoiler, are my detailed explanations.

cuBerBruce said:

Here are my explanations for my human solutions ...

Click to expand...

I'm completely blown away by this. I can't believe you have such short human
solutions for these positions. I can't even fathom how you found such short
solutions for just the centers.

Congratulations!

rokicki said:

I'm completely blown away by this. I can't believe you have such short human
solutions for these positions. I can't even fathom how you found such short
solutions for just the centers.

Congratulations!

Click to expand...

Thanks.

I figured solutions in this metric should be comparable to OBTM solutions. My solutions are generally longer than my OBTM solutions on the earlier competition. I attribute this to not spending the same amount of time as the first competition.

I note that it was proved several years ago that 22 moves is an upper bound to solve centers in this metric. (Except for the fact that this proof did not consider OLL parity.)

Finding a good centers solution largely involved a lot of trial and error. Of course, you also want to avoid "OLL parity" in this step, so you want to complete the third center having made the correct parity of inner layer moves. It is also important to get a good solution here, as the other steps will need to be totally redone if you decide to change the centers solution.

Some other techniques I tried.

Try to preserve any paired up centers - 2 adjacent (not diagonally) center pieces of the same color. (But this can also end up adding too many moves.) Getting 3 pieces of the same color on a face can also be beneficial.

Using insertions.

Getting opposite-face colors on the same face.

After getting a centers solution, try changing the order of consecutive face moves. This does not get a shorter centers solution, but may allow you to get more edges paired up for free.

Using inserted moves.

For example, for scramble 4, the start:
2R R D 2B2 D 2B' F 2L' U2 2L R F L' 2U2 R' 2U' R B2 2U (19)

appears to require something like R' 2U R2 2U to finish, resulting in a 23-move solution.

2R R D 2B2 D 2B' F 2L' U2 2L R F L' 2U2 R' 2U' R B2 2U R' 2U R2 2U' (23)

But adding the move B at the beginning allows the ending to be changed to 2U R2 2U'.

This simplifies to:

B 2R R D 2B2 D 2B' F 2L' U2 2L R F L' 2U2 R' 2U' R B2 2U2 R2 2U' (22)

Thus, the inserted move allowed a net reduction of one move. Note that the back face after the scramble had two colors represented in the center pieces. These corresponded to the last two colors solved. Turning the back face had the "visible effect" of swapping two of the center pieces. Using the right "swap" allowed a more efficient ending.

Ha, I noticed in rokicki's writeup he stopped saying "I" and started saying "we" to mean "me and my machine"

In my opinion, cuBerBruce's solutions are especially strong in the edge-pairing step. I think I could match him on the centers and maybe in 3x3x3 (if I spend enough time), but not in edge-pairing. Dunno, it seems easy seeing his solutions...

ch_ts said:

In my opinion, cuBerBruce's solutions are especially strong in the edge-pairing step. I think I could match him on the centers and maybe in 3x3x3 (if I spend enough time), but not in edge-pairing. Dunno, it seems easy seeing his solutions...

Click to expand...

Of the 3 basic phases (centers, edge pairing, 3x3x3), I estimate edge pairing is where I spend the least amount of time.

Some basic techniques/principles I use in edge pairing:

1. Use any axis for "slicing." Choose the axis separately for each n-at-a-time pairing sub-step.

2. Try to find pairs that are already "set up" for pairing. In my solution for the 3rd scramble, I not only was able to get 2 dedges for "free" during centers solving, but I also was set up for immediate "slicing" into a 4-at-a-time pairing sub-step. In only 8 moves, I was "half done" with edge pairing. You need to look for these "lucky" situations.

3. Extending the preceding point, always look for setting up pairs (particularly in the front end) that can be set up in the least number of moves.

4. Try to get paired edges for "free" during centers solving as I mentioned in my previous post. If it takes on average 2.5-3 moves to do each pairing, getting 2 dedges for "free" saves about 5-6 moves during edge pairing.

5. 6-at-a-time pairing may not be all that great a strategy. The third pair on the front end always takes (at least) 3 moves to set up (unless you get cancellations), and you generally have 9 or more moves total (barring cancellations) for the three pairs on the back end (not counting the "slicing back").

6. On the front end, you generally have two choices for which edge pair to set up for the 2nd pair. The same holds for the third pair if you do 6-at-a-time pairing. Choose the one that can be set up most efficiently.

7. In speedsolving, you generally set up the pairs on the back end in a specific order. (You "store" the front end pairs in a specific order). In FMC you have no need to do these in a specific order once you know what needs to go where. This may help get cancellations or avoid bad 4-move setup cases.

8. Avoid 4-move setups for a single pair. Choose a different pair to set up or choose to do fewer "at a time" to avoid the bad case.

9. Of course, avoid PLL parity at the end of edge edge pairing. If you get to a point where you have two dedges left, the algorithm 2D' L' F U' L F' U 2D or its mirror (2D R F' U R' F 2D') will work (this of course assumes the unpaired edges are at FL and FR with the pairs horizontal, not diagonal).

10. Don't just do one edge pairing attempt. Do a few attempts and take the best one (or possibly one that leaves a good starting point for the 3x3x3 phase).

As for 3x3x3 solving, I am not very good at finding sub-30 solutions very quickly. I typically took several hours to find each sub-30 solution. Good FMCers these days seem to be usually able to come up with sub-30 solutions within an hour, and perhaps not just sub-30, but often down in the 24-27 range as well.

This is what I do (when not using cmowla's reduction method) :

Centers
1. Remove 2 opposite centers from 2 faces. Let's say white/yellow. Remove white/yellow from L and R faces, so they're on F, U, B, D.
2. Make 1x2 blocks stashing them in one slice (say 2L) when necessary.
3. Make 2x2 centers by merging the 1x2 blocks. Let's say I put them on U and D
4. 3rd and 4th centers. Let's say I'm doing green and red. Make 1x2 blocks alternating green/red/green/red on R, F, L, B. If I need to solve orientation parity, put the 1x2 blocks in a slice (say 2D slice) and do an extra 2U (or Uw). Then turn two of the blocks into the U slice, do 2U2 (or Uw2)
5. Do 5th and 6th centers.

Goals:
centers: 20 moves.
centers + edge pairing together: 50 moves.
3x3x3: 30 moves.

My congratulation too to the three contestants, 36/37 moves in the computer division on average and 76 moves in the human division are absolutely amazing!
I hope the three phase solver I am developing will give some solutions which are not too far away from 40 moves. Phase 1 which I consider the hardest already works, it puts the cube into a position which is generated by <U,R,D,L,F2,B2,2U2,2R2,2D2,2L2,2F2,2B2>. I did not encounter a position which needed more than 14 moves for this step. Phase 2 is on the way, it puts the cube into <U,R,D,L,F2,B2>. In phase 3 there is a 3x3x3 cube left with already fixed edge orientations which wil take about 17 moves to solve on average. We will see how suboptimal solutions contribute to better overall solutions with this approach.

I also would like to congratulate all contestants. The computer solution move-counts are breath-taking, and Bruce's human solution move-counts are very nice as well.

ch_ts said:

Ha, I noticed in rokicki's writeup he stopped saying "I" and started saying "we" to mean "me and my machine"

Click to expand...

I wish I could say we had been so clever! It's just poor writing.

I also want to correct a few things I have wrong in that writeup. The distance-10 positions in the middle
pruning table numbered 45B, not 4.5B, so extending the table to include distance-11 positions would
not have been useful (as almost all table entries would have been set to 11, so very few table entries
would have a value of 12).

There's a number of ways I can proceed from here. Perhaps the most natural is to simply use the
reduction solver to optimally find reductions for a larger set of random positions, and gather some
statistics on that distribution. Another is to try to determine what near-misses are most productive
in terms of generating actual reductions that are only slightly longer.

Certainly gaining more confidence in the "median of 19" solution length for reduction is worthwhile as
this sets a clear target for solvers that use reduction built out of more than one stage.

Herbert Kociemba said:

I hope the three phase solver I am developing will give some solutions which are not too far away from 40 moves. Phase 1 which I consider the hardest already works, it puts the cube into a position which is generated by <U,R,D,L,F2,B2,2U2,2R2,2D2,2L2,2F2,2B2>. I did not encounter a position which needed more than 14 moves for this step. Phase 2 is on the way, it puts the cube into <U,R,D,L,F2,B2>. In phase 3 there is a 3x3x3 cube left with already fixed edge orientations which wil take about 17 moves to solve on average. We will see how suboptimal solutions contribute to better overall solutions with this approach.

Click to expand...

My estimate is this will result in solutions about 42 moves. It's a guess (but not total guess).

One of the variations I tried does your 1st phase in 2 steps, and your 2nd phase in 2 steps also, and then puts the cube into <U,D,F,B,R2,L2>. For example, for scramble 3 I have for reduction:
U 2F2 R2 2B' F' 2U D2 2L' F L U 2R R2 B 2L
B' D2 B' 2U2 F2 2U2 2R2 F R2 2R2 U2 2L2 2F2 2R2 R2 U' 2L2
and then the cube is in <U,D,F,B,R2,L2>.
view

ch_ts said:

My estimate is this will result in solutions about 42 moves. It's a guess (but not total guess).

One of the variations I tried does your 1st phase in 2 steps, and your 2nd phase in 2 steps also, and then puts the cube into <U,D,F,B,R2,L2>. For example, for scramble 3 I have for reduction:
U 2F2 R2 2B' F' 2U D2 2L' F L U 2R R2 B 2L
B' D2 B' 2U2 F2 2U2 2R2 F R2 2R2 U2 2L2 2F2 2R2 R2 U' 2L2
and then the cube is in <U,D,F,B,R2,L2>.

Click to expand...

Did you use suboptimal solutions from phase1/2 to get shorter solutions in phase 3/4?

The search space of my phase 2 (your phase 3/4) is quite small and you could try to do this in one step. In phase 2 I use two coordinates: an "edge pairing" coordinate with a "raw" index from 0..12!/2, reduced by 16 symmetries the index runs from 0..14999139 and a center coordinate. I built the pruning table for "edge pairing" coordinate today and the maximum depth is 13 with an average of about 10-11 moves. So we have the preliminary result that edge pairing alone can always be done with 13 moves in phase 2.
The center coordinate for phase 2 should have 70*70*6 entries, but I have not implemented this coordinate yet.

I finished the coding of the phase 2 now too. The center coordinate for phase 2 has not 70*70*6 but 70*70*12 values btw. Without using suboptimal solutions, just taking the first solution of each phase I got the following for scramble 1:
3F 3U 2R2 3U 3u 3R2 3U 3F2 R 3U2 3f' 2U 3R .U L' F2 U 2B2 B2 2U2 D' 2F2 U L U' 2R2 .L' U' R' B2 L2 D L' U' L2 U L U D2 F2 D2 L2
The total length is 13+13+16=42. Using suboptimal solutions a < 40 move solution should be no problem.

Also 13/13/16 for scramble 4:
3f 3U2 R' 3r' 3F' 2U' F' R' U 2R F 3R2 3F.B2 U2 2L2 L 2D2 D B2 R' 2L2 2F2 B2 L 2U2.F2 L2 U2 D R2 D F2 R' L2 D2 B2 L2 F2 U' F2 R2

I tried if and how good a solution I get if applying the phase 1 and phase 2 solver to the single dedge flip. Using just the first solution which popped out for phase 1 and then applying phase2 solutions until the cube was compeletly solved I found the following 9+12=21 and move solution

2R U2 2R2 F2 U2 2R' U2 F2 2RU R2 2B2 R2 U 2R2 U' R2 2B2 R2 U 2R2

Another 9+11 solution is

2R U2 2R2 F2 U2 2R' U2 F2 2R' U 2F2 R2 2F2 U 2R2 U' 2F2 R2 2F2 U

Using suboptimal phase 1 solutions I found a 11+8 solution:

3u 2F' R2 3u2 2F' 3u2 R2 3u' 2R2 U2 2R'U' R2 U 2R2 U' R2 U' 2R2

... and a 11+7 solution:
2R F2 2R' F2 2R U2 2R2 F2 2R' F2 2R'2U2 F2 2R2 F2 U2 2R2 2U2

No I didn't try that... I think I may revisit my solver, there are some changes I'd like to make with it.

I let the dedge flip solver run over night and now found a 12 + 5 = 17 move solution in SSTM and STM for the single dedge flip

U2 3R' F2 3R U2 3R' U2 2R2 F2 3R U2 2RD2 F2 2L2 F2 D2

I hope this is quite remarkable because in https://www.speedsolving.com/wiki/index.php/4x4x4_Parity_Algorithms#One_Dedge_Flip I see only a single dedge flip algorithm which is 17 moves in STM but it is more in SSTM.

Herbert Kociemba said:

I let the dedge flip solver run over night and now found a 12 + 5 = 17 move solution in SSTM and STM for the single dedge flip

U2 3R' F2 3R U2 3R' U2 2R2 F2 3R U2 2RD2 F2 2L2 F2 D2

I hope this is quite remarkable because in https://www.speedsolving.com/wiki/index.php/4x4x4_Parity_Algorithms#One_Dedge_Flip I see only a single dedge flip algorithm which is 17 moves in STM but it is more in SSTM.

Click to expand...

Wow, only a 15-move reduction! That should be easy for my program; I should have
been able to find this with my new reduction solver fast enough.

I'm going to have to try running through a bunch of last-layer positions and see what
I can do. Is OBT or SST more interesting for this?

Congratulations, Herbert.