Message #704

From: Klaus <klaus.weidinger@yahoo.com>
Subject: Re: 3^4 parity problems
Date: Sat, 17 Oct 2009 20:01:31 -0000

Hello everyone,

recently I do not have very much time and therefore my current solve doesn’t proceed very fast, but I think in about one or two weeks I will find some time to finish it.

@ matthew:
Well, I think my approach to solving the corners is very efficient with about 54 moves (I think there will be a way of working around the parity, however a very time consuming one), but on a 2^4 this will take a lot more turns, because you can only perform twists equivalent to turning around a 2c-piece on a 3^4. Therefore, if you use the same method for the same scramble of the corners on a 3^4 and a 2^4 it will take more turns on a 2^4 and I’m not sure if the method is good enough to break the record.

@ Melinda:
I really am looking forward to the new puzzles as well. Will there be a 16-cell and a 24-cell available? It would really amaze me if you even put in the effort to implement a 600-cell, however I’m not sure if anyone would have the time to solve this ;-)

@ Levi:
I think you’re right with most of what you have said. One can’t compare speed solutions using macros to those achieved "bare-handed" (as David Vanderschel called it once) if one is measuring the real time used. But I think I’ve come up with a very convenient solution to get them comparable:
If the programme would stop the clock while one is setting up the macro, but measure the time used for this, it could add this amount of time to the clock every time the macro is executed.
Perhaps the overall time for the solve would be less with the use of macros, but this would only affect the solving time very little (if you used exactly the same turn sequence for solving).
This would also prevent the development of too many different speed solving categories.

To your thoughts about computer aided solutions I’m completely on your side. There is really no way of comparing them to human work. However it would be possible to introduce a category for fewest moves solutions achieved by computers, which could especially appeal to some of the programmers within this group and would perhaps help to find out somethig about the upper and lower bounds for fewest move solutions.

Have a nice twist,
Klaus