josef.jelinek
Member
Hey, thanks for the feedback.
This version is still quite early alpha and I expect you will find more bugs than I can for me to fix it.
The transition between the two phases is not expected to repeat turns of the same side, but there are some problems which I need to fix and I had to relax the limitation of redundant turns between the phases (the implementation actually uses finite automaton to prune the turns that may be already tried to depth 4, which is quite a boost considering standard approach of limiting the same face turning again and fitting it with all these wide, slice, cube turns that the program now supports.. there is just too much ambiguity now in short turn sequences to use anything simpler). It should work ok when the two phases' turn sequences are linked properly.
Regarding programming languages and their efficiency... I really do not much care anymore... C++ would get you nothing in this case, since JVM now optimizes and inlines the main solver functions and loops even better (suited to the exact processor it runs on), but that means nothing, because vast majority of time is spent on accessing the main memory, since used tables are not small and accesses are scattered and not cache-able. I could have implemented that in Lisp (clojure 1.3 for native arrays) and it would be the same speed. Well in Python it would be significantly slower though.
In the last example "F F" is output as the solver uses just the specified turns and does not know about F2 at that moment, but it is just limitation of the output representation in this console UI, which was just done very fast to allow testing before integrating with more sophisticated UI.
This version is still quite early alpha and I expect you will find more bugs than I can for me to fix it.
The transition between the two phases is not expected to repeat turns of the same side, but there are some problems which I need to fix and I had to relax the limitation of redundant turns between the phases (the implementation actually uses finite automaton to prune the turns that may be already tried to depth 4, which is quite a boost considering standard approach of limiting the same face turning again and fitting it with all these wide, slice, cube turns that the program now supports.. there is just too much ambiguity now in short turn sequences to use anything simpler). It should work ok when the two phases' turn sequences are linked properly.
Regarding programming languages and their efficiency... I really do not much care anymore... C++ would get you nothing in this case, since JVM now optimizes and inlines the main solver functions and loops even better (suited to the exact processor it runs on), but that means nothing, because vast majority of time is spent on accessing the main memory, since used tables are not small and accesses are scattered and not cache-able. I could have implemented that in Lisp (clojure 1.3 for native arrays) and it would be the same speed. Well in Python it would be significantly slower though.
In the last example "F F" is output as the solver uses just the specified turns and does not know about F2 at that moment, but it is just limitation of the output representation in this console UI, which was just done very fast to allow testing before integrating with more sophisticated UI.
