Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #6724
| 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> |
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
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