# --



## TheCubeMaster (Feb 24, 2014)

--


----------



## Methuselah96 (Feb 24, 2014)

Maybe you should check this out: http://www.speedsolving.com/forum/s...bing-training-that-yields-systematic-progress. It is very similar to what you're doing here. But it looks nice. gj.


----------



## DAoliHVAR (Feb 24, 2014)

wow cool thing
i think it would be much more accurate if it were avg of 12 for each of those but that maybe difficult so i'm not complaining


----------



## ChickenWrap (Feb 25, 2014)

This is beautiful.


----------



## TDM (Feb 26, 2014)

I like it! Just a few suggestions:
Ao12 is better than Ao5; luck can affect an Ao5 too much.
A sup-2 cross should not be green for sub-15 solvers.
There's nothing for timing cross+1: that's my weakest point in my solves and there's no way you can tell from just timing cross, OLL, PLL and the entire solve whether there is any pause between cross and the first pair.


----------



## TDM (Mar 2, 2014)

TheCubeMaster said:


> I am glad that you like it and thank you for the suggestions, however the transition from cross to 1st pair can be calculated using the time it takes you to solve your first pair and cross time (the first pair is calculated by taking your f2l avg and dividing it by 4, as there are 4 pairs in f2l) I admit, this may not be 100% accurate but it is certainly very close and I will try to make it more accurate in future. Thank you for your opinion and advice.


Yeah, the time for the first pair will almost always be different to the time for the next four pairs, which is why you can't just divide by four. It will be "very close" for some people, but for me I can pause for up to three seconds, making it very inaccurate.

[offtopic]Funnily enough, I think where I pause most at any point in any event is after finishing the final cross edge on 4x4, which is usually a lot more than 3 seconds. I suck at whatever happens after the cross [/offtopic]


----------



## pipkiksass (Mar 3, 2014)

TheCubeMaster said:


> *the transition* from cross to 1st pair can be calculated using the time it takes you to solve your first pair and cross time (the first pair is calculated by taking your f2l avg and dividing it by 4, as there are 4 pairs in f2l)



This is just totally wrong, sorry. Firstly this isn't the time for the transition, it's the time for cross + 1. Secondly, you aren't using "f2l avg", as I'll discuss in a minute.

Apologies if some of this sounds negative - all of these points are meant as constructive criticism. I'd be more than happy to help you update this spreadsheet so that it actually allows an analysis of a CFOP solve. Here goes:

1 - your "est f2l average" is just average solve time minus cross, OLL and PLL. This is not accurate or realistic - you are not factoring in recognition at any stage. This artificially inflates the "est f2l average", which here represents "everything but cross execution, OLL and PLL execution". Perhaps you could estimate this correctly by factoring in samples of OLL and PLL recognition times, but the formula used here is meaningless. The best way to address this would be to time OLL, PLL, OLL + recognition, PLL + recognition, and thereby establish an average of these recog times, which could also be deducted from the average solve time in order to more accurately establish the overall f2l time. I.e. "est f2l average" should be [solve average] - ([cross average] + [OLL recognition average] + [OLL average] + [PLL recognition average] + [PLL average]).

2 - your "cross and first pair time" is just the cross average plus "est f2l average" (which, as discussed in point 1, is meaningless) divided by 4. Why not just allow the users to time cross + first pair, and give an accurate figure, rather than a cross average plus 1/4 of a meaningless number? As TDM says, this would be better calculated using a separate timed interval, as f2l pair 1 is generally slower for a lot of CFOP solvers, and doesn't represent 25% of 'average' f2l by a long stretch.

3 - "est first pair recog time" and "est pair average insertion" - I'd love to know how you're calculating these. As (QED) the "est f2l average" figure is meaningless, anything derrived from this figure is equally meaningless.

4 - What on earth is going on with the baseline solves and analysis? I'm told (with a 16.73 cube average) my "est f2l tps" are 0.55 with an "est f2l average" of 7.31. This means I'm solving f2l in 4.02 moves. GO ME!!! Think there may be an error in this formula? A commonly quoted stat is that an efficient CFOP solve should be c.60 moves for cross + f2l. If you factor in an average cross of 7 MOVES, this should be c.53 divided by the "est f2l average" (again, currently meaningless). 

5 - I've tried to puzzle out the "idealised" values, but no joy - how can my idealised f2l average be 11.52? This is 68.86% of my overall average as entered into the spreadsheet, and doesn't include cross. F2l alone should be nowhere NEAR 70% of my solve. I'm pretty sure this formula is just wrong.

I think there is merit in what you're doing, but I think a lot needs to change:

My first suggestion is that you change the protection settings to allow users to select but not modify the content of password-protected cells. This would allow users to understand your formulae, and to feed back as to how these formulae can be improved.

