This may seem strange, but, I need an idea on how to read a one dimensional array as one which is 3-d and toroid (doughnut like).

This starts with my "Game of life" patch in the #pixel forum, which I now realize is flawed.

I have a table, say 32 points, which I 'fold' to represent an array which is 8X4. Now, I can read the array as a three dimensional one with some pretty simple counters. The process of Conway's game requires me to find the sum of all neighboring cells, or points, which have boolean values. So, if I am interested in updating the status of cell whose location in the grid is 1-0, I [tabread] the table at point 8. The problem is in reading the states of the adjacent cells. If i want to read the cell 'to the right' of point 8 (n) I just increase the [tabread] index by one, giving me point 9 (n+1). Same goes for above and below, except I subtract or add the length of the row: (n-8) or (n+8) respectively. *BUT* If I need to point BEFORE cell eight, I have to wrap the counter to give me the point at the 'right end' of the row. This goes the same for cells 'above' and 'below' those in the 'top' and 'bottom' rows, and to the 'right' and 'left' of cells in the finite columns.

So I think I need some fancy math using [wrap] to spit out a list of eight positions in the array, corresponding to the eight 'neighbors' of the cell whose fate I am trying to decide. Does this make sense? Is this a good opportunity to learn PERL or PYTHON?

--Nestor(tired)

any reason is a good reason to learn perl or python. But if you use a base 10 grid size, you can avoid any hard math. And if you can deal with the hard math, then by switching numeral bases, any n dimensional space represented in one d is easy.

so imagine you want a 2 dimensional 10 wide space. 1 dimensional array 0 99. who are the neighbors of 42? 32, 52, 41, 43. those are the direct neighbors. -10 +10 -1 +1. If you want the catty corner dimensions, add +11 -11 and +9 -9 too. Three dimensions +-100 +-10 +-1 +-101 +-110 +-11 +-99 +-9. Works for any dimensions (anyone care to proof/disproof?)

so thatways, representing a 10x grid in 1d is cakey. So is an 8x unit for your space. but instead of thinking 64, think 100. instead of thinking 42 think 52. Instead of thinking 23 think 27. Perl or python comes in handy. for instance:

#!/usr/bin/env python

def rebase (baseten, newbase):
mod = baseten % newbase
div = baseten / newbase
if div > 0:
mod = str(rebase(div, newbase)) + str(mod)
return int(mod)
rebase(64,8)
rebase(42,8)
rebase(23,8)

That's how easy python can be. I'm sure a real python scripter would have a much cleaner script than this, OC. this rebase can't generate hexdecimal, for instance.

Hey, if you want any help with the scripting, or whatever, I'd be happy to contribute code for a ndimensional game-of-life.

sunji

Right, I think that this is how I am thinking already. The problem is: In my current system, if I am at position 31(7,7), and I try to get the neighbors, using +1, -1, +8, -8, I get: 0(the counter is wrapped with a [mod 32]) 30, 7, 23. As you can see, this is incorrect, the 0 should be 24...

I think I can figure this out, but, I want to avoid 'hard-coding' the wrapping of the table. Luckily, I have lots of coffee on hand.

Okay, here's a hard-coded example. I just applied an x-y scheme to addressing the table, so a message of [0 0( does the the trick.

http://www.pdpatchrepo.info/hurleur/conway_seq.pd

i had the same probleme

if + value
v=(v+value)%size
if - value
v=(size+v-value)%size

for example for -8 with 7
v=(32+7-8)%32 = 31

HK

I seem to be getting:

error: 3-$3-r: no such object
error: 0-$3-r: no such object
error: 1-$3-r: no such object
error: 3-$3-r: no such object
error: 0-$3-r: no such object

when I try to step it. It's not a searchable error, and I can't find them searching the text. They are constructed s-r pairs somewhere in the patch? Is this error related to the ndimensional discussion at hand?

Weird, still works for me, that error must be generated by the message in the subpatch conwaycount: ;$2-$3-r $1

The receiving end is the toggles.

the $2-$3 syntax requires a fairly recent Pd, older Pd only substitutes the first $2. the solution for old-Pd is ugly (using makefilename etc) - just upgrade to newer Pd is my recommendation.

heh, i'm still a 3.9 geezer. The conway game of your's is great, Nestor. Would you mind if i employed it in an upcoming perfrormance? i'll credit you, of course.

@sunji said:

heh, i'm still a 3.9 geezer. The conway game of your's is great, Nestor. Would you mind if i employed it in an upcoming perfrormance? i'll credit you, of course.

Of sourse Sunji, I'd be honored. I am not actually sure that it is 100% accurate, due to order of execution problems, but I've put it on the back burner for now. I'll actually be 'gigging' with it next week as well.

my show's not til early october. i've been mapping the lifegame to a cylinder and then merging it with the trunk of a tree, so the tree appears to have living bark. Im' also going to be using the table as a filter source, but I haven't quite got the parameters matched up yet.

Sounds Cool.

The problem with it as it stands now is that each cell is written in order; most implementations use two arrays, I've been working on a way to process the whole array all at once, bouncing the outcome to another array, and then bouncing back.

"i've been mapping the lifegame to a cylinder and then merging it with the trunk of a tree, so the tree appears to have living bark."

you guys are doing some really cool interesting stuff!

Hate to correct you hardoff, but you are still the king of interesting stuff. But I'm sure gonna post it to my site as soon as it's performed, then y'all can judge.