Thread: "Social dream"

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 RubikExpl=
orer 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 numbe=
ring sequence. Is the numbering sequence in "Magic120Cell" and in MC4D topo=
logically 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 a=
nd corners). In this case the transfer is very important for me.


--- In 4D_Cubing@yahoogroups.com, Roice Nelson wrote:
>
> Hi Eduard,
>=20
> 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 p=
er
> 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, an=
d
> 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.
>=20
> MC4D has a different encoding of twists. I didn't check the source code
> (which is available
> online),
> but I'm pretty sure the last digit you were asking about is a
> bitmaskrepresenting 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 h=
ad
> a 120-cell puzzle with 5 stickers per side, slicemask would need to be
> included.
>=20
> Here are my other thoughts on this.
>=20
> - 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 huma=
n
> 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 t=
o
> MC4D and retire the Magic120Cell code. Also, I think the log file
> standardization Andrey has suggested would sidestep this need, assuming t=
he
> various implementations were updated to respect it.
> - An "evaluator" feature could be added directly to MC4D, which would sh=
ow
> 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,
> 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 cod=
e
> just cycles through stickers on a face and checks whether they are all th=
e
> 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.
>=20
> Best,
> Roice
>=20
>=20
> On Sat, Feb 19, 2011 at 8:13 AM, Eduard wrote:
>=20
> >
> > (a) Introduction
> >
> > The marvelaous 120-Cell in 4D.
> >
> > The 4D Regulars are very sympathic models of perfect democratic societi=
es
> > with perfectly equal individuals. Each has an equal number of neighbour=
s in
> > equal constellation. This number is 4 for the 5-Cell, 6 for the hypercu=
be (8
> > `individuals') and 12 for the 120-Cell (120 `individuals' =3D society).
> >
> > A cluster of bees in winter has to arrange changes of roles (inner / ou=
ter
> > places in the cluster). Everybody wants be in the warmer inner space. N=
o
> > such problems in 4D at least for 120 bees housed in the 120-Cell. Every=
body
> > is equally surrounded by 12 neighbours. Perhaps arrange the bees in 3D =
in a
> > infinite grid to avoid social problems.
> >
> > Let me use the abreviations =84Magic" for the program Magic120Cell and
> > =84Hyper" for the Hypermeaminx puzzle in MC4D.
> >
> >
> > (b) Combine Magic and Hyper.
> >
> > I think Magic and Hyper cannot share their log files.
> >
> > Complementarity: Magic has finding help and no macro, Hyper has no find=
ing
> > help but macro.
> >
> > I need both!
> >
> > How about a *transfer* program?
> >
> > Roice: can you give me a table with the two corresponding labelings of
> > stickers in Magic and Hyper? I need also to know the signification of t=
he
> > last digit of the numbers in Magic log file (2 clockwise and 4 anticloc=
kwise
> > for faces, what is 6 and 8?).
> >
> >
> > (c) Partial HOF
> >
> > The HOF for the 120-Cell has only two entries until now. Noel Chalmers =
and
> > Matt Galla (great performer). In order to achive more participants (abo=
ut
> > 400 as in the Al Zimmerman contests) I propose to install HOF for parti=
al
> > results.
> >
> > For this I need an *evaluator*, a program which calculates the percenta=
ge
> > of cubies in place and well oriented from the log file. The code must
> > already existe for the checking and emitting "Congratulations" in MC4D.
> >
> > With this evaluator a ranking list is possible as in the Al Zimmerman
> > contests (take best results of each participant).
> >
> > This can be a good motivation to get in touch with the 120-Cell and liv=
e a
> > moment in the world of this 120 individuals (dodecahedra).
> >
> > If I get the evaluator and the incoming log files
> >
> > I propose to do the managing this of partial HOF in superliminal.com/wi=
ki(in protected pages).
> >
> > Doing only the 2 colored faces in the 120-Cell is already demanding bec=
ause
> > you have to get a good feeling of the neighbourhoods and soon to use
> > commutators to avoid the disturbing of already placed cubies.
> >
> > If this partial HOF is working I propose to do promotion in (1) Roice's
> > description of Magic120Cell, (2) Roice's description of MC4D, (3)
> > Superliminal.com/wiki and (4) in the "4D cubing" forum.
> >
> > What do you think all?
>

--0016e6da98b90002dd049cbece0e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Eduard,

I'm sorry, but I do not think what you are asking for is trivial to do. Th=
e
sticker numbering sequence is indeed different among the two programs.
There is somewhat of a regular order in Magic120Cell (the first sticker of
each cell is the center, the next 12 are the 2C pieces, then 3C follow,
etc.), but this is not true in MC4D, where the stickers are created by a
generic polytope slicing engine that will not produce stickers in a
guaranteed, well-ordered manner. Furthermore, the cell ordering and cell
orientations certainly won't match, and this will also affect the sticker
numbering sequence.

In short, I'm afraid that without some complex custom coding, it will not b=
e
possible to generate the transfer table you'd like. So my apologies, but I
think you are out of luck until one of the developers has time to add a
piece finding feature to MC4D.

Take Care,
Roice


On Sun, Feb 20, 2011 at 4: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 MC=
4D
> topologically equivalent or are they both arbitrary and it is very diffic=
ult
> to associate the two numberings?
>
> I'm interested to start NOW with the faces in Magic120Cell where no macro=
s
> are needed and the find option is very usefull. This will cost lot of hou=
rs
> (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 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. I=
n
> > 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 whi=
ch
> 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 com=
e
> up
> > with a standard format, so I'm sure some of these issues will arise whe=
n
> > that is discussed.
> >
> > MC4D has a different encoding of twists. I didn't check the source cod=
e
> > (which is available
> > online),
> > but I'm pretty sure the last digit you were asking about is a
> > bitmaskrepresenting the
> > slicemask of the twist (which slices were held down while
> > twisting). For the 120-cell puzzle with 3 stickers-per-side, this is n=
ot
> 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 makin=
g
> 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 thi=
nk
> > 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 woul=
d
> be
> > good to add to the issue
> > tracker,
> > 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 ra=
n
> > 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 kno=
ws
> it
> > is not solved and immediately returns. So it doesn't need to think abo=
ut
> > how much of the puzzle is completed.
> >
> > Best,
> > Roice
> >
> >
> > On Sat, Feb 19, 2011 at 8:13 AM, Eduard wrote:
> >
> > >
> > > (a) Introduction
> > >
> > > The marvelaous 120-Cell in 4D.
> > >
> > > The 4D Regulars are very sympathic models of perfect democratic
> societies
> > > with perfectly equal individuals. Each has an equal number of
> neighbours in
> > > equal constellation. This number is 4 for the 5-Cell, 6 for the
> hypercube (8
> > > `individuals') and 12 for the 120-Cell (120 `individuals' =3D society=
).
> > >
> > > A cluster of bees in winter has to arrange changes of roles (inner /
> outer
> > > places in the cluster). Everybody wants be in the warmer inner space.
> No
> > > such problems in 4D at least for 120 bees housed in the 120-Cell.
> Everybody
> > > is equally surrounded by 12 neighbours. Perhaps arrange the bees in 3=
D
> in a
> > > infinite grid to avoid social problems.
> > >
> > > Let me use the abreviations =84Magic" for the program Magic120Cell an=
d
> > > =84Hyper" for the Hypermeaminx puzzle in MC4D.
> > >
> > >
> > > (b) Combine Magic and Hyper.
> > >
> > > I think Magic and Hyper cannot share their log files.
> > >
> > > Complementarity: Magic has finding help and no macro, Hyper has no
> finding
> > > help but macro.
> > >
> > > I need both!
> > >
> > > How about a *transfer* program?
> > >
> > > Roice: can you give me a table with the two corresponding labelings o=
f
> > > stickers in Magic and Hyper? I need also to know the signification of
> the
> > > last digit of the numbers in Magic log file (2 clockwise and 4
> anticlockwise
> > > for faces, what is 6 and 8?).
> > >
> > >
> > > (c) Partial HOF
> > >
> > > The HOF for the 120-Cell has only two entries until now. Noel Chalmer=
s
> and
> > > Matt Galla (great performer). In order to achive more participants
> (about
> > > 400 as in the Al Zimmerman contests) I propose to install HOF for
> partial
> > > results.
> > >
> > > For this I need an *evaluator*, a program which calculates the
> percentage
> > > of cubies in place and well oriented from the log file. The code must
> > > already existe for the checking and emitting "Congratulations" in MC4=
D.
> > >
> > > With this evaluator a ranking list is possible as in the Al Zimmerman
> > > contests (take best results of each participant).
> > >
> > > This can be a good motivation to get in touch with the 120-Cell and
> live a
> > > moment in the world of this 120 individuals (dodecahedra).
> > >
> > > If I get the evaluator and the incoming log files
> > >
> > > I propose to do the managing this of partial HOF in
> superliminal.com/wiki(in protected pages).
> > >
> > > Doing only the 2 colored faces in the 120-Cell is already demanding
> because
> > > you have to get a good feeling of the neighbourhoods and soon to use
> > > commutators to avoid the disturbing of already placed cubies.
> > >
> > > If this partial HOF is working I propose to do promotion in (1) Roice=
's
> > > description of Magic120Cell, (2) Roice's description of MC4D, (3)
> > > Superliminal.com/wiki and (4) in the "4D cubing" forum.
> > >
> > > What do you think all?
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--0016e6da98b90002dd049cbece0e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Eduard,

------=_NextPart_000_0006_01CBD163.5FA18720
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Okay, thanks, I understand.
I will wait with tackling the 120-cell.
Ed

----- Original Message -----=20
From: Roice Nelson=20
To: 4D_Cubing@yahoogroups.com=20
Sent: Monday, February 21, 2011 12:07 AM
Subject: Re: [MC4D] Social dream


=20=20=20=20
Hi Eduard,



I'm sorry, but I do not think what you are asking for is trivial to do. =
The sticker numbering sequence is indeed different among the two programs. =
There is somewhat of a regular order in Magic120Cell (the first sticker of=
each cell is the center, the next 12 are the 2C pieces, then 3C follow, et=
c.), but this is not true in MC4D, where the stickers are created by a gene=
ric polytope slicing engine that will not produce stickers in a guaranteed,=
well-ordered manner. Furthermore, the cell ordering and cell orientations=
certainly won't match, and this will also affect the sticker numbering seq=
uence.


In short, I'm afraid that without some complex custom coding, it will not=
be possible to generate the transfer table you'd like. So my apologies, b=
ut I think you are out of luck until one of the developers has time to add =
a piece finding feature to MC4D.


Take Care,
Roice



On Sun, Feb 20, 2011 at 4: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 wort=
h).
I see an evaluator problem for not layered methods as that in the Rubik=
Explorer 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 n=
umbering sequence. Is the numbering sequence in "Magic120Cell" and in MC4D =
topologically equivalent or are they both arbitrary and it is very difficul=
t to associate the two numberings?

I'm interested to start NOW with the faces in Magic120Cell where no mac=
ros are needed and the find option is very usefull. This will cost lot of h=
ours (weeks). I'm sure that I will not want to continue without macros (edg=
es and corners). In this case the transfer is very important for me.



