Thread: "3^4 parity problems"

Hi everyone,

I'm currently trying to do the 3^4 in as few twists as possible and I think=
this could get a really good try. But at the moment I'm stuck with some co=
nstellation that I could solve, but which would take about 40 twists which =
would really worsen the result. So I'm looking for a shorter solution to th=
e folling problem:

I'm doing corners first, so I'm only concerned about the 4c-pieces. I've al=
ready solved 12 of the 16 corners and the rest of them (arranged in a squar=
e) is already oriented but the have to be rotated 180=B0. That means I need=
to twist half of the pieces on one face around 180=B0.
If you don't understand what I mean, I've added an image to the photo secti=
on. Just disregard all but the 4c-pieces and you get what I mean.

I hope you can help me with this problem because otherwise I won't get a go=
od turn count with this cube and I'll have to try another shuffle which is =
very time consuming.

Have a nice twist,
Klaus

I certainly know how you feel, I had the same problem doing a fewest moves =
solve on the 2^4. I could not find a very short solution for it (relative =
to the required solve length) so I did trial and error until I chanced upon=
a solution without the problem. If you are interested, I have just create=
d a save file with a 22 move solution (the best I can manage I think) which=
I will now attempt to upload to the site for you to find.

I intend to try a fewest move solve on the 3^4 and 4^4 eventually, after se=
tting the records on the other two puzzles, but for now I wish you good luc=
k! :)

Happy hypercubing,
Matthew

--- In 4D_Cubing@yahoogroups.com, "Klaus" wrote:
>
> Hi everyone,
>=20
> I'm currently trying to do the 3^4 in as few twists as possible and I thi=
nk this could get a really good try. But at the moment I'm stuck with some =
constellation that I could solve, but which would take about 40 twists whic=
h would really worsen the result. So I'm looking for a shorter solution to =
the folling problem:
>=20
> I'm doing corners first, so I'm only concerned about the 4c-pieces. I've =
already solved 12 of the 16 corners and the rest of them (arranged in a squ=
are) is already oriented but the have to be rotated 180=B0. That means I ne=
ed to twist half of the pieces on one face around 180=B0.
> If you don't understand what I mean, I've added an image to the photo sec=
tion. Just disregard all but the 4c-pieces and you get what I mean.
>=20
> I hope you can help me with this problem because otherwise I won't get a =
good turn count with this cube and I'll have to try another shuffle which i=
s very time consuming.
>=20
> Have a nice twist,
> Klaus
>

Thanks a lot. That is way better than my solution. I'll use this
and hope that I will not encounter any further problems during the rest of =
the solve.

Have a nice twist,
Klaus

--- In 4D_Cubing@yahoogroups.com, "matthewsheerin" wrote=
:
>
> I certainly know how you feel, I had the same problem doing a fewest move=
s solve on the 2^4. I could not find a very short solution for it (relativ=
e to the required solve length) so I did trial and error until I chanced up=
on a solution without the problem. If you are interested, I have just crea=
ted a save file with a 22 move solution (the best I can manage I think) whi=
ch I will now attempt to upload to the site for you to find.
>=20
> I intend to try a fewest move solve on the 3^4 and 4^4 eventually, after =
setting the records on the other two puzzles, but for now I wish you good l=
uck! :)
>=20
> Happy hypercubing,
> Matthew
>=20
> --- In 4D_Cubing@yahoogroups.com, "Klaus" wrote:
> >
> > Hi everyone,
> >=20
> > I'm currently trying to do the 3^4 in as few twists as possible and I t=
hink this could get a really good try. But at the moment I'm stuck with som=
e constellation that I could solve, but which would take about 40 twists wh=
ich would really worsen the result. So I'm looking for a shorter solution t=
o the folling problem:
> >=20
> > I'm doing corners first, so I'm only concerned about the 4c-pieces. I'v=
e already solved 12 of the 16 corners and the rest of them (arranged in a s=
quare) is already oriented but the have to be rotated 180=B0. That means I =
need to twist half of the pieces on one face around 180=B0.
> > If you don't understand what I mean, I've added an image to the photo s=
ection. Just disregard all but the 4c-pieces and you get what I mean.
> >=20
> > I hope you can help me with this problem because otherwise I won't get =
a good turn count with this cube and I'll have to try another shuffle which=
is very time consuming.
> >=20
> > Have a nice twist,
> > Klaus
> >
>

This brings up a question that I've been struggling with and have yet to
make up my mind about which is whether it should be considered to be
fair for people to use trial-and-error to find starting configurations
that happen to avoid particular problems leading to shortest solutions.
We decided that it made sense to use standard scrambles in speed solving
but I don't think we've ever addressed the problem for shortest
solutions. Opinions?

On a lighter note, here's a video of what must be the world's fastest
solution of the 1x1x1:
http://www.youtube.com/watch?v=eYf1nKTr7ZQ
0.13 seconds! Wow!!

-Melinda

matthewsheerin wrote:
>
>
> I certainly know how you feel, I had the same problem doing a fewest
> moves solve on the 2^4. I could not find a very short solution for it
> (relative to the required solve length) so I did trial and error until
> I chanced upon a solution without the problem. If you are interested,
> I have just created a save file with a 22 move solution (the best I
> can manage I think) which I will now attempt to upload to the site for
> you to find.
>
> I intend to try a fewest move solve on the 3^4 and 4^4 eventually,
> after setting the records on the other two puzzles, but for now I wish
> you good luck! :)
>
> Happy hypercubing,
> Matthew
>
>

