Message #715

From: Klaus <>
Subject: [MC4D] Re: 3^4 parity problems
Date: Wed, 21 Oct 2009 15:15:04 -0000

> 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,