--- In 4D_Cubing@yahoogroups.com, Roice Nelson 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-bi=
t
> integer, which is what you see in the log files. There are 63 sticke=
rs per
> cell, so 6 bits are required for that. 7 bits are needed to record w=
hich 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 f=
ew
> weeks ago, I made it more reader friendly. Andrey has suggested we c=
ome up
> with a standard format, so I'm sure some of these issues will arise w=
hen
> that is discussed.
>
> MC4D has a different encoding of twists. I didn't check the source c=
ode
> (which is available

> online),

> but I'm pretty sure the last digit you were asking about is a

> bitmaskrepresenting 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 y=
ou had
> a 120-cell puzzle with 5 stickers per side, slicemask would need to b=
e
> included.
>
> Here are my other thoughts on this.
>
> - I like the competitions and think they are good motivators, so mak=
ing 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 t=
hink
> the better long term solution here would be to add the missing featur=
es to
> MC4D and retire the Magic120Cell code. Also, I think the log file
> standardization Andrey has suggested would sidestep this need, assumi=
ng the
> various implementations were updated to respect it.
> - An "evaluator" feature could be added directly to MC4D, which woul=
d show
> the percentage completed on the puzzle. You could calculate percenta=
ge
> complete on either a sticker or piece basis. This feature request wo=
uld be
> good to add to the issue

