# Thread: Like Sudoku, but not.

1. ## Like Sudoku, but not.

1. You have a square of N*N.
2. Any cell can only have one of four values: 3,2,1 and 0.
3. A cell and it's neighbors in (row-1,row+1) or (col-1,col+1) must equal 5.

I want to fill N*N randomly with the above rules. I have a problem though, I think that once I enter the first three values, the entire grid fixed. Consider:

30???????
1????????
?????????
..

The first same-row and first same-column will determine the entire array. I am hoping this isn't true. Does anyone see any flaw in this? What I really want to do is just randomly start scattering values around, and eventually merge it to fit the rules. But I don't think it's possible.

302...repeating
122...repeating
131...repeating
...repeating

Now we don't always end up with that exact 3x3 block repeating. For example, I could have done:

31...
2...
...

But then I would have had another fixed pattern. Basically, pick any spot, and left+right+here = 5, up+down+here = five, and any other random spot has to do the same. From anywhere, anything you can reach from 2 hops in a straight line from where you are, counting where you are, is five.

If I had taken the start of the second pattern block, and stuck it at [X10,Y10][X11,y10][X10,y11] for the three numbers, it would be impossible for it to merge with the first pattern, due to the trio locking you into whatever pattern, right?

Showing a failure for the two patterns to ever merge:
Code:
```302???????????
122???????????
131???????????
??????????????
??????????????
??????????31??
??????????2???```
Now I cheated a bit here for the sake of fitting this on one screen. But I don't think it's possible for that red block to be a part of this grid, having entered the green blocks first.
[/edit]

[edit2]
Actually, it's more like: The first two consecutive numbers lock the third. The first three consecutive numbers are forever locked. The first horizontal lock and vertical lock lock the 3x3 set. The locked set locks the entire array. See:

3cc
r
r

I have 11 or 02 or 20 as possible options for rr or cc. But once I pick one, I'm screwed. There will be lucky coincidences, and I can get it down to 1 garbage space, but I need zero garbage spaces. I was also hoping to actually get more than a 3x3 block repeated. I was trying for huge blocks, but it looks like that's just impossible with the rules I have.
[/edit]

Am I missing anything obvious here?

Quzah.

2. Can you expand the acceptable input set to include negative variants, ie -3, -2, -1?

3. Not really. What I'm actually trying to solve is a three color problem. It's sort of complicated (at least for me it is). I'm actually trying to split a sphere of undetermined size into three equal parts. The easiest way for me to look at this was a 1d12. Each color gets four sides on a d12. I used Red, Yellow and Blue. Then what I did is I counted the sides that touched of any given side, and converted that to a color. Each side of a d12 has five edges, with one of three possible colors.
Code:
```1d12 = 4 sides each color

color    - clock - number
sorted      wise   values
------------------------
1 RRRYY - RRRYY - 320
2 RRYYB - YBRRY - 221 ? 311
3 RRRBB - BBRRR - 302
4 RRYBB - RBBYR - 212
5 RRYBB - YBBRR - 212 ? 113
6 RRBBB - BBBRR - 203
7 BBBYY - YYBBB - 023
8 RYYBB - YYRBB - 122
9 RYYBB - RYYBB - 122 ? 131
10 YYYBB - YYYBB - 032
11 RRYYY - RRYYY - 230
12 RRYYB - YRRBY - 221

311? we don't have these because
113? we are using a 1d12
131? and coloring connectors```
So, a given side is colored based on its number above. For example, side 1 is 3 parts red, 2 parts yellow, 0 parts blue. What I really want to do is have a sphere of any size, split into three equal pieces, with a nice way to move about its surface. The problem is that spheres are terrible for movement. The problem with that is that I want the sphere to have no defined size. I want an undetermined amount of space for each side, equal, but undetermined.

The reason I think I need a sphere instead of a grid, is because grids are a pain in the ass to split three ways. Hell, everything's a pain in the ass to split three ways. I thought about doing a 3D array, and each axis belongs to a color, but I'm not sure if that will work. It's probably what I'm going to have to do, since this isn't working. I think it's what I'm about to be stuck with.

The problem with this is that, if I am on the north pole, and we call that axis Z, then we split the earth with 2 more axis, one through say, what Panama, to wherever the other side of the world is, and then another around ... what's half way between Panama and the other side of the world? Egypt?, through the otherside of THAT ... and if I assign red to the north-south axis, and blue to Egpyt, and Yellow to Panama, and I travel through the earth up and down a tunnel drilled through the north and south poles, what color is changing? The amount of red?

Well if I'm on the red axis, then I should be 100% red, and 0 blue/yellow? Does that seem right? Then the only way I'd pick up any color is if I moved in either direction along their axis? I guess that's working right.

What I really need to do is to map 3 axis to 2d space.

Quzah.

4. I suppose we could just move this to game programming, since it's not actually C related. Force of habit.

Quzah.

5. Moved.