In the same way that fewest moves competitors can have attempts with differ=
ent scrambles by attending several competitions, I believe that trying a fe=
w different scrambles for these 4D puzzles is fair play.

And just to clarify, I used trial and error from a certain save point I had=
created just before the problem with the corners which was discussed arose=
. I then had a situation where I could spend several days working on a 2^3=
(that's just how my solution worked) fewest moves solve to get few moves a=
nd no parity. I could also backtrack a little and solve differently to obt=
ain a different 2^3 scramble when I was too annoyed by the one I had. It w=
as made harder by the fact I have never practiced fewest moves solves in 3D=
!

It occurred to me to use an online solve program to aid this step, but I th=
ought that would certainly be cheating and I would not be able to live with=
myself if I set a record in that fashion. The alternative I chose was a r=
ather tedious week's work ...

I would be interested to find out other people's opinions on this question =
though, so thanks to Melinda for bringing it up :)

Happy hypercubing
Matthew

--- In 4D_Cubing@yahoogroups.com, Melinda Green wrote:
>
> This brings up a question that I've been struggling with and have yet to=
=20
> make up my mind about which is whether it should be considered to be=20
> fair for people to use trial-and-error to find starting configurations=20
> that happen to avoid particular problems leading to shortest solutions.=20
> We decided that it made sense to use standard scrambles in speed solving=
=20
> but I don't think we've ever addressed the problem for shortest=20
> solutions. Opinions?
>=20
> On a lighter note, here's a video of what must be the world's fastest=20
> solution of the 1x1x1:
> http://www.youtube.com/watch?v=3DeYf1nKTr7ZQ
> 0.13 seconds! Wow!!
>=20
> -Melinda
>=20
> matthewsheerin wrote:
> >=20=20
> >
> > I certainly know how you feel, I had the same problem doing a fewest=20
> > moves solve on the 2^4. I could not find a very short solution for it=20
> > (relative to the required solve length) so I did trial and error until=
=20
> > I chanced upon a solution without the problem. If you are interested,=20
> > I have just created a save file with a 22 move solution (the best I=20
> > can manage I think) which I will now attempt to upload to the site for=
=20
> > you to find.
> >
> > I intend to try a fewest move solve on the 3^4 and 4^4 eventually,=20
> > after setting the records on the other two puzzles, but for now I wish=
=20
> > you good luck! :)
> >
> > Happy hypercubing,
> > Matthew
> >
> >
>

Hi everyone,

I also thought about this but for my system this doesn't really make sense =
because it just takes to long to get to a position from where you can decid=
e if this problem/parity occurs (Well it was only 50 turns but to optimize =
them took me about 3 days). I will however try to find a way to predict it =
earlier and to work around this awkward situation.

But even if you decided that trial-and-error is unfair, I can't come up wit=
h a way how to deal with that topic. Is it even possible [with the current =
programme] to supply a cube scrambled by hand without the possibility that =
someone can derive the fewest-move solution from the log-file?

@ matthewsheerin: I have to solve some 2^3 cubes in my solution, too, and I=
'm using the Guimond method (if there is any faster method, please tell me)=
. I tried to find some PLL algorithms with the computer, but I don't think =
this is cheating, because if you look them up on the internet where some ot=
her people have found them by computer, or if you do the work yourself make=
s no difference. If you, however, compute a fewest move solution for the wh=
ole 2^3 or 3^3, I would call this cheating.

btw: has anyone ever made an attempt to prove an upper bound for fewest mov=
e solutions on the 3^4?

Have a nice twist,
Klaus

Hi Klaus,

It would seem that you use a different method from me (not exactly surprisi=
ng given the range of methods a 'mere' 3D cube presents) so the similarity =
with solving the 2^3 is maybe not exact. I believe I was in the situation =
where my 2^3 solve could go either way and end in parity or no parity depen=
ding on how it was solved. The corner algorithm I provided stays within th=
e bounds of my method, which would seem to prove this.
On a 2^3 I usually opt for a method I inferred after learning the basic Hum=
an Thistlethwaite, which I think is basically Guimond (I could be wrong her=
e). For this fewest moves challenge though I found it used too many moves,=
so I had to be more open-minded about things.

Out of interest on your progress, what was 50 moves?

I think you may have point about providing a scramble which cannot be rever=
se engineered. I agree, and I can't think of a way to police against the t=
rial and error approach with different scrambles either.

I suppose looking up algorithms for smaller steps would be acceptable, sinc=
e methods for 3D cubes rely on learning algorithms too, which are generally=
found on the internet these days.

I second the request for an upper (and lower) bound for 4D, though I will s=
top short of asking for a God's number, since that hasn't been found for th=
e 3x3x3 yet!

happy hypercubing
Matthew