My second suggestion would be to time OLL and PLL plus recognition, and subtract OLL/PLL averages to allow you to accurately factor in recognition times.

My third suggestion would be to time cross + 1, to allow you to accurately ascertain the length of the cross > f2l transition.

My fourth suggestion (in line with TDM) would be to allow Ao12s, to give more accurate data samples.

My fifth suggestion would be to make the validated data areas relevant to the individual user by allowing them to enter a 'target time', and show validation relative to this. I.e. if my 'target time' was 16 seconds, the spreadsheet would validate based on the 'ideal' splits for 16 seconds, and perhaps show 17 seconds, 15 seconds and 14 seconds as the other 3 columns. I'm not overly convinced that 4 columns are necessary. Target time, target time +1, target time -1 would be much better. All 'idealised' times would be relative to this target time. 

Just a thought. If you fancy sending me an unprotected copy of the sheet, I'd be happy to illustrate.


----------



## mark49152 (Mar 3, 2014)

Pip is correct (about everything except the move count for cross + F2L, which is more like 35).

However, I would recommend looking at what has been done before and trying to extend or improve it, rather than reinventing the wheel. Search on "systematic practice". You will find a spreadsheet made by speedpicker that already does a better job of CFOP solve analysis. Study that carefully, and you might see how you can contribute by adding something new and useful.


----------



## Methuselah96 (Mar 4, 2014)

mark49152 said:


> Pip is correct (about everything except the move count for cross + F2L, which is more like 35).
> 
> However, I would recommend looking at what has been done before and trying to extend or improve it, rather than reinventing the wheel. Search on "systematic practice". You will find a spreadsheet made by speedpicker that already does a better job of CFOP solve analysis. Study that carefully, and you might see how you can contribute by adding something new and useful.



Yes, I think speedpicker's is better, but his has a few shortcomings as well. Such as estimating OLL from PLL TPS.


----------



## jeff081692 (Mar 4, 2014)

Personally just the knowledge of 38% for LL can tell me exactly where I stand if I do LL scrambles. What I would like is something where you can input your average for a specific OLL/PLL case and it gives you back all the OLL and PLL in order of which is furthest from it's ideal percentage. That way you know exactly which algs you should drill more at all times.

Actually a LL timer that remembers your previous data would be amazing for that since it can be set up like Anki where it periodically makes sure each alg stays at a certain level for recognition and execution and can give you detailed feedback.


----------



## Methuselah96 (Mar 4, 2014)

jeff081692 said:


> Personally just the knowledge of 38% for LL can tell me exactly where I stand if I do LL scrambles. What I would like is something where you can input your average for a specific OLL/PLL case and it gives you back all the OLL and PLL in order of which is furthest from it's ideal percentage. That way you know exactly which algs you should drill more at all times.
> 
> Actually a LL timer that remembers your previous data would be amazing for that since it can be set up like Anki where it periodically makes sure each alg stays at a certain level for recognition and execution and can give you detailed feedback.



A year ago I was working on basically this as an add-on to Prisma for speedpicker. I almost finished the PLL part of it and then got busy doing other stuff. It is on my to-do list but a lot of other things come first.


----------



## jeff081692 (Mar 4, 2014)

I see. I should try to download Prisma again since I stopped using it when the spacebar wouldn't activate the timer.


----------



## pipkiksass (Mar 4, 2014)

I'm working on a spreadsheet which will provide more accurate averages of each step. 

Baaaaasically, you perform the following:

12 crosses
12 cross + 1
12 1st F2L pair (w. inspection)
12 complete F2L (w. inspection - cross solved)
12 OLL (w. inspection)
12 OLL (without inspection)
12 PLL (w. inspection)
12 PLL (without inspection)

This will provide splits for the following steps:

1 - Cross
2 - Transition to F2L
3 - F2L
4 - OLL recog
5 - OLL
6 - PLL recog
7 - PLL

And measure these against Speedpicker's idealised relative proportions for a CFOP solve. 

It will also provide TPS estimates based on 35 turns for full F2L (7 for cross and 28 for F2L), but allow you to override the move counts if you think you have inefficient cross or F2L. It will base LL TPS estimates on averages of common OLL/PLL movecounts.

You can enter your 'target' time (for example mine is 18s), and three columns are shown to show your progress for your target time, and 1s either side (i.e. 17/18/19s in my case). These show your averages, along with how much they need to be improved (or not, as the case may be). This also works with TPS. 

This should allow you to measure which of the above 7 steps you need to focus on. For example if my PLL average and TPS are better than they need to be for 18s, and also better than they need to be for 17s, this would be a good indicator that I don't need to drill PLLs until I'm looking to be sub-16.

