Message #1434

From: Melinda Green <melinda@superliminal.com>
Subject: Re: [MC4D] Social dream
Date: Sun, 20 Feb 2011 16:16:39 -0800

Hello Eduard,

Please be aware that if you put substantial work into a 120 cell
solution in Roice’s implementation, that you will likely either have to
wait for someone to support his log format in MC4D (or write a
stand-alone converter) or do the coding yourself. If you do it
yourself, I encourage you to write it in Java and possibly even do it by
extending MC4D to be able to read and possibly write Roice’s format.
It’s fine to do it as a stand-alone program too because it should be
easy for someone to add it later into MC4D so long as you write it in
Java. Mostly I just want to make sure that you understand the risk of
doing weeks of work with M120C in order to use its piece-finder and then
being stuck waiting for that functionality in MC4D in order to use it’s
macro ability to finish the job.

Good luck with whatever you decide to do!
-Melinda

On 2/20/2011 2:26 PM, Eduard wrote:
>
>
> Hi Roice, thanks very much for the answer.
>
> I see both the transfer program and the evaluator need work..
> I prefer the piece-evaluator (stickers can be in place without any worth).
> I see an evaluator problem for not layered methods as that in the RubikExplorer for 3D.
>
> The sticker-label-table for transfer is only about 7000 lines long.
> Unpack the integer values is not a problem for me, but what about the numbering sequence. Is the numbering sequence in "Magic120Cell" and in MC4D topologically equivalent or are they both arbitrary and it is very difficult to associate the two numberings?
>
> I’m interested to start NOW with the faces in Magic120Cell where no macros are needed and the find option is very usefull. This will cost lot of hours (weeks). I’m sure that I will not want to continue without macros (edges and corners). In this case the transfer is very important for me.
>
>
> — In 4D_Cubing@yahoogroups.com, Roice Nelson<roice3@…> wrote:
>> Hi Eduard,
>>
>> I can’t give you the "table of stickers" you are asking for, because it
>> would be huge. I can briefly describe the log file encoding though. In
>> Magic120Cell, all the information for a twist is encoded into a 32-bit
>> integer, which is what you see in the log files. There are 63 stickers per
>> cell, so 6 bits are required for that. 7 bits are needed to record which of
>> the 120 cells the sticker is on. 1 bit is used to record the twist
>> direction, and another for whether or not it is a view rotation. In
>> retrospect, I don’t like that I packed it all into an integer. It is
>> compact, but people want to look in the log files and understand them, and
>> this representation is opaque. For the MagicTile log files I did a few
>> weeks ago, I made it more reader friendly. Andrey has suggested we come up
>> with a standard format, so I’m sure some of these issues will arise when
>> that is discussed.
>>
>> MC4D has a different encoding of twists. I didn’t check the source code
>> (which is available
>> online<http://code.google.com/p/magiccube4d/source/browse/>),
>> but I’m pretty sure the last digit you were asking about is a
>> bitmask<http://en.wikipedia.org/wiki/Bitmask>representing the
>> slicemask of the twist (which slices were held down while
>> twisting). For the 120-cell puzzle with 3 stickers-per-side, this is not an
>> import piece of information, which is why it wasn’t part of my twist
>> definition above. But for other MC4D puzzles, it is important. If you had
>> a 120-cell puzzle with 5 stickers per side, slicemask would need to be
>> included.
>>
>> Here are my other thoughts on this.
>>
>> - I like the competitions and think they are good motivators, so making it
>> such that more could participate is a worthy and positive goal. (As an
>> aside, I think it’d be cool if this could be more automated…that is, if
>> the software could directly support logging solutions online without human
>> intervention.)
>> - While effort could be expended on a log file transfer program, I think
>> the better long term solution here would be to add the missing features to
>> MC4D and retire the Magic120Cell code. Also, I think the log file
>> standardization Andrey has suggested would sidestep this need, assuming the
>> various implementations were updated to respect it.
>> - An "evaluator" feature could be added directly to MC4D, which would show
>> the percentage completed on the puzzle. You could calculate percentage
>> complete on either a sticker or piece basis. This feature request would be
>> good to add to the issue
>> tracker<http://code.google.com/p/magiccube4d/issues/list>,
>> so that it will be ready for when someone is motivated to work on it. I do
>> know it will be a difficult problem to handle generally in MC4D, due to
>> even-length puzzles where there aren’t unmoving central stickers. I ran
>> into this when adding this feature to MC5D. FYI, right now, the MC4D code
>> just cycles through stickers on a face and checks whether they are all the
>> same, and does this for each face. Once it finds one different, it knows it
>> is not solved and immediately returns. So it doesn’t need to think about
>> how much of the puzzle is completed.
>>
>> Best,
>> Roice
>>