--- In 4D_Cubing@yahoogroups.com, "Klaus" wrote:
>
> Hi everyone,
>=20
> I also thought about this but for my system this doesn't really make sens=
e because it just takes to long to get to a position from where you can dec=
ide if this problem/parity occurs (Well it was only 50 turns but to optimiz=
e them took me about 3 days). I will however try to find a way to predict i=
t earlier and to work around this awkward situation.
>=20
> But even if you decided that trial-and-error is unfair, I can't come up w=
ith a way how to deal with that topic. Is it even possible [with the curren=
t programme] to supply a cube scrambled by hand without the possibility tha=
t someone can derive the fewest-move solution from the log-file?
>=20
> @ matthewsheerin: I have to solve some 2^3 cubes in my solution, too, and=
I'm using the Guimond method (if there is any faster method, please tell m=
e). I tried to find some PLL algorithms with the computer, but I don't thin=
k this is cheating, because if you look them up on the internet where some =
other people have found them by computer, or if you do the work yourself ma=
kes no difference. If you, however, compute a fewest move solution for the =
whole 2^3 or 3^3, I would call this cheating.
>=20
> btw: has anyone ever made an attempt to prove an upper bound for fewest m=
ove solutions on the 3^4?
>=20
> Have a nice twist,
> Klaus
>

Hi Matthew,

I will give a description of my solution when I have finished this solve an=
d perhaps two or three other ones, depending on how close I get to Roice. I=
won't explain it right now, because i don't want anyone to break the recor=
d with my sytem until i have tried to optimize it to its limits ;-)

However, I can give a very general explanation. The method works in three s=
teps.
In the first step I solve all of the 4c-pieces. On my first try this step t=
ook me 323 twists. After coming up with a more efficient way of solving the=
corners and lots of algorithms written down on paper I finally manage to s=
olve this first step within 54 moves, despite the parity case. You gave me =
an algorithm to solve this parity within 22 moves and so I finished the fir=
st step in 76 moves.
The second step is solving two complete faces opposite to each other. This =
can be compared to solving the U and D faces on the 3^3 leaving the middle =
layer scrambled. In my first attempt this took me 306 moves and this step m=
ight get a real problem because I didn't come up with a method to cut down =
on twists. At the moment I have done 27 twists in this step and have roughl=
y completed about 15%.
The last step is very similar to solving a 3^3, just in a way more confusin=
g perspective ;-) In my first solve this took me 146 twists. At that time, =
however, I just wanted to complete the 3^4 for the first time and didn't wa=
tch the turn count. So I will hopefully stay below 100 turns for this step =
this time.

I think it should be very easy to stay below 500 turns this time, but I'm n=
ot sure if I have any chance of getting near Roice. Perhaps, if I find a wa=
y to speed up step 2 I'll have some chance.

Have a nice twist,
Klaus

--- In 4D_Cubing@yahoogroups.com, "matthewsheerin" wrote=
:
>
> Hi Klaus,
>=20
> It would seem that you use a different method from me (not exactly surpri=
sing given the range of methods a 'mere' 3D cube presents) so the similarit=
y with solving the 2^3 is maybe not exact. I believe I was in the situatio=
n where my 2^3 solve could go either way and end in parity or no parity dep=
ending on how it was solved. The corner algorithm I provided stays within =
the bounds of my method, which would seem to prove this.
> On a 2^3 I usually opt for a method I inferred after learning the basic H=
uman Thistlethwaite, which I think is basically Guimond (I could be wrong h=
ere). For this fewest moves challenge though I found it used too many move=
s, so I had to be more open-minded about things.
>=20
> Out of interest on your progress, what was 50 moves?
>=20
> I think you may have point about providing a scramble which cannot be rev=
erse engineered. I agree, and I can't think of a way to police against the=
trial and error approach with different scrambles either.
>=20
> I suppose looking up algorithms for smaller steps would be acceptable, si=
nce methods for 3D cubes rely on learning algorithms too, which are general=
ly found on the internet these days.
>=20
> I second the request for an upper (and lower) bound for 4D, though I will=
stop short of asking for a God's number, since that hasn't been found for =
the 3x3x3 yet!
>=20
> happy hypercubing
> Matthew

To answer Klaus' question, it currently *is* possible with the current
puzzle to supply a scrambled log file that does not include the scramble
history. I'm not sure that makes much difference however because I
suspect it wouldn't be too hard for someone to tell whether a solution
essentially backed out the scrambling, and it certainly wouldn't
resemble any sort of human solution. There are definitely interesting
questions regarding which methods should be considered fair and how to
disallow or detect cheating. I already caught one attempt, so these are
not an abstract questions.

Early on we had to drill deeply into the question of macro use before
deciding that they are fair to use but that solutions using them just
shouldn't be compared with ones that didn't. Even still there are
unanswered questions such as whether they should be allowed during speed
solving competitions and if so, should they have to be created during
the actual timed runs or whether use of previously created macro files
should be allowed.

For the "shortest" category, my feeling is that just about anything
short of backing out the scramble should be allowed. If you can write or
find software to help, then power to you though I hope that you'd
declare any aids you used. OTOH, there's still this issue of searching
for random scrambles that let you side-step parity problems or even
whole steps. As an extreme and completely impractical thought
experiment, imagine writing a program that can examine an ungodly number
of full scrambles in search of one that just so happens to be one twist
away from being solved. If you then solve it, can you really claim to
have performed the shortest solution to a full scramble with a single
twist? And even if we disallowed such cherry picking, and assuming we
could enforce that rule, then would it fair even then since some people
will simply get lucky sometimes. I certainly wouldn't want to tell
someone that they have to finish each full solve before starting another
one! OTOH (I get at least 3 hands in 4D, right?) this is the idea behind
averaging several solves commonly used in speed solving.