Any thoughts? Should have something to publish later tonight or tomorrow.


----------



## jeff081692 (Mar 4, 2014)

I like it. It would actually solve my problem where I did a lot of F2L with inspection and cross solved but when I did full F2L solves it was extremely far off than my potential given the splits for F2L pairs and cross individually. Chances are the transition to F2L are a bigger difference than my F2L itself but I would never know how much of a difference. (I guess doing cross+1 would tell me) but I like that you include pretty much every possible thing broken down.


----------



## pipkiksass (Mar 4, 2014)

View attachment pips kikass solve analyser.xlsx.zip

Right - here's a first draft. It's not protected in any way, so you can look at the formulae and see how it works. It's also not been tested, but the formulae should work. On the final version, I'll protect the formulae once I'm happy with them. Also, I assume that the ideal recognition time is zero. I guess this could be optimistic!

All you have to do is complete the times on the Cross, OLL and PLL sheets, the 'totals' sheet should autocomplete. I've not added PLL or OLL TPS yet, that will take 30 seconds tomorrow.

Also I can't get conditional formatting to work on the Totals sheet, which is odd. I only have a mac at home, and no Office, so can't tweak it till tomorrow.

If anyone fancies taking a look and giving some feedback, feel free.


----------



## jeff081692 (Mar 4, 2014)

I haven't gotten a chance to do any solves yet but from what I can tell the ideal stuff is accurate and I like how much easier it is to test out different goals to see where you stand instead of doing it by hand all the time.

Edit: so one thing I would change is when inserting times, to make it show to 2 decimal places all the time so it is easier to read down the list. For example 2.50 instead of 2.5 would line up the numbers nicely by decimal point.

Edit 2: So I got 1.81 for cross, 3.88 for cross+1, .86 for one F2L pair, and 6.17 for F2L pairs. But it says my average pause after cross is 3.02 I think it should be more like 1.21? that would be cross+1 - (cross + F2L pair)
But that is one of the things you mentioned about conditional formatting I guess.


----------



## TDM (Mar 7, 2014)

TheCubeMaster said:


> 1 - Estimated F2L Average. This is not calculated from avg solve minus oll, pll & cross.
> It is more about taking the proportions of your solve (including cross, oll and pll), allow me to explain.
> 
> Let's say a scrambled cube was an apple and it took me 7 big bites to eat all of the apple, or in this case solve the scrambled cube.
> ...


You're assuming that each step of Cross, each slot, OLL and PLL take the same time. They don't.


> 3 - 1st Pair Recognition Time + Average Pair Insertion Speed. Let's start with the 1st pair recog, this is calculated using the f2l, cross and first pair times. It is accurate and does not need to be modified in future, I am very confident it is not only useful but also very accurate, because the f2l avg is (NOT!) meaningless as I demonstrated in point #1.


Your F2L average is meaningless. It isn't 4/7 of the total solve, and the first pair is not 1/7th of the solve. You can't predict the first pair because the first pair is always different to the other pairs.


----------



## TheCubeMaster (Mar 7, 2014)

TDM said:


> You're assuming that each step of Cross, each slot, OLL and PLL take the same time. They don't.
> 
> Your F2L average is meaningless. It isn't 4/7 of the total solve, and the first pair is not 1/7th of the solve. You can't predict the first pair because the first pair is always different to the other pairs.



You're right, but the difference would be barely anything (maybe 2.47 prediction and 2.77 actual) and the analyser doesn't just "guess", it works out proportions using a broad range of specific functions to break down your solve.


----------



## TDM (Mar 7, 2014)

TheCubeMaster said:


> You're right, but the difference would be barely anything (maybe 2.47 prediction and 2.77 actual)


Maybe for some people, but not for me and not for many others. My first pair recog is so poor that this would provide a very inaccurate value for my cross+1 (I'd guess my F2L is something like 2 for cross, 4 for first pair and then that leaves 1.3s for the other pairs. This is only an estimate, but it's almost certainly close to what I actually average). You can't assume that everyone is similar, because for this step they aren't.


----------



## pipkiksass (Mar 8, 2014)

Oh dear, you went there. 

Firstly, this is a community forum. Communities are all about sharing. Why hide your formulae? I published a spreadsheet which actually does what it's supposed to. And didn't lock it. That's because my formulae actually work. 

Secondly, I was genuinely trying to be constructive, but since you took the criticism so badly and insist on vehemently defending formulae which clearly don't work, I thought I'd take a closer look. **unlocks spreadsheet** 



TheCubeMaster said:


> 1 - Estimated F2L Average. *This is not calculated from avg solve minus oll, pll & cross*.


Yes, that's precisely what it is. Your formula is "=C44-(C61+C11)". Why lie?



TheCubeMaster said:


> It is more about taking the proportions of your solve (including cross, oll and pll), allow me to explain...
> **EXPLANATION**
> *Although it seems like simply taking away*, it is not. It analyses the proportions and calculates the result from those proportions.


It does seem like "simply taking away", doesn't it? You can't claim that something analyses data when it is just performing a basic mathematical operation. That attracts attention to it, leading Excel superusers to unlock your spreadsheet and expose you. 



TheCubeMaster said:


> 2 - Cross & 1st Pair


TDM has covered this, but I'll restate for the record - cross + 1st pair is not the same as cross + 1/4 of F2L time. There's a significant transition to consider.



TheCubeMaster said:


> Let's start with the 1st pair recog... I am very confident it is not only useful but also very accurate


Yes, let's!

You add cross + 1/4 of F2L, then in the next formula subtract the cross time from this number!! You could have just used C55, rather than C57. Anyway, I digress...

Other than that basic error, this formula is utter BS. You take the estimated time per pair. You then take the time for 4 F2L pairs only (no cross) and subtract the time for cross + first pair (=3 pairs minus cross!) You then divide this number by three, and subtract it from the estimated first pair time. 

If this formula delivers "accurate" results, it's purely by luck! This formula is, to all intents and purposes, a random number generator.



TheCubeMaster said:


> As for the avg pair insertion, this too is derived from the same times and is also accurate using the formula that calculates it.


Nope. Once again, you subtract cross + 1 from F2L without cross, then divide this nonsense number by 3. 



TheCubeMaster said:


> 4 - As for baseline + analysis. There is no error with the formula


Yes, there is. Your baseline solve formula takes full solve time, subtracts LL, subtracts cross... then adds LL back on! Notice anything missing? Like the cross time? Why subtract a number just to add it back on? Why not just use "=C44"?



TheCubeMaster said:


> and I have *NO IDEA!!* how you got an f2l tps of 0.55 with an f2l avg of 7.31!


You have no idea? Cool, let me explain it to you. Your formula doesn't look at TPS. It takes the time for solving 4 F2L pairs and divides it by the time taken to solve cross + *5 F2L pairs* (=C51/(C57+C51)). What the value of this number is is anyone's guess!

To calculate F2L TPS, you need to take the number of moves taken for F2L, and divide by the time taken to solve F2L. Most people agree that reasonably efficient CFOP F2L takes c.35 moves, of which c.7 are cross. So =28/C51 would actually give a sensible result. In my case 3.83 TPS. 



TheCubeMaster said:


> If you take a look at "Sheet2" which contains some examples of random data entry, you would see that the f2l tps is 0.71 and f2l avg is 23.68, this means it takes 17 moves (approx) to solve f2l. I think that makes a bit more sense! Are you sure it wasn't something like a typing mistake or miscalculation??


No, it was your formula. 

Firstly, there is no way you (or anyone else) are solving F2L in 17 moves. 

Secondly, you will always get a number below 1 for this value, as you will always be dividing a number by a bigger number (4 F2L pairs < 5 F2L pairs + cross). A formula that always calculates F2L TPS as a number that is always less than one is not accurate. Plug Faz's solve breakdowns in from a Brest reconstruction. You'll get roughly 0.6 TPS. This is not Faz's F2L TPS, which is closer to 12.



TheCubeMaster said:


> It has calculated that your f2l took up 68.6% of your solve, maybe f2l isn't your strong point.


LMAO!!!! 7.31 F2L out of an 18.5 second solve is _not_ 68.6%. It's not even 40%. How can you possibly expect this argument to hold any water?



TheCubeMaster said:


> It is not right of you to accuse the analyser by taking a guess of whether it's accurate or inaccurate, as I can certainly tell you it is accurate.


No, it's not. And I'm not guessing. 



TheCubeMaster said:


> Recognition times can be calculated fine as they are using a comprehensive data analysis function.


No, they aren't.



TheCubeMaster said:


> I'd rather the user not be able to see the formulas used, because they could easily just copy them and make there own analyser from my hard work.



I've made a better spreadsheet already. It took an hour, and I shared it. Because we're a community, and communities share. 



TheCubeMaster said:


> Thank you for your "constructive criticism" on my analyser


No worries



TheCubeMaster said:


> I really do think you're getting the wrong impression about how some of the mathematical techniques and data handling is carried out.


I disagree. But what do I know?


----------



## ChickenWrap (Mar 8, 2014)

Well, I love your spreadsheet. Only complaint is maybe they should be an average of 12? Not a huge deal though. The calculated F2l time for me is actually within .5-1 seconds for me on average, so I think it is fairly accurate for me. Thanks for the awesome tool!!


----------

