Message #708

From: Melinda Green <melinda@superliminal.com>
Subject: Re: [MC4D] Re: 3^4 parity problems
Date: Sun, 18 Oct 2009 14:52:46 -0700

I also think it is a clever solution. I’ve added it to our feature wish
list along with the idea of a solution timer which will be rather easy
to add. Of course to guard against cheating it seems like we’d need to
have everyone in the same place whereas speed solving without such an
equalizer can be done by distributing a shared scramble and seeing who
can post the first solution.

One thing that worries me a little is that either way we might be
forcing people to use macros in order to stay competitive. This may be
true even with Klaus’ macro timer because the solver only needs to
concentrate really hard at the beginning in order to perform the
algorithm as fast as possible once and then take advantage of that speed
every time they apply it, whereas a person solving without macros will
be penalized whenever they make a mistake or simply perform it more
slowly when they start getting tired. This might not apply to the 2^4
where the solutions might become so fast that the advantage will go to
the non macro users. At the minimum I will plan to add a solution timer
while we think some more about Klaus’ fascinating refinement.

And speaking of the 2^4, I should probably give you a heads-up regarding
the new version which may affect the shortest records. Twists in the new
versions are "grip" based rather than sticker based. One nice
side-effect of this change is that it allows macros created for a puzzle
of one size to be used on other sizes as well. That will provide one way
in which you will be able to apply your 3^4 macros to the 2^4 that
include twists that the UI currently does not offer directly on the 2^4.
There’s even another more subtle way this affects you which I hesitate
to say but I aught to disclose because some people will figure it out
anyway. The fact is that you could perform your shortest solution to
just the corners of the 3^4 (with or without macros) and then change
your log file to declare the puzzle to be a complete solution to the
2^4. I would not consider this to be cheating because I see it as more
of a problem that the UI does not currently give you a way to get at all
the grips of that puzzle. For this and other reasons, I don’t like the
2^4 very much but obviously lots of you do and you therefore deserve to
know about these things so that you can discuss and decide what you
think is fair and how the various records and competitions should be
handled.

-Melinda

Levi Wegner wrote:
>
>
> Klaus-
>
> I think your idea of timing macro recording is a good idea to simplify
> the problem.
>
> Good luck on your record attempts!
>
> -Levi
>
>
>
> — On *Sat, 10/17/09, Klaus /<klaus.weidinger@yahoo.com>/* wrote:
>
>
> From: Klaus <klaus.weidinger@yahoo.com>
> Subject: [MC4D] Re: 3^4 parity problems
> To: 4D_Cubing@yahoogroups.com
> Date: Saturday, October 17, 2009, 10:01 AM
>
>
>
> 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
>
>
>