For myself, I don't worry about people cherry picking very much in most
cases largely because most puzzles are really 3 puzzles in one (2C + 3C
+ 4C), and so cherry picking is probably only going to be able to help
you with whichever element you like to solve first. It could however
help you to *decide* which element to start with since problems with one
element can be much harder than problems in another, but overall it
feels fair enough. My main concern is only with the 2^4 which has
nothing but corner pieces. These puzzles have always bothered me because
they're oddballs in other ways too. In retrospect I suppose this was a
rather lengthy way of saying that I have no opinion. Sorry about that! :-)

To make it up to all of you who have read this far, I'll let you in on a
bit of very juicy news: Roice and I have been hard at work generating a
new version of MC4D using a new puzzle generation engine from Don. The
new version will allow you to solve a whole bunch of beautiful new 4D
shapes other than the cube. It is also much improved in many other small
ways including sound effects, interactive arbitrary 4D rotations and a
much needed GUI facelift. Best of all, you get to be the first people to
try it out when we create our first beta testing version soon. So watch
this space for news of MC4D 4.0!

Happy puzzling!
-Melinda

matthewsheerin wrote:
>
>
> [...]
>
> I think you may have point about providing a scramble which cannot be
> reverse engineered. I agree, and I can't think of a way to police
> against the trial and error approach with different scrambles either.
>
> I suppose looking up algorithms for smaller steps would be acceptable,
> since methods for 3D cubes rely on learning algorithms too, which are
> generally found on the internet these days.
>
> I second the request for an upper (and lower) bound for 4D, though I
> will stop short of asking for a God's number, since that hasn't been
> found for the 3x3x3 yet!
>
> happy hypercubing
> Matthew
>
> --- In 4D_Cubing@yahoogroups.com ,
> "Klaus" wrote:
> >
> > Hi everyone,
> >
> > I also thought about this but for my system this doesn't really make
> sense because it just takes to long to get to a position from where
> you can decide if this problem/parity occurs (Well it was only 50
> turns but to optimize them took me about 3 days). I will however try
> to find a way to predict it earlier and to work around this awkward
> situation.
> >
> > But even if you decided that trial-and-error is unfair, I can't come
> up with a way how to deal with that topic. Is it even possible [with
> the current programme] to supply a cube scrambled by hand without the
> possibility that someone can derive the fewest-move solution from the
> log-file?
> >
> > @ matthewsheerin: I have to solve some 2^3 cubes in my solution,
> too, and I'm using the Guimond method (if there is any faster method,
> please tell me). I tried to find some PLL algorithms with the
> computer, but I don't think this is cheating, because if you look them
> up on the internet where some other people have found them by
> computer, or if you do the work yourself makes no difference. If you,
> however, compute a fewest move solution for the whole 2^3 or 3^3, I
> would call this cheating.
> >
> > btw: has anyone ever made an attempt to prove an upper bound for
> fewest move solutions on the 3^4?
> >
> > Have a nice twist,
> > Klaus
> >
>
>

Hello again,
This has certainly turned out to be an interesting discussion!

That's an interesting method you have there Klaus, and I'm sure I'm not the=
only one here who would like to see how far it can be pushed. I have been=
considering various ideas for reducing move counts, which I think would be=
hard to explain, and are also unproven just now. Despite the fact I want =
to with all this talk, I will not be attempting any fewest moves solves any=
time soon. I have my reasons, not least of which is a lack of free time n=
ow I have started uni. I will eventually return to the idea, especially si=
nce your 54 move solution for the corners, had it not encountered parity, w=
ould have been able to demolish the current record for the 2^4, and I think=
it would be worth your while considering having a crack at that one. I ca=
n think of how to significantly reduce my move count for the 2^4 and the 3^=
4, but the question of whether my ideas work and by how much will have to w=
ait.

@Melinda: I would consider using a computer generated solution to certainly=
be cheating, even if the person in question wrote the program. I have no =
qualms about using macros created by the solver (though I slowly stopped us=
ing them for my 4D solves, I feel they hinder the move count), but the thin=
king behind the solution should be all, or at least mainly, done by a human=
.

Just to finish, I am looking forward to new 4D puzzles becoming available. =
I have considered it a possibility from the start and I am excited to see =
what they look like and how they behave. Many thanks to the wonderful peop=
le helping to bring them to life! :)

happy hypercubing
Matthew

