Sorry, an error occurred while loading the content.

## Re: 3^4 parity problems

Expand Messages
• 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
Message 1 of 25 , Oct 17, 2009
• 0 Attachment
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
• Klaus, The new version will actually allow for an infinite number of different puzzles but that set will not include the 16, 24, or 600 cell in the first
Message 2 of 25 , Oct 17, 2009
• 0 Attachment
Klaus,

The new version will actually allow for an infinite number of different
puzzles but that set will not include the 16, 24, or 600 cell in the
first version. ;-)
It will however include the 120 cell but without the needed piece-finder
included in Roice's specialized app. We definitely do plan to include
the piece finder as well as more puzzles because sometimes infinity is
not enough! The puzzle-generation code is Don's brain child and is
obviously an amazing piece of work. I'm sure that everyone will be quite
happy with this once we shake out the bugs. Actually it's fairly solid
now but so far we've only tested on Windows and haven't put it to
real-world use solving full scrambles. That's where you guys come in. :-)

Stay tuned!
-Melinda

Klaus wrote:
>
>
> [...]
>
> @ 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 ;-)
>
> __
• Hello, To solve problems with various scrambles, simply do what I was doing: just take scramble which was used to previous record! This way it will be
Message 3 of 25 , Oct 18, 2009
• 0 Attachment
Hello,

To solve problems with various scrambles, simply do what I was doing:
just take scramble which was used to previous record! This way it will
be legitimate "shortest solve" because based on the same ground state.
(I don't think that on 3^4 you can get something better from choosing
starting state, the cube is to complex. I was almost magical when I was
beating previous Rocie record with 334 twists and we were finishing
stages 2C, 3C and 4C varying only by 1 twist! and my final result was
333 twists). On 2^4 there is a little different story and I encourage
you to take record scramble and work on it.

On 3^4 I don't think that method which starts with 4C will give good
result. Believe me - I was there :). Algorithms which not move 4C's and
concerns only other pieces are to much twist consuming.

Method which I've used in order to break previous Roice solution (334
twists) was basicly "Roice solution" but with only using two algorithms
and a lot of thinking on preliminary moves to solve 3 or more pieces 3C
(very nasty alg which shuffles eight 3C but has only 4 twists) and 2
pieces of 4C at the same time in one algorithm. I must say it -> 300
twists is a boundary of such kind of approach. It just like Fridrich on
3^3 and 30 twists there. There are steps which you have to go through
(2C, 3C and 4C), not breaking what you build already and there is no way
to comprehend and deal with pieces (my preliminary moves was taking more
twists than algorithm.

My next try on Roice record in 3^4 will be Layer by Layer (ok, partly
layer) method :) and be sure I want my shortest 2^4 back as well :P

Congratulations on all new records and good luck with new tries!

All the best,
Remi

----------------------------------------------------------------------
Bezp³atne konto i limit do 100 tys. Otwierasz?
• Klaus- I think your idea of timing macro recording is a good idea to simplify the problem.  Good luck on your record attempts! -Levi ... From: Klaus
Message 4 of 25 , Oct 18, 2009
• 0 Attachment
 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 wrote:From: Klaus Subject: [MC4D] Re: 3^4 parity problemsTo: 4D_Cubing@yahoogroups.comDate: 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

