Algorithm trainer for Lin CP always generates the same case

[bugybunny]

I’m not sure if that’s intended or a bug though :p

Go to the Algorithm trainer, select Lin corner permutation, select Even Oriented Corners for example and generate scrambles. I always get the one where the yellow and white edge swap directly + an adjacent swap on top. I would expect to get random edges (that can be solved with an even number of swaps).

This would be great to learn PLL+1.

[mikavilpas]

Hi, I think I know what you mean. It's been a while so it took me some time to remind myself that this was about again. ( ͡° ͜ʖ ͡°)

I don't remember this part that well, but I went over the code shortly in the morning, and it looks like I left that out consciously: comment. But what you are asking could be a new kind of algorithm set.

I think it's an okay idea, but unfortunately I am still feeling pain in my hands, and I've decided to stay out of non-work related programming until I feel better. So what I'm saying is that I might implement it at some later time.

[mikavilpas]

By the way, do you have the algorithms somewhere? I could maybe look into it on my coffee break at work.

[mikavilpas]

Oh, I should add that the actual algorithms don't have to be special or efficient. It's enough if they are able to solve the case. The actual scramble will be obfuscated so it can't be guessed that easily.

[bugybunny]

By the way, do you have the algorithms somewhere? I could maybe look into it on my coffee break at work.

https://docs.google.com/document/d/1sXODF-g3CowiUr1_brwyR2JpQsu6VYb-NKaYYTP1Sd8/edit?usp=sharing for example. But yeah as you said, they don‘t need to be efficient and also shouldn‘t be just the inverse, otherwise I will know which case I will get most likely.
Can you just generate scrambles with these situations like you do for the cubeshape trainer? That would be the best solution even if it‘s not efficient.

[mikavilpas]

cool, thanks.
I have a bunch of tests that I run for all algorithm sets. These seem to fail a couple of them. Could you make sure the algorithms are perfect (so a machine will be able to understand them)?

I had problems come up with the algs 27, 28 and 36. The tests say they could not be executed. The way they should work is, you should start with the puzzle solved, and do exactly the algorithm. If you detect any errors, I can fix them and the feature will probably work.

You can see my work here:
https://github.com/sp3ctum/squanmate/compare/feature/lin-pll+1-algset

[mikavilpas]

Can you just generate scrambles with these situations like you do for the cubeshape trainer? That would be the best solution even if it‘s not efficient.

I think this approach will be better. I can't remember if the other approach had a good distribution of randomness. And this is much faster for me to do quickly.

[bugybunny]

I'm without a Sq1 until at least Monday. I guess an alignment is wrong and the puzzle cannot be sliced? I would need a physical Sq1 to find the errors I guess.

I'll have a look on Monday or maybe I can write the creator of the doc to correct it.

[bugybunny]

Someone commented that 36 should be (4,3)/(-4,-1)/(1,-2)/(-1,-4)/(1,-2)/(3,3)/(-1,2)/(-2,1)/( - 1,-3). He said 27 and 28 should be fine.

[mikavilpas]

Never mind, I got it. The algorithms were missing a comma in the first rotation.

[mikavilpas]

Okay, the feature is now released. Please test it out, as I only made sure that the algorithms are generated correctly... I'm pretty confident that it will work, though :)
https://cdn.rawgit.com/sp3ctum/squanmate/6.10/resources/public/index.html#/

[bugybunny]

Thanks a lot, you are awesome! I hope to have time in the evening to test it.

[bugybunny]

Ok, I unfortunately didn’t have time (infection near my elbow and I have to wear a splint for a few days and cannot move my left arm <.<) yet but something I saw: the document is split up in different sets, grouped by which corners need to be swapped (the normal Lin CP case). Grouping these cases in squanmate and allow a user to select/deselect a whole set would be helpful.

I saw that you already have them grouped by comments in lin_pll_plus_1.cljs. I don’t have a suggestion for the UI however.

[mikavilpas]

Oh, sorry to hear that. Take care of yourself and no rush with this thing. I like the suggestion, but maybe I'll implement it at some later time.

…

On Sun, Nov 11, 2018, 18:25 Marco Syfrig ***@***.*** wrote: Ok, I unfortunately didn’t have time (infection near my elbow and I have to wear a splint for a few days and cannot move my left arm <.<) yet but something I saw: the document is split up in different sets, grouped by which corners need to be swapped (the normal Lin CP casse). Grouping these cases in squanmate and allow a user to select/deselect a whole set would be helpful. I saw that you already have them grouped by comments in lin_pll_plus_1.cljs. I don’t have a suggestion for the UI however. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#59 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASW99-mB0Uo3rhIqEoShLsDAIptfVpMks5uuE93gaJpZM4X6550> .

[bugybunny]

I finally started testing it and I noticed one more annoyance: the unsolved edge at the bottom layer should always be at DF. I would argue that’s where it will be in 99 % of the cases when you come to the PLL+1 stage in a solve.

[mikavilpas]

Yeah that's probably just the end rotation that every algorithm in the trainer has, unless I misunderstood you. We can keep this open for now.

…

On Mon, Nov 26, 2018, 21:01 Marco Syfrig ***@***.*** wrote: I finally started testing it and I noticed one more annoyance: the unsolved edge at the bottom layer should always be at DF. I would argue that’s where it will be in 99 % of the cases when you come to the PLL+1 stage in a solve. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#59 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASW92_mUpiaJd16G2GfnwQM_1mTxe3Oks5uzDpugaJpZM4X6550> .