--- In 4D_Cubing@yahoogroups.com, "Klaus" wrote:
>
> Hi Matthew,
>=20
> I will give a description of my solution when I have finished this solve =
and perhaps two or three other ones, depending on how close I get to Roice.=
I won't explain it right now, because i don't want anyone to break the rec=
ord with my sytem until i have tried to optimize it to its limits ;-)
>=20
> However, I can give a very general explanation. The method works in three=
steps.
> In the first step I solve all of the 4c-pieces. On my first try this step=
took me 323 twists. After coming up with a more efficient way of solving t=
he corners and lots of algorithms written down on paper I finally manage to=
solve this first step within 54 moves, despite the parity case. You gave m=
e an algorithm to solve this parity within 22 moves and so I finished the f=
irst step in 76 moves.
> The second step is solving two complete faces opposite to each other. Thi=
s can be compared to solving the U and D faces on the 3^3 leaving the middl=
e layer scrambled. In my first attempt this took me 306 moves and this step=
might get a real problem because I didn't come up with a method to cut dow=
n on twists. At the moment I have done 27 twists in this step and have roug=
hly completed about 15%.
> The last step is very similar to solving a 3^3, just in a way more confus=
ing perspective ;-) In my first solve this took me 146 twists. At that time=
, however, I just wanted to complete the 3^4 for the first time and didn't =
watch the turn count. So I will hopefully stay below 100 turns for this ste=
p this time.
>=20
> I think it should be very easy to stay below 500 turns this time, but I'm=
not sure if I have any chance of getting near Roice. Perhaps, if I find a =
way to speed up step 2 I'll have some chance.
>=20
> Have a nice twist,
> Klaus
>=20
> --- In 4D_Cubing@yahoogroups.com, "matthewsheerin" wrote:
> >
> > Hi Klaus,
> >=20
> > It would seem that you use a different method from me (not exactly surp=
rising given the range of methods a 'mere' 3D cube presents) so the similar=
ity with solving the 2^3 is maybe not exact. I believe I was in the situat=
ion where my 2^3 solve could go either way and end in parity or no parity d=
epending on how it was solved. The corner algorithm I provided stays withi=
n the bounds of my method, which would seem to prove this.
> > On a 2^3 I usually opt for a method I inferred after learning the basic=
Human Thistlethwaite, which I think is basically Guimond (I could be wrong=
here). For this fewest moves challenge though I found it used too many mo=
ves, so I had to be more open-minded about things.
> >=20
> > Out of interest on your progress, what was 50 moves?
> >=20
> > I think you may have point about providing a scramble which cannot be r=
everse engineered. I agree, and I can't think of a way to police against t=
he trial and error approach with different scrambles either.
> >=20
> > I suppose looking up algorithms for smaller steps would be acceptable, =
since methods for 3D cubes rely on learning algorithms too, which are gener=
ally found on the internet these days.
> >=20
> > I second the request for an upper (and lower) bound for 4D, though I wi=
ll stop short of asking for a God's number, since that hasn't been found fo=
r the 3x3x3 yet!
> >=20
> > happy hypercubing
> > Matthew
>

=20
=A0




=20=20=20=20
To answer Klaus' question, it currently *is* possible wit=
h the current=20

puzzle to supply a scrambled log file that does not include the scramble=20

history. I'm not sure that makes much difference however because I=20

suspect it wouldn't be too hard for someone to tell whether a solution=20

essentially backed out the scrambling, and it certainly wouldn't=20

resemble any sort of human solution. There are definitely interesting=20

questions regarding which methods should be considered fair and how to=20

disallow or detect cheating. I already caught one attempt, so these are=20

not an abstract questions.



Early on we had to drill deeply into the question of macro use before=20

deciding that they are fair to use but that solutions using them just=20

shouldn't be compared with ones that didn't. Even still there are=20

unanswered questions such as whether they should be allowed during speed=20

solving competitions and if so, should they have to be created during=20

the actual timed runs or whether use of previously created macro files=20

should be allowed.



For the "shortest" category, my feeling is that just about anything=20

short of backing out the scramble should be allowed. If you can write or=20

find software to help, then power to you though I hope that you'd=20

declare any aids you used. OTOH, there's still this issue of searching=20

for random scrambles that let you side-step parity problems or even=20

whole steps. As an extreme and completely impractical thought=20

experiment, imagine writing a program that can examine an ungodly number=20

of full scrambles in search of one that just so happens to be one twist=20

away from being solved. If you then solve it, can you really claim to=20

have performed the shortest solution to a full scramble with a single=20

twist? And even if we disallowed such cherry picking, and assuming we=20

could enforce that rule, then would it fair even then since some people=20

will simply get lucky sometimes. I certainly wouldn't want to tell=20

someone that they have to finish each full solve before starting another=20

one! OTOH (I get at least 3 hands in 4D, right?) this is the idea behind=20

averaging several solves commonly used in speed solving.



For myself, I don't worry about people cherry picking very much in most=20

cases largely because most puzzles are really 3 puzzles in one (2C + 3C=20

+ 4C), and so cherry picking is probably only going to be able to help=20

you with whichever element you like to solve first. It could however=20

help you to *decide* which element to start with since problems with one=20

element can be much harder than problems in another, but overall it=20

feels fair enough. My main concern is only with the 2^4 which has=20

nothing but corner pieces. These puzzles have always bothered me because=20

they're oddballs in other ways too. In retrospect I suppose this was a=20

rather lengthy way of saying that I have no opinion. Sorry about that! :-)



To make it up to all of you who have read this far, I'll let you in on a=20

bit of very juicy news: Roice and I have been hard at work generating a=20

new version of MC4D using a new puzzle generation engine from Don. The=20

new version will allow you to solve a whole bunch of beautiful new 4D=20

shapes other than the cube. It is also much improved in many other small=20

ways including sound effects, interactive arbitrary 4D rotations and a=20

much needed GUI facelift. Best of all, you get to be the first people to=20

