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


Groups > comp.programming > #6724

Re: Rubik's cube

From BartC <bc@freeuk.com>
Newsgroups comp.programming
Subject Re: Rubik's cube
Date 2016-07-18 00:39 +0100
Organization A noiseless patient Spider
Message-ID <nmh4vi$86q$1@dont-email.me> (permalink)
References <4c721d5f-f64e-4d2e-aabb-a49bf5588075@googlegroups.com> <7bfddf49-951b-4f4d-ae90-86c500122d22@googlegroups.com>

Show all headers | View raw


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

Back to comp.programming | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

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

csiph-web