Likely want to just skip down 10 or so posts if you stumble upon this thread, I had issues and nothing made sense. I have fewer issues now and I think things should become productive.

Normally this is pretty simple, but I need XYZ to wrap, so a 3x3x3 array counting in X would go 0,1,2,0,1... and in the Y it would go o 3, 6, 0, 3... and Z would be 0, 9, 18, 0, 9... Here is the simplified version of what I am currently doing to illustrate more clearly, Z is of variable size.

This works, but it means I have to do a great deal of conversion between XYZ and array index which complicates the rest of the patch. Working off array index and having a single counter incremented by the needed amount would greatly simplify the patch overall. I think I had this figured out awhile ago but I either did not save it or saved over it and now things are so messed up in my head I am not even certain this is a reasonable task. I will consider externals for this one, but I still want to know how to do it in vanilla if it is sane to do so.

Edit: That [mod 100] should be [mod 10], typo when I simplified the patch.
Edit: Not that it matters, those are not even my actual sizes, I just can not think straight on this any longer.
Edit: [v x] [v y] and [v z] would just be 1 or 0 if that was not apparent, think I should be done with edits now

@ddw_music and @ingox, I over simplified in my example patch and made almost as much of a mess of this thread as I have made of my patch. Your posts have actually helped by giving me some perspective/direction even if I sent you chasing my tail. Think I need to take a break before I attempt any more fixing.

@oid https://forum.pdpatchrepo.info/topic/12507/bang-issues

@ingox Haha. It would be more accurate if the bang moved as soon as the mouse got near so you could never click it.

@oid Haha, true.

@oid Here it is with a one step navigation on a range of zero to ninety-nine for x, y and z respectively:

3d-navigation.pd

But it seems somewhat unclear why the coordinates should be stored as a single value. It would probably easier to just keep them separate...

It is anyhow, at least in theory, possible to use an encoding that supports an infinite range. This would work like the diagonal numbering of the rational numbers when proving their countability (see https://en.wikipedia.org/wiki/Rational_number#Properties).

In 3d space the numbering would go along the surfaces of cubes of growing side length.

@ingox said:

It would probably easier to just keep them separate...

It is easier and that is exactly what I had been doing but it means that every time the array is accessed coordinates need to be converted, I can not avoid dealing with the array index, but if I can remain purely 1 dimensional for this counter I can almost eliminate all conversion. It is just so simple to do if you do not need to wrap in the X, Y and Z individually, just add the appropriate amount to the old index, done.

It is anyhow, at least in theory, possible to use an encoding that supports an infinite range.

What about a finite range? While Z is variable, practicality limits it so there is no reason not to impose a limit. I suspect the math here would be more costly than the conversions and that it will all be math I forgot sometime back around the turn of the century like your link.

I do not think we are quite on the same page yet, so best to wait for me to get a proper example/description up before responding.

OK, it turns out that both of the patches I posted DID work for me, the cause has been documented in the bang issues thread @ingox posted above for anyone interested. It really caused me some issues and I had no idea what was going on. Either PD or my computer had a major hiccup, things are sorted out but it took a good amount of time to fix everything that went off.

Here is an actually working example

xyz.pd
So, this properly shows how X Y and Z wrap around. I am trying to get rid of the need to convert the XYZ to the array index for every increment or vice versa, too increment the array index directly while maintaining the wrapping. You all may have understood what I was after, that bug had left me very very confused and had likely been causing me issues for a few days now. I will reread through the thread tomorrow after sleep and see if things make more sense.

Thanks for the help!

Finally getting back to this, ended up having to start over since what ever caused the duplicate wires left me questioning if it was patch corruption of just an error in my logic anytime something did not work as expected. Had to take a break before redoing that entire large patch from scratch, once I got away from the corrupt patch things came easily and I sorted it out.

This seems to do the trick, I have the nagging suspicion it can be further simplified but it works and greatly simplifies the rest of the patch.

Sanity has returned. You all tried to point me in the right direction, but I seemed to have been rather fixated.