try it out when we create our first beta testing version soon. So watch=20

this space for news of MC4D 4.0!



Happy puzzling!

-Melinda


=09
=09=20
=09
=09




=09




=09
=09


=09
=09
=09




=20=20=20=20=20=20
--0-804030045-1255795311=:32770
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

top" style=3D"font: inherit;">All- I think allowing "che= rry-picking" should be allowed, as it's not enforcible. However as with 3^3= cubing and n^4 with macros, this should be mentioned by the solver. If som= eone happened upon a scramble which happened to have the 4c's solved, this = would increase their odds of setting a record (depending on their method). = This sort of lucky scramble should be noted. As far as sp= eed hypercubing, there should be several classes. This seems like blindfold= ed cubing to me. Some people include the memorization time in their solutio= ns. This requires a fast method of memorization and a less complex method d= uring the actual solve. Solutions, counting memorization, range from approx= imately 1:30 to 10:00. Others only include the actual solve time in the sol= ution. This requires a fast solution, typically by solving the cube in your head and memorizing this short sequence. If you include the memorization t= ime, this method would take prohibitively long, yet the actual solution can= be performed in seconds. Back to hypercubing. I t= hink macros would speed up most solves. But if someone is using them, they = should be required to rewrite them for each solve under time. This would be= very tedious, and there is no guarantee this would put macro/macroless tim= es into the same ballpark. That's where two or more categories come in.&nbs= p; As far as computer aids are concerned, this is = a difficult question. Anyone who wrote a program to produce minimal solutio= ns, or any solutions for that matter, would be recognized for such an impre= ssive accomplishment. But this shouldn't be compared to a human only soluti= on of a puzzle. I've wrestled over developing a program to automate my n^d = solution when I make my attempt at the 7^5. This program would perform the exact method I would use. Inputting a log file and clicking ru= n clearly isn't the same as me sitting in front of the puzzle for weeks tur= ning the puzzle and hashing out the solution myself. But using a computer t= o generate reusable macros or something similar could be OK. (I spent a day= or two writing the macros I used to solve the 6^5, and as my laptop I save= d them on died, I'll be doing it again!) I'd compare this to climbing evere= st- would my name be added to the list of climbers if I built a robot to cl= imb for me? How about if I use GPS? Where do we draw the line? r> There's one final point I'd like to make in contradiction to e= verything I just said. We're already such an elite subset of the magic cube= solvers, dividing us up too much really defeats the point of competitions = like speed solving or minimal solves. Happy solvin= g everyone! -Levi --- On <= b>Thu, 10/15/09, Melinda Green <melinda@superliminal.com> = wrote: gin-left: 5px; padding-left: 5px;"> From: Melinda Green <melinda@supe= rliminal.com> Subject: Re: [MC4D] Re: 3^4 parity problems To: 4D_C= ubing@yahoogroups.com Date: Thursday, October 15, 2009, 2:44 PM <= div id=3D"yiv543147080"> =20   To answer Klaus' question, it currently *is* possible = with the current puzzle to supply a scrambled log file that does not include the scramble r> history. I'm not sure that makes much difference however because I suspect it wouldn't be too hard for someone to tell whether a solution essentially backed out the scrambling, and it certainly wouldn't resemble any sort of human solution. There are definitely interesting questions regarding which methods should be considered fair and how to disallow or detect cheating. I already caught one attempt, so these are > not an abstract questions. Early on we had to drill deeply into the question of macro use before deciding that they are fair to use but that solutions using them just shouldn't be compared with ones that didn't. Even still there are unanswered questions such as whether they should be allowed during speed r> solving competitions and if so, should they have to be created during the actual timed runs or whether use of previously created macro files should be allowed. For the "shortest" category, my feeling is that just about anything short of backing out the scramble should be allowed. If you can write or r> find software to help, then power to you though I hope that you'd declare any aids you used. OTOH, there's still this issue of searching for random scrambles that let you side-step parity problems or even whole steps. As an extreme and completely impractical thought experiment, imagine writing a program that can examine an ungodly number r> of full scrambles in search of one that just so happens to be one twist > away from being solved. If you then solve it, can you really claim to have performed the shortest solution to a full scramble with a single twist? And even if we disallowed such cherry picking, and assuming we could enforce that rule, then would it fair even then since some people > will simply get lucky sometimes. I certainly wouldn't want to tell someone that they have to finish each full solve before starting another r> one! OTOH (I get at least 3 hands in 4D, right?) this is the idea behind r> averaging several solves commonly used in speed solving. For myself, I don't worry about people cherry picking very much in most > cases largely because most puzzles are really 3 puzzles in one (2C + 3C > + 4C), and so cherry picking is probably only going to be able to help you with whichever element you like to solve first. It could however help you to *decide* which element to start with since problems with one r> element can be much harder than problems in another, but overall it feels fair enough. My main concern is only with the 2^4 which has nothing but corner pieces. These puzzles have always bothered me because r> they're oddballs in other ways too. In retrospect I suppose this was a rather lengthy way of saying that I have no opinion. Sorry about that! :-)= To make it up to all of you who have read this far, I'll let you in on a r> bit of very juicy news: Roice and I have been hard at work generating a > new version of MC4D using a new puzzle generation engine from Don. The new version will allow you to solve a whole bunch of beautiful new 4D shapes other than the cube. It is also much improved in many other small r> ways including sound effects, interactive arbitrary 4D rotations and a much needed GUI facelift. Best of all, you get to be the first people to r> try it out when we create our first beta testing version soon. So watch > this space for news of MC4D 4.0! Happy puzzling! -Melinda pan class=3D"Apple-style-span" style=3D"font-size: 10px; line-height: 12px;= ">=3D"Apple-style-span" style=3D"font-size: 13px; line-height: 15px;"> pan> =09 =09=20 =09 =09

