Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6695 > unrolled thread

Rubik's cube

Back to article view | Back to comp.programming

Contents

  Rubik's cube G G <gdotone@gmail.com> - 2016-07-01 02:21 -0700
    Re: Rubik's cube G G <gdotone@gmail.com> - 2016-07-01 02:28 -0700
    Re: Rubik's cube G G <gdotone@gmail.com> - 2016-07-01 07:40 -0700
    Re: Rubik's cube Tim Harig <timharig@eternal-september.org> - 2016-07-01 16:19 +0000
      Re: Rubik's cube G G <gdotone@gmail.com> - 2016-07-01 10:00 -0700
    Re: Rubik's cube Öö Tiib <ootiib@hot.ee> - 2016-07-17 07:39 -0700
      Re: Rubik's cube BartC <bc@freeuk.com> - 2016-07-18 00:39 +0100

#6695 — Rubik's cube

where to start:

a 3 X 3 X 3 array
   fixed sized not growing or shrinking so an array is 
   a reasonable data representation?

question the only way a to change a position of a 
   piece  is through rotation?

- so matrix mathematics to handle the rotations?

[toc] | [next] | [standalone]

#6696

On Friday, July 1, 2016 at 5:21:12 AM UTC-4, G G wrote:
> where to start:
> 
> a 3 X 3 X 3 array
>    fixed sized not growing or shrinking so an array is 
>    a reasonable data representation?
> 
> question the only way a to change a position of a 
>    piece  is through rotation?
> 
> - so matrix mathematics to handle the rotations?

the center piece determines the color of a side.
the corner pieces have three colors - once the 
corner piece has the same color as the piece in 
the middle one can determine what color the other
faces must be.

[toc] | [prev] | [next] | [standalone]

#6697

On Friday, July 1, 2016 at 5:21:12 AM UTC-4, G G wrote:
> where to start:
> 
> a 3 X 3 X 3 array
>    fixed sized not growing or shrinking so an array is 
>    a reasonable data representation?
> 
> question the only way a to change a position of a 
>    piece  is through rotation?
> 
> - so matrix mathematics to handle the rotations?

though this is a cube, a three by three, by three is not a good representation of 
the data

[toc] | [prev] | [next] | [standalone]

#6698

On 2016-07-01, G G <gdotone@gmail.com> wrote:
> a 3 X 3 X 3 array
>    fixed sized not growing or shrinking so an array is 
>    a reasonable data representation?

I wrote a rubik's cube simulator using a graph network.

> question the only way a to change a position of a 
>    piece  is through rotation?
> - so matrix mathematics to handle the rotations?

For my graph network, you simply walked around one set of vertexes and changed
where the edges pointered. The hard part was keeping track of which
direction each vertex reference was pointing as it was shuffled around.  I
had to create a notation system for referring to which edge was pointed
where, and since my notation was from a single angle, change the edge
direction names along with the references as they were shuffled around.

The labeling was not strickly necessary for the code but kept things
straight in my head.  I also created a model cube with numbered squares
so that I could quickly confirm that the transformations where done
correctly.

[toc] | [prev] | [next] | [standalone]

#6699

On Friday, July 1, 2016 at 12:19:08 PM UTC-4, Tim Harig wrote:

> For my graph network, you simply walked around one set of vertexes and changed
> where the edges pointered. The hard part was keeping track of which
> direction each vertex reference was pointing as it was shuffled around.  I
> had to create a notation system for referring to which edge was pointed
> where, and since my notation was from a single angle, change the edge
> direction names along with the references as they were shuffled around.
> 
> The labeling was not strickly necessary for the code but kept things
> straight in my head.  I also created a model cube with numbered squares
> so that I could quickly confirm that the transformations where done
> correctly.

ok, i can see using a graph.

[toc] | [prev] | [next] | [standalone]

#6716

On Friday, 1 July 2016 12:21:12 UTC+3, G G  wrote:
> where to start:
> 
> a 3 X 3 X 3 array
>    fixed sized not growing or shrinking so an array is 
>    a reasonable data representation?
> 
> question the only way a to change a position of a 
>    piece  is through rotation?
> 
> - so matrix mathematics to handle the rotations?

Easiest way to simulate something is to describe *exactly* what it is,
not some simplified impressions from afar. Have you had Rubic cube?
Have you breaken it up? What it is?

Rubic cube seemingly consists of exactly 8 corner positions and 12 edge
positions around central "fixed" cross. In such corner can be one of 8
unique corner pieces and each piece can be there in 3 ways. In edge can
be one of 12 unique edge pieces and each piece can be there in 2 ways. 

That means I would start with two arrays ... lets say 'Corner[8]' and
'Edge[12]' where 'Corner' and 'Edge' are appropriate records to hold
possible state of that corner or edge.
 
All the manipulations of it simply move pieces between positions, no
matrix algebra is needed there.

[toc] | [prev] | [next] | [standalone]

#6724

On 17/07/2016 15:39, Öö Tiib wrote:
> On Friday, 1 July 2016 12:21:12 UTC+3, G G  wrote:
>> where to start:
>>
>> a 3 X 3 X 3 array
>>    fixed sized not growing or shrinking so an array is
>>    a reasonable data representation?
>>
>> question the only way a to change a position of a
>>    piece  is through rotation?
>>
>> - so matrix mathematics to handle the rotations?
>
> Easiest way to simulate something is to describe *exactly* what it is,
> not some simplified impressions from afar. Have you had Rubic cube?
> Have you breaken it up? What it is?
>
> Rubic cube seemingly consists of exactly 8 corner positions and 12 edge
> positions around central "fixed" cross. In such corner can be one of 8
> unique corner pieces and each piece can be there in 3 ways. In edge can
> be one of 12 unique edge pieces and each piece can be there in 2 ways.
>
> That means I would start with two arrays ... lets say 'Corner[8]' and
> 'Edge[12]' where 'Corner' and 'Edge' are appropriate records to hold
> possible state of that corner or edge.
>
> All the manipulations of it simply move pieces between positions, no
> matrix algebra is needed there.

Lots of ways to do this.

I was going to have a go and would have started perhaps with an array of 
54 squares (for the 6 sides each of 3x3 squares) representing a fixed cube.

For each square there would need to be extra info on how it relates to 
the 0, 2 or 3 squares on the adjoining face with which it shares an edge.

Each square contains a value which is the current colour. Rotation 
involves transposing the values between the squares. (A bit like 
rotating an actual cube by peeling off the colour patches and sticking 
them elsewhere.)

Of course when you actually try and program it you will find out what 
works, what doesn't, and what you've forgotten to account for.

The OP might also want to model the behaviour of a physical cube, rather 
than just play with the logistics, which could need a different approach.

-- 
Bartc

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web