• 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
Message 5 of 25 , Oct 18, 2009
• 0 Attachment
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@...>/* wrote:
>
>
> From: Klaus <klaus.weidinger@...>
> 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
>
>
>
• I am happy that my solution seems to be considered as a possible way to work around different styles of macro usage. However I don t understand why you think
Message 6 of 25 , Oct 19, 2009
• 0 Attachment
I am happy that my solution seems to be considered as a possible way to work around different styles of macro usage. However I don't understand why you think everyone has to be in the same place. Well, if you want to account for illegal "teamwork" this might be true. But
there will be almost always a way of cheating, even if it just consists of hacking the programme. Well, at least until someone builds a working model of a 4D cube.

If you think, using macros could still be an advantage with the use of a macro timer, you could just add some penalty time whenever a macro is executed. This could be some fixed amount like 10 seconds or just generally a certain percentage of the macro time, for example 5%. If you want to be really exact, you could even vary this percentage with the size of the puzzle. However, I admit there will likely never be a truely fair solution to this problem, despite just making two separate categories for macro and non-macro solves.

Another problem dealing with this issue is, that one could cheat by klicking on "define macro" and then work out a way of getting the next steps fast and then never execute this macro. By this one could gain an infinite amount of thinking time without the stopwatch running. There are different ways of working around this problem.

One of the easier ones could be to just let the cubers always define their macros on a solved cube. This could, however, not prevent that someone makes a screenshot of the cube and then clicks on "define macro".
Another way could be, that the penalty time (10 sec./5%) is not only added when the macro is executed, but also when it is defined. This, however, would not be strong enough to prevent this way of cheating and to just raise the penalty percentage would prevent serious macro usage at all.
If all of this does not help, you could even say that each macro has to be executed at least twice in every solve or otherwise the solve will not be accepted. I said "twice" on purpose because if you only need the macro once you could just do it by hand this one time. However, there will be a problem if you are not able to predict, whether you need it multiple times. Therefore you could also set this limitation to "at least on execution".

To get really safe you could of course combine these methods arbitraryly.

About the new grip based twisting system I can't judge yet, because I didn't have the chance to try it out, but you will have to correct all of the old records. And does the grip based system also support half turns around 2c-pieces?

Have a nice twist,
Klaus

--- In 4D_Cubing@yahoogroups.com, Melinda Green <melinda@...> wrote:
>
> 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
• Dear Melinda, With new version of MagicCube4D with different steering on 2^4 you should post a scramble which will be base for shortest solution for everybody.
Message 7 of 25 , Oct 19, 2009
• 0 Attachment
Dear Melinda,

With new version of MagicCube4D with different steering on 2^4 you
should post a scramble which will be base for shortest solution for
everybody. I think it will be easy to beat present shortest record on
2^4. You can even make it as a competition due to new version première :)

I must argue with seeing solving "corners" on 3^4 as 2^4 cube solve.
There are different methods to solve this two cubes. Some alg's concerns
middle layers. Solving stage 4C (after previous solving 2C and 3C
stages) on 3^4 has nothing to do with solving 2^4 cube due to avoiding
messing with solved pieces. (I think such try of using corners 3^4 as
the 2^4 solve will be visible due to mixing 3C pieces)

When it comes to Hyperspeedsolving I vote for:

->2^4 competition without macros
->3^4 with macros (No reasonable solve time without macros on 3^4 ->
1,5h is too much)

I was starting with 20 macros and at my best days I could reach time
18min 27sec. Sending solution will take at best around 15-30 seconds if
mail or communicator will be prepared, but still we won't get actual
time of solve. Interior timer is a nice idea. It's hard to decide what
to do with time during performing twists from macro: I always needed to
see what was going on the cube, so I've never used no-time macro.
Switching positions of colours makes my eyes (and brain) hurt:P

Different scenarios (there is no sense to treat solving cube with or
without macros or even from different scenarios below, there are just
different types of competition with different strategies, just like one
hand, classic 3x3, etc) :

a) everybody can have, lets say, 10 macros prepared before start; after
start one can build new macros (or not)

b) after start competitor should build set of macros from scratch and
it's up to him/her how many macros will be build (building macros
consumes competition time)

That's all. Good night for everybody. Hyper dreams,
Remigiusz

---------------------------------------------------------------
Zobacz jak pracuje sie na wysokosciach.
Kliknij >>> http://link.interia.pl/f2384
• Klaus, I think your basic suggestion for macro timing is great. I probably shouldn t have brought up my minor concerns because now it is leading to designing
Message 8 of 25 , Oct 19, 2009
• 0 Attachment
Klaus,

I think your basic suggestion for macro timing is great. I probably
shouldn't have brought up my minor concerns because now it is leading to
designing refinements which I think is a bit premature. If we start
holding speed cubing contests and if we implement your basic suggestion
and if we find that proves to be a disadvantage to macro or non-macro
users, then I'm sure we'll figure out the refinements that seem fair to
everyone.

I don't think we'd need to hold competitions in a single location in
order for it to be fair but it would certainly be the easiest way. I
agree with you that cheating will always be possible. I just feel a duty
to think about it and to take measures to discourage it. I don't see any
way to create any sort of official speed records that are produced
remotely but that shouldn't stop us from letting people claim their
private results. I also like the idea of holding informal races timed
only by the wall clock. I think that it makes good sense to include a
timer in MC4D that solvers can use as they like in order to more easily
measure and compare their personal, unofficial speeds.

This is probably a good point to announce our intention to set up a wiki
to let you guys maintain your own unofficial hall-of-fame for
accomplishments and records. I still intend to maintain the current
official list of solvers and shortest records for the 3^4, 4^4, and 5^4,
as well as the shortest 2^4; but it will simply be too much work for me
to do the same for the veritable zoo of new puzzles and sizes that are
about to become available. If anyone has suggestions for how to
administer and official HOF for these, please share your ideas. Until
then then this will simply have to be based on the honor system.

Regarding your question about allowing half turns in addition to quarter
turns: this is not a grip vs. sticker issue but it does involve the log
files. The existing product supports half turns internally but not in
the log file format. The new version will now support it in the log
files as well but not yet in the UI. I had experimented with the idea of
using the shift key to "double" the amount of twist you get when
clicking. That actually would work fine but now with all the new puzzles
it wouldn't seem right to support only doubling of twist angles when
some puzzles would benefit just as much from multiplying by 3, 4, 5,
etc. The problem is that we can't think of a good usable way to support
that in the UI. This will make more sense once you've had a chance to
play with the new puzzles a bit. We will then count on you guys to make
suggestions for how we might implement that and how to compare records
set before and after any such feature becomes available.

Regarding your question about correcting past records due to changing to
grip vs. sticker based log files: the only record that I think of that
might need to be corrected would be the shortest 2^4. Thinking now about
how to do that gives me an interesting thought about how to count twists
in general. Maybe any number of consecutive twists on a given face with
the same slice mask should only count as a single twist.

Fun stuff to think about!
-Melinda

Klaus wrote:
> I am happy that my solution seems to be considered as a possible way to work around different styles of macro usage. However I don't understand why you think everyone has to be in the same place. Well, if you want to account for illegal "teamwork" this might be true. But
> there will be almost always a way of cheating, even if it just consists of hacking the programme. Well, at least until someone builds a working model of a 4D cube.
>
> If you think, using macros could still be an advantage with the use of a macro timer, you could just add some penalty time whenever a macro is executed. This could be some fixed amount like 10 seconds or just generally a certain percentage of the macro time, for example 5%. If you want to be really exact, you could even vary this percentage with the size of the puzzle. However, I admit there will likely never be a truely fair solution to this problem, despite just making two separate categories for macro and non-macro solves.
>
> Another problem dealing with this issue is, that one could cheat by klicking on "define macro" and then work out a way of getting the next steps fast and then never execute this macro. By this one could gain an infinite amount of thinking time without the stopwatch running. There are different ways of working around this problem.
>
> One of the easier ones could be to just let the cubers always define their macros on a solved cube. This could, however, not prevent that someone makes a screenshot of the cube and then clicks on "define macro".
> Another way could be, that the penalty time (10 sec./5%) is not only added when the macro is executed, but also when it is defined. This, however, would not be strong enough to prevent this way of cheating and to just raise the penalty percentage would prevent serious macro usage at all.
> If all of this does not help, you could even say that each macro has to be executed at least twice in every solve or otherwise the solve will not be accepted. I said "twice" on purpose because if you only need the macro once you could just do it by hand this one time. However, there will be a problem if you are not able to predict, whether you need it multiple times. Therefore you could also set this limitation to "at least on execution".
>
> To get really safe you could of course combine these methods arbitraryly.
>
> About the new grip based twisting system I can't judge yet, because I didn't have the chance to try it out, but you will have to correct all of the old records. And does the grip based system also support half turns around 2c-pieces?
>
> Have a nice twist,
> Klaus
>
> --- In 4D_Cubing@yahoogroups.com, Melinda Green <melinda@...> wrote:
>
>> 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
>>
>
>
• Well, of course it s up to you in which way you try to use any of my suggestions. These were just thoughts about how to deal with problems that even might
Message 9 of 25 , Oct 20, 2009
• 0 Attachment
Well, of course it's up to you in which way you try to use any of my suggestions. These were just thoughts about how to deal with problems that even might never evolve. Even if you don't use any of them in the first version of the new programme I won't be mad at you because I'm really looking forward to seeing this new programm at work ;-) And additionally I'm no speedcuber so i doubt that I will take part in many of those competitions. I think I will rather stick to fewest move solving.
Btw: What is the name of the new programme, or is it still called MC4D?

> I don't think we'd need to hold competitions in a single location in
> order for it to be fair but it would certainly be the easiest way.

I don't think so. Well, perhaps it would be the easiest way to prevent cheating, but it would as well ensure low attendance. I don't now the 4D-cubing community very well, yet, but I think they are widely spread around the whole world and few would come from remote places.

> I agree with you that cheating will always be possible. I just feel a duty
> to think about it and to take measures to discourage it. I don't see any
> way to create any sort of official speed records that are produced
> remotely but that shouldn't stop us from letting people claim their
> private results.

Well, if you have some spare time ;-) and want to programme some web interface for user input and then run all the cubes on a central server it would be possible, but I think this is not really needed. (And of course one could hack the server ;-)

> I also like the idea of holding informal races timed
> only by the wall clock. I think that it makes good sense to include a
> timer in MC4D that solvers can use as they like in order to more easily
> measure and compare their personal, unofficial speeds.
>
> This is probably a good point to announce our intention to set up a wiki
> to let you guys maintain your own unofficial hall-of-fame for
> accomplishments and records. I still intend to maintain the current
> official list of solvers and shortest records for the 3^4, 4^4, and 5^4,
> as well as the shortest 2^4; but it will simply be too much work for me
> to do the same for the veritable zoo of new puzzles and sizes that are
> about to become available. If anyone has suggestions for how to
> administer and official HOF for these, please share your ideas. Until
> then then this will simply have to be based on the honor system.

Well, I can't even imagine this zoo of puzzles yet, so I can't come up with a way of maintaining the records. Well, of course I can think of the possible platonic polychora turned into puzzles, but what else can this programme do?

> Regarding your question about allowing half turns in addition to quarter
> turns: this is not a grip vs. sticker issue but it does involve the log
> files. The existing product supports half turns internally but not in
> the log file format. The new version will now support it in the log
> files as well but not yet in the UI. I had experimented with the idea of
> using the shift key to "double" the amount of twist you get when
> clicking. That actually would work fine but now with all the new puzzles
> it wouldn't seem right to support only doubling of twist angles when
> some puzzles would benefit just as much from multiplying by 3, 4, 5,
> etc. The problem is that we can't think of a good usable way to support
> that in the UI. This will make more sense once you've had a chance to
> play with the new puzzles a bit. We will then count on you guys to make
> suggestions for how we might implement that and how to compare records
> set before and after any such feature becomes available.
>
> Regarding your question about correcting past records due to changing to
> grip vs. sticker based log files: the only record that I think of that
> might need to be corrected would be the shortest 2^4. Thinking now about
> how to do that gives me an interesting thought about how to count twists
> in general. Maybe any number of consecutive twists on a given face with
> the same slice mask should only count as a single twist.

That is exactly what I meant. If you turn one side on a normal rubiks it is (generally) considered as one turn and this should hold true on every other derivation of it. Of course you are right that turns of one face with different slice masks should be considered separate turns. I didn't even think of this but it perhaps feels most intuitive.
And from what you wrote above I conclude that I still don't understand how a grip based system will behave. I thought it would be somehow like klicking on a cubie and then drag-and-drop it to the desired position, which would automatically include every imaginable way of turning a single face on any kind of puzzle.

Another request from me is to enable the usage of numpad keys to control the slice mask and making the numpad "," or the "0" equal to the current function of Ctrl.

Have a nice twist,
Klaus
• Remi, It s great to hear from you again! Some of our newer members may not know that Remi is one of the more passionate boosters of our little puzzle so I m
Message 10 of 25 , Oct 20, 2009
• 0 Attachment
Remi,

It's great to hear from you again! Some of our newer members may not
know that Remi is one of the more passionate boosters of our little
puzzle so I'm very happy that the recent news has piqued his interest.

I like your suggestions for holding speed contests. Would you like to
run some? I know that you would enjoy competing but I'm afraid that you
will crush everyone else, and you certainly have more experience with
speed contests than most of us. Still, I stand by my offer to run a
contest if at least three people sign up. Either way, I think we should
wait until the public release of version 4 so that we can shake out
unknown bugs and any problems with different platforms. Anytime after
that is fine with me, including immediately after as part of a product
launch.

-Melinda

thesamer@... wrote:
> Dear Melinda,
>
> With new version of MagicCube4D with different steering on 2^4 you
> should post a scramble which will be base for shortest solution for
> everybody. I think it will be easy to beat present shortest record on
> 2^4. You can even make it as a competition due to new version première :)
>
> I must argue with seeing solving "corners" on 3^4 as 2^4 cube solve.
> There are different methods to solve this two cubes. Some alg's concerns
> middle layers. Solving stage 4C (after previous solving 2C and 3C
> stages) on 3^4 has nothing to do with solving 2^4 cube due to avoiding
> messing with solved pieces. (I think such try of using corners 3^4 as
> the 2^4 solve will be visible due to mixing 3C pieces)
>
>
>
> When it comes to Hyperspeedsolving I vote for:
>
> ->2^4 competition without macros
> ->3^4 with macros (No reasonable solve time without macros on 3^4 ->
> 1,5h is too much)
>
> I was starting with 20 macros and at my best days I could reach time
> 18min 27sec. Sending solution will take at best around 15-30 seconds if
> mail or communicator will be prepared, but still we won't get actual
> time of solve. Interior timer is a nice idea. It's hard to decide what
> to do with time during performing twists from macro: I always needed to
> see what was going on the cube, so I've never used no-time macro.
> Switching positions of colours makes my eyes (and brain) hurt:P
>
> Different scenarios (there is no sense to treat solving cube with or
> without macros or even from different scenarios below, there are just
> different types of competition with different strategies, just like one
> hand, classic 3x3, etc) :
>
> a) everybody can have, lets say, 10 macros prepared before start; after
> start one can build new macros (or not)
>
> b) after start competitor should build set of macros from scratch and
> it's up to him/her how many macros will be build (building macros
> consumes competition time)
>
> That's all. Good night for everybody. Hyper dreams,
> Remigiusz
>
• ... Yes. We briefly discussed the idea of renaming it because it s not not restricted to cubes, but MagicPolytope4D just didn t have the same ring to it. :-)
Message 11 of 25 , Oct 20, 2009
• 0 Attachment
Klaus wrote:
> Well, of course it's up to you in which way you try to use any of my suggestions. These were just thoughts about how to deal with problems that even might never evolve. Even if you don't use any of them in the first version of the new programme I won't be mad at you because I'm really looking forward to seeing this new programm at work ;-) And additionally I'm no speedcuber so i doubt that I will take part in many of those competitions. I think I will rather stick to fewest move solving.
> Btw: What is the name of the new programme, or is it still called MC4D?
>

Yes. We briefly discussed the idea of renaming it because it's not not
restricted to cubes, but MagicPolytope4D just didn't have the same ring
to it. :-) We can still rename it later, or even with the public
release if anyone here as a great suggestion. Aside from the obvious
name recognition that MC4D now has, another benefit is that the cubic
name and default puzzle will make the idea easier to swallow for new
people. I don't know if my experience is any indication, but even the
smartest people that I tell about the puzzle are scared enough of a 4D
cube. When I then tell them that it supports more than just cube, they
usually start looking around for doors. :-)

>> I don't think we'd need to hold competitions in a single location in
>> order for it to be fair but it would certainly be the easiest way.
>>
>
> I don't think so. Well, perhaps it would be the easiest way to prevent cheating, but it would as well ensure low attendance. I don't now the 4D-cubing community very well, yet, but I think they are widely spread around the whole world and few would come from remote places.
>

Oh, I'm sure. I should have been more clear that i only meant that it
would be the easiest way to prevent cheating, if not the most practical.

>> I agree with you that cheating will always be possible. I just feel a duty
>> to think about it and to take measures to discourage it. I don't see any
>> way to create any sort of official speed records that are produced
>> remotely but that shouldn't stop us from letting people claim their
>> private results.
>>
>
> Well, if you have some spare time ;-) and want to programme some web interface for user input and then run all the cubes on a central server it would be possible, but I think this is not really needed. (And of course one could hack the server ;-)
>

They wouldn't have to hack the server to cheat. Team and computer
assistance would still be possible, even if it would eliminate some
other opportunities for cheating.

>> I also like the idea of holding informal races timed
>> only by the wall clock. I think that it makes good sense to include a
>> timer in MC4D that solvers can use as they like in order to more easily
>> measure and compare their personal, unofficial speeds.
>>
>> This is probably a good point to announce our intention to set up a wiki
>> to let you guys maintain your own unofficial hall-of-fame for
>> accomplishments and records. I still intend to maintain the current
>> official list of solvers and shortest records for the 3^4, 4^4, and 5^4,
>> as well as the shortest 2^4; but it will simply be too much work for me
>> to do the same for the veritable zoo of new puzzles and sizes that are
>> about to become available. If anyone has suggestions for how to
>> administer and official HOF for these, please share your ideas. Until
>> then then this will simply have to be based on the honor system.
>>
>
> Well, I can't even imagine this zoo of puzzles yet, so I can't come up with a way of maintaining the records. Well, of course I can think of the possible platonic polychora turned into puzzles, but what else can this programme do?
>

Probably best to just show you. ;-)

I'm going to pre-announce now our intent to make the beta version
available in the late afternoon this Friday. We anticipate that this may
set off a mini gold rush of attempt to claim "firsts" records, so this
timing will hopefully give the most people the chance to plan to spend
some serious time with it this weekend.

I apologize to those people that would like to do this but for which
this is too short notice. For any of you who plan to jump at this
opportunity, I recommend that you try to reserve access to a Windows
machine, and in particular, one using Sun's version of the Java VM. Oh,
and the latest Java version 1.6 will be required, so you should make
sure that your machine is up-to-date. Go to java.com to make sure and
upgrade if not. If there turn out to be any problems that keep any of
you from getting in early on all the fun, I apologize in advance. We
can't predict what problems might crop up, and if that happens, I can't
see any way to not give an advantage to beta testers lucky enough to not
experience them. I hope that nobody holds such problems against us. Just
remember that those of you dedicated enough to be reading this are
getting a special opportunity that other members and the rest of the
puzzling community will not have.

>> Regarding your question about allowing half turns in addition to quarter
>> turns: this is not a grip vs. sticker issue but it does involve the log
>> files. The existing product supports half turns internally but not in
>> the log file format. The new version will now support it in the log
>> files as well but not yet in the UI. I had experimented with the idea of
>> using the shift key to "double" the amount of twist you get when
>> clicking. That actually would work fine but now with all the new puzzles
>> it wouldn't seem right to support only doubling of twist angles when
>> some puzzles would benefit just as much from multiplying by 3, 4, 5,
>> etc. The problem is that we can't think of a good usable way to support
>> that in the UI. This will make more sense once you've had a chance to
>> play with the new puzzles a bit. We will then count on you guys to make
>> suggestions for how we might implement that and how to compare records
>> set before and after any such feature becomes available.
>>
>> Regarding your question about correcting past records due to changing to
>> grip vs. sticker based log files: the only record that I think of that
>> might need to be corrected would be the shortest 2^4. Thinking now about
>> how to do that gives me an interesting thought about how to count twists
>> in general. Maybe any number of consecutive twists on a given face with
>> the same slice mask should only count as a single twist.
>>
>
> That is exactly what I meant. If you turn one side on a normal rubiks it is (generally) considered as one turn and this should hold true on every other derivation of it. Of course you are right that turns of one face with different slice masks should be considered separate turns. I didn't even think of this but it perhaps feels most intuitive.
> And from what you wrote above I conclude that I still don't understand how a grip based system will behave. I thought it would be somehow like klicking on a cubie and then drag-and-drop it to the desired position, which would automatically include every imaginable way of turning a single face on any kind of puzzle.
>

I like that idea, Klaus! Or at least the gesture that I imagine wouldn't
require clicking on any particular cubie but rather would let you
continuously drag a whole face around and have it snap into the closest
orientation when you release the mouse. Ideally you'd be able to do this
several times in a row to the same face and have it count as a single
twist so long as the same slicemask is used each time.

This is not, however, what I meant about the new version being
grip-based. The main difference is in the log files. The user interface
will be the same as before, so most users will not notice the difference
except that your new macros will apply to all sizes of the puzzle type
you defined them on.

> Another request from me is to enable the usage of numpad keys to control the slice mask and making the numpad "," or the "0" equal to the current function of Ctrl.

Great suggestions! Note that in addition to being able to record your
own records, there will also be an issue tracking system that you can
use to report bugs, request features, and to vote on the bugs and
features that you would most like to see addressed, so I encourage you
to add your favorite suggestions there. In the meantime I suggest that
you brush up on your algorithms and puzzle manipulation skills, clear
your weekend calendar as much as you can, and stock up on coffee because
for better or worse this could turn out to be one exciting weekend!

Good luck to everyone!!
-Melinda
• ... Well, if a nice name comes to my mind I will post it here. ... It at least wouldn t be possible to get you some extra time or just send in faked log files.
Message 12 of 25 , Oct 21, 2009
• 0 Attachment
> Yes. We briefly discussed the idea of renaming it because it's not not
> restricted to cubes, but MagicPolytope4D just didn't have the same ring
> to it. :-) We can still rename it later, or even with the public
> release if anyone here as a great suggestion. Aside from the obvious
> name recognition that MC4D now has, another benefit is that the cubic
> name and default puzzle will make the idea easier to swallow for new
> people. I don't know if my experience is any indication, but even the
> smartest people that I tell about the puzzle are scared enough of a 4D
> cube. When I then tell them that it supports more than just cube, they
> usually start looking around for doors. :-)

Well, if a nice name comes to my mind I will post it here.

> [...]
> They wouldn't have to hack the server to cheat. Team and computer
> assistance would still be possible, even if it would eliminate some
> other opportunities for cheating.

It at least wouldn't be possible to get you some extra time or just send in faked log files. But, teamwork would still be possible and I think this is impossible to avoid unless everybody is in the same place.

> > Well, I can't even imagine this zoo of puzzles yet, so I can't
> > come up with a way of maintaining the records. Well, of course I
> > can think of the possible platonic polychora turned into puzzles,
> > but what else can this programme do?

> Probably best to just show you. ;-)

Yeah, probably ;-)

> I'm going to pre-announce now our intent to make the beta version
> available in the late afternoon this Friday. We anticipate that this may
> set off a mini gold rush of attempt to claim "firsts" records, so this
> timing will hopefully give the most people the chance to plan to spend
> some serious time with it this weekend.

I'm afraid I have a physics exam on tuesday and so I will spend most of my weekend with learning. But perhaps I'll try to get the 2^4 solved first, because this should not afford too much time.

btw: Do you release it on the old website and where are we supposed to send our log-files to? Does the address remain unchanged?

> >> [...] Maybe any number of consecutive twists on a given face with
> >> the same slice mask should only count as a single twist.

> > That is exactly what I meant. [...]
> > And from what you wrote above I conclude that I still don't
> > understand how a grip based system will behave. I thought it
> > would be somehow like klicking on a cubie and then drag-and-drop
> > it to the desired position, which would automatically include
> > every imaginable way of turning a single face on any kind of
> > puzzle.

> I like that idea, Klaus! Or at least the gesture that I imagine wouldn't
> require clicking on any particular cubie but rather would let you
> continuously drag a whole face around and have it snap into the closest
> orientation when you release the mouse. Ideally you'd be able to do this
> several times in a row to the same face and have it count as a single
> twist so long as the same slicemask is used each time.

You would not even need to do this several times in a row because with drag and drop you can reach every position (of one face) in one move.

> This is not, however, what I meant about the new version being
> grip-based. The main difference is in the log files. The user interface
> will be the same as before, so most users will not notice the difference
> except that your new macros will apply to all sizes of the puzzle type
> you defined them on.

Well, then I perhaps won't notice a change at all ;-) But for every macro-user this will perhaps be a real aid.

Have a nice twist,
Klaus
• ... The locations for the download, solution wiki, and issue tracking will be given in tomorrow s announcement. Once the worst bugs are squished and we have a
Message 13 of 25 , Oct 22, 2009
• 0 Attachment
Klaus wrote:
> [...]
>> I'm going to pre-announce now our intent to make the beta version
>> available in the late afternoon this Friday. We anticipate that this may
>> set off a mini gold rush of attempt to claim "firsts" records, so this
>> timing will hopefully give the most people the chance to plan to spend
>> some serious time with it this weekend.
>>
>
> I'm afraid I have a physics exam on tuesday and so I will spend most of my weekend with learning. But perhaps I'll try to get the 2^4 solved first, because this should not afford too much time.
>
> btw: Do you release it on the old website and where are we supposed to send our log-files to? Does the address remain unchanged?
>

The locations for the download, solution wiki, and issue tracking will
be given in tomorrow's announcement. Once the worst bugs are squished
and we have a version that seems solid enough for everyone, we will
create the official 4.0 release and I will add those links to the main
MC4D page. Until then, you will be the only people who are being told
about it.

Good luck with your 2^4 solution!

>> I like that idea, Klaus! Or at least the gesture that I imagine wouldn't
>> require clicking on any particular cubie but rather would let you
>> continuously drag a whole face around and have it snap into the closest
>> orientation when you release the mouse. Ideally you'd be able to do this
>> several times in a row to the same face and have it count as a single
>> twist so long as the same slicemask is used each time.
>>
>
> You would not even need to do this several times in a row because with drag and drop you can reach every position (of one face) in one move.
>

You might realize after dropping it that it's not in the right
orientation, so I wouldn't want to make you have to undo it and then try
to get it right in a single twist. The program should concatenate any
compatible consecutive twists into a single one for you.

23 hours and counting!!
-Melinda
• Hi everyone, I finally found some time to continue with my 3^4 solve and now another unexpected parity occured. I have posted a screenshot of it to the
Message 14 of 25 , Nov 14 9:24 AM
• 0 Attachment
Hi everyone,

I finally found some time to continue with my 3^4 solve and now another unexpected parity occured. I have posted a screenshot of it to the gallery. It is the second image in the album "parity problems".
If anyone knows how to solve this, please tell me.

btw: my current turn count is 391, so I didn't manage to come close enough to Roice's record for having a chance to break it. With another parity sequence aplied, it won't even be possible to stay below 400. However, I hope I will by chance find a way to optimize the second step of my 3-step solution, which took the most twists this time.

Have a nice twist,
Klaus
Your message has been successfully submitted and would be delivered to recipients shortly.