=20=20=20=20=20=20
--0-804030045-1255795311=:32770--

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 abo=
ut 54 moves (I think there will be a way of working around the parity, howe=
ver a very time consuming one), but on a 2^4 this will take a lot more turn=
s, because you can only perform twists equivalent to turning around a 2c-pi=
ece on a 3^4. Therefore, if you use the same method for the same scramble o=
f the corners on a 3^4 and a 2^4 it will take more turns on a 2^4 and I'm n=
ot 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 t=
he effort to implement a 600-cell, however I'm not sure if anyone would hav=
e the time to solve this ;-)

@ Levi:
I think you're right with most of what you have said. One can't compare spe=
ed solutions using macros to those achieved "bare-handed" (as David Vanders=
chel 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, bu=
t measure the time used for this, it could add this amount of time to the c=
lock 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 exac=
tly 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 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 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?
>> http://link.interia.pl/f23bb

=20
=A0




=20=20=20=20
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 abo=
ut 54 moves (I think there will be a way of working around the parity, howe=
ver a very time consuming one), but on a 2^4 this will take a lot more turn=
s, because you can only perform twists equivalent to turning around a 2c-pi=
ece on a 3^4. Therefore, if you use the same method for the same scramble o=
f the corners on a 3^4 and a 2^4 it will take more turns on a 2^4 and I'm n=
ot 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 t=
he effort to implement a 600-cell, however I'm not sure if anyone would hav=
e the time to solve this ;-)



@ Levi:

I think you're right with most of what you have said. One can't compare spe=
ed solutions using macros to those achieved "bare-handed" (as David Vanders=
chel 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, bu=
t measure the time used for this, it could add this amount of time to the c=
lock 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 exac=
tly 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




=20

=20=20=20=20=20=20

=20=20=20=20
=20=20=20=20
=09
=09=20
=09
=09




=09




=09
=09


=09
=09
=09




=20=20=20=20=20=20
--0-1619191419-1255892001=:34131
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

top" style=3D"font: inherit;">Klaus- I think your idea o= f 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: =3D"border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left= : 5px;"> From: Klaus <klaus.weidinger@yahoo.com> Subject: [MC4D= ] Re: 3^4 parity problems To: 4D_Cubing@yahoogroups.com Date: Saturda= y, October 17, 2009, 10:01 AM =20   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 abo= ut 54 moves (I think there will be a way of working around the parity, howe= ver a very time consuming one), but on a 2^4 this will take a lot more turn= s, because you can only perform twists equivalent to turning around a 2c-pi= ece on a 3^4. Therefore, if you use the same method for the same scramble o= f the corners on a 3^4 and a 2^4 it will take more turns on a 2^4 and I'm n= ot 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 t= he effort to implement a 600-cell, however I'm not sure if anyone would hav= e the time to solve this ;-) @ Levi: I think you're right with most of what you have said. One can't compare spe= ed solutions using macros to those achieved "bare-handed" (as David Vanders= chel 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, bu= t measure the time used for this, it could add this amount of time to the c= lock 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 exac= tly 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 =20 =20=20 =09=20 =09 =09

=20=20=20=20=20=20
--0-1619191419-1255892001=:34131--

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 //* wrote:
>
>
> From: Klaus
> 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 wor=
k around different styles of macro usage. However I don't understand why yo=
u 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 ma=
cro timer, you could just add some penalty time whenever a macro is execute=
d. This could be some fixed amount like 10 seconds or just generally a cert=
ain 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. How=
ever, I admit there will likely never be a truely fair solution to this pro=
blem, despite just making two separate categories for macro and non-macro s=
olves.

Another problem dealing with this issue is, that one could cheat by klickin=
g 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 amoun=
t 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 make=
s 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, wou=
ld not be strong enough to prevent this way of cheating and to just raise t=
he 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 a=
ccepted. 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 proble=
m if you are not able to predict, whether you need it multiple times. There=
fore 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 ol=
d 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 wrote:
>
> I also think it is a clever solution. I've added it to our feature wish=20
> list along with the idea of a solution timer which will be rather easy=20
> to add. Of course to guard against cheating it seems like we'd need to=20
> have everyone in the same place whereas speed solving without such an=20
> equalizer can be done by distributing a shared scramble and seeing who=20
> can post the first solution.
>=20
> One thing that worries me a little is that either way we might be=20
> forcing people to use macros in order to stay competitive. This may be=20
> true even with Klaus' macro timer because the solver only needs to=20
> concentrate really hard at the beginning in order to perform the=20
> algorithm as fast as possible once and then take advantage of that speed=
=20
> every time they apply it, whereas a person solving without macros will=20
> be penalized whenever they make a mistake or simply perform it more=20
> slowly when they start getting tired. This might not apply to the 2^4=20
> where the solutions might become so fast that the advantage will go to=20
> the non macro users. At the minimum I will plan to add a solution timer=20
> while we think some more about Klaus' fascinating refinement.
>=20
> And speaking of the 2^4, I should probably give you a heads-up regarding=
=20
> the new version which may affect the shortest records. Twists in the new=
=20
> versions are "grip" based rather than sticker based. One nice=20
> side-effect of this change is that it allows macros created for a puzzle=
=20
> of one size to be used on other sizes as well. That will provide one way=
=20
> in which you will be able to apply your 3^4 macros to the 2^4 that=20
> include twists that the UI currently does not offer directly on the 2^4.=
=20
> There's even another more subtle way this affects you which I hesitate=20
> to say but I aught to disclose because some people will figure it out=20
> anyway. The fact is that you could perform your shortest solution to=20
> just the corners of the 3^4 (with or without macros) and then change=20
> your log file to declare the puzzle to be a complete solution to the=20
> 2^4. I would not consider this to be cheating because I see it as more=20
> of a problem that the UI does not currently give you a way to get at all=
=20
> the grips of that puzzle. For this and other reasons, I don't like the=20
> 2^4 very much but obviously lots of you do and you therefore deserve to=20
> know about these things so that you can discuss and decide what you=20
> think is fair and how the various records and competitions should be=20
> handled.
>=20
> -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. 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 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 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 sugges=
tions. These were just thoughts about how to deal with problems that even m=
ight never evolve. Even if you don't use any of them in the first version o=
f the new programme I won't be mad at you because I'm really looking forwar=
d to seeing this new programm at work ;-) And additionally I'm no speedcube=
r 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=20
> order for it to be fair but it would certainly be the easiest way.
=20
I don't think so. Well, perhaps it would be the easiest way to prevent chea=
ting, 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 wh=
ole world and few would come from remote places.

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

