I am developing a computer program that solves the Rubik's cube. It is not anything advanced nor fast. It solves the cube by the Friedrich method, using algorithms that I use in real life to solve the cube. Because of that, the output solving algorithm is quite a long one and I was wondering is there is a way to transform the output to an equivalent algorithm, but shorter. This might actually be impossible, but I think this is a question worth asking. For example here is a list of equivalent algorithms that orient the corners of the last layer of that cube state shown in the image.
L.E.: Friedrich splits the solve in 4 steps(cross, inserting corners and their corresponding edges(F2L), orienting the last layer(OLL) and permuting the last layer(PLL)). So far my program only solves the cross, and I am now beginning to code the algorithms for the second step(F2L). All the algorithms I find online for F2L, OLL and PLL are designed to be remembered and/or executed as easily and naturally as possible, so they are not necessarily the shortest ones. Using Kociemba's program I can find shorter algorithms equivalent to those used by humans only for PLL, where the entire cube stays the same except for the edges and corners of the last layer. This is because Kociemba only gives the algorithms that leads to complete solve of the cube(and only for PLL we need this solution). For F2L for example I don't know what configurations I should put the cube in in order to output the algorithm that only inserts the desired pair(corner and edge) in the correct place and doesn't care about the cubies in the last layer, or the cubies in the other corners(that are not solved yet). I hope that makes sense. I make this program for a project for my Algorithms course, first year in CS and the requirements are that it must solve any given state of the 3x3x3 cube and output the shortest solution. I know group theory can be used, but it is much more complex and requires more time than I was given to finish the project, so I thought that Friedrich would be easier to achieve.
So far my outputs an algorithm for solving the cross that averages at 10 moves with a maximum of 19 in half turn metric. The execution time varies from 0.02 to 0.03 seconds per cube. This data was obtained from running the program on 1500 randomly generated cube states.