> tracker,

> 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 al=
l the
> same, and does this for each face. Once it finds one different, it k=
nows it
> is not solved and immediately returns. So it doesn't need to think a=
bout
> how much of the puzzle is completed.
>
> Best,
> Roice
>
>

> On Sat, Feb 19, 2011 at 8:13 AM, Eduard wrote:
>
> >
> > (a) Introduction
> >
> > The marvelaous 120-Cell in 4D.
> >
> > The 4D Regulars are very sympathic models of perfect democratic soc=
ieties
> > with perfectly equal individuals. Each has an equal number of neigh=
bours in
> > equal constellation. This number is 4 for the 5-Cell, 6 for the hyp=
ercube (8
> > `individuals') and 12 for the 120-Cell (120 `individuals' =3D socie=
ty).
> >
> > A cluster of bees in winter has to arrange changes of roles (inner =
/ outer
> > places in the cluster). Everybody wants be in the warmer inner spac=
e. No
> > such problems in 4D at least for 120 bees housed in the 120-Cell. E=
verybody
> > is equally surrounded by 12 neighbours. Perhaps arrange the bees in=
3D in a
> > infinite grid to avoid social problems.
> >
> > Let me use the abreviations =84Magic" for the program Magic120Cell =
and
> > =84Hyper" for the Hypermeaminx puzzle in MC4D.
> >
> >
> > (b) Combine Magic and Hyper.
> >
> > I think Magic and Hyper cannot share their log files.
> >
> > Complementarity: Magic has finding help and no macro, Hyper has no =
finding
> > help but macro.
> >
> > I need both!
> >
> > How about a *transfer* program?
> >
> > Roice: can you give me a table with the two corresponding labelings=
of
> > stickers in Magic and Hyper? I need also to know the signification =
of the
> > last digit of the numbers in Magic log file (2 clockwise and 4 anti=
clockwise
> > for faces, what is 6 and 8?).
> >
> >
> > (c) Partial HOF
> >
> > The HOF for the 120-Cell has only two entries until now. Noel Chalm=
ers and
> > Matt Galla (great performer). In order to achive more participants =
(about
> > 400 as in the Al Zimmerman contests) I propose to install HOF for p=
artial
> > results.
> >
> > For this I need an *evaluator*, a program which calculates the perc=
entage
> > of cubies in place and well oriented from the log file. The code mu=
st
> > already existe for the checking and emitting "Congratulations" in M=
C4D.
> >
> > With this evaluator a ranking list is possible as in the Al Zimmerm=
an
> > contests (take best results of each participant).
> >
> > This can be a good motivation to get in touch with the 120-Cell and=
live a
> > moment in the world of this 120 individuals (dodecahedra).
> >
> > If I get the evaluator and the incoming log files
> >
> > I propose to do the managing this of partial HOF in superliminal.co=
m/wiki(in protected pages).
> >
> > Doing only the 2 colored faces in the 120-Cell is already demanding=
because
> > you have to get a good feeling of the neighbourhoods and soon to us=
e
> > commutators to avoid the disturbing of already placed cubies.
> >
> > If this partial HOF is working I propose to do promotion in (1) Roi=
ce's
> > description of Magic120Cell, (2) Roice's description of MC4D, (3)
> > Superliminal.com/wiki and (4) in the "4D cubing" forum.
> >
> > What do you think all?
>





------------------------------------

Yahoo! Groups Links







=20=20
------=_NextPart_000_0006_01CBD163.5FA18720
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



pe>