Well, if you have some spare time ;-) and want to programme some web interf=
ace 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 coul=
d hack the server ;-)

> I also like the idea of holding informal races timed=20
> only by the wall clock. I think that it makes good sense to include a=20
> timer in MC4D that solvers can use as they like in order to more easily=20
> measure and compare their personal, unofficial speeds.
>=20
> This is probably a good point to announce our intention to set up a wiki=
=20
> to let you guys maintain your own unofficial hall-of-fame for=20
> accomplishments and records. I still intend to maintain the current=20
> official list of solvers and shortest records for the 3^4, 4^4, and 5^4,=
=20
> as well as the shortest 2^4; but it will simply be too much work for me=20
> to do the same for the veritable zoo of new puzzles and sizes that are=20
> about to become available. If anyone has suggestions for how to=20
> administer and official HOF for these, please share your ideas. Until=20
> 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 possi=
ble platonic polychora turned into puzzles, but what else can this programm=
e do?
=20
> Regarding your question about allowing half turns in addition to quarter=
=20
> turns: this is not a grip vs. sticker issue but it does involve the log=20
> files. The existing product supports half turns internally but not in=20
> the log file format. The new version will now support it in the log=20
> files as well but not yet in the UI. I had experimented with the idea of=
=20
> using the shift key to "double" the amount of twist you get when=20
> clicking. That actually would work fine but now with all the new puzzles=
=20
> it wouldn't seem right to support only doubling of twist angles when=20
> some puzzles would benefit just as much from multiplying by 3, 4, 5,=20
> etc. The problem is that we can't think of a good usable way to support=20
> that in the UI. This will make more sense once you've had a chance to=20
> play with the new puzzles a bit. We will then count on you guys to make=20
> suggestions for how we might implement that and how to compare records=20
> set before and after any such feature becomes available.
>=20
> Regarding your question about correcting past records due to changing to=
=20
> grip vs. sticker based log files: the only record that I think of that=20
> might need to be corrected would be the shortest 2^4. Thinking now about=
=20
> how to do that gives me an interesting thought about how to count twists=
=20
> in general. Maybe any number of consecutive twists on a given face with=20
> 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 othe=
r derivation of it. Of course you are right that turns of one face with dif=
ferent 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 klickin=
g 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 th=
e slice mask and making the numpad "," or the "0" equal to the current func=
tion 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 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@interia.pl 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
>

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

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

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

> [...]
> They wouldn't have to hack the server to cheat. Team and computer=20
> assistance would still be possible, even if it would eliminate some=20
> 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=20
> available in the late afternoon this Friday. We anticipate that this may=
=20
> set off a mini gold rush of attempt to claim "firsts" records, so this=20
> timing will hopefully give the most people the chance to plan to spend=20
> 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, be=
cause 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=20
> >> 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=
=20
> require clicking on any particular cubie but rather would let you=20
> continuously drag a whole face around and have it snap into the closest=20
> orientation when you release the mouse. Ideally you'd be able to do this=
=20
> several times in a row to the same face and have it count as a single=20
> 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=20
> grip-based. The main difference is in the log files. The user interface=20
> will be the same as before, so most users will not notice the difference=
=20
> except that your new macros will apply to all sizes of the puzzle type=20
> you defined them on.

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

Have a nice twist,
Klaus

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 une=
xpected 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 sequ=
ence 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 solutio=
n, which took the most twists this time.

Have a nice twist,
Klaus