2D Arrays

[Controls Guy]

So I'd like to build a 2D array of bits, addressable for both dimensions.  I don't believe we can (yet) build 2D data blocks, but have to build 1D arrays of standard types.  So since I can access individual bits in integer types (though not quite as easily as indexing), I can in effect get a 32 x n array by doing an n-element array of DINT's.  That works OK for what it is, but I want the short dimension to be more than 32, possibly in the 100-200 range.  I haven't yet come up with a way to do this that I like.

Maybe a 1D array of strings and MEMCOPY in and out?

[plcnut]

I ran a little test just to see... and it worked perfectly!
I made a String of 32 Characters, and the bits in, and bits out of 512 bits each.
Here are my screenshots:

[franji1]

Using the REF(block#, index) MATH function and REFWRITE value, block#, index instruction, you can implement 2D arrays.

Create a set of Data-Blocks, one for each "column".  User block numbers will start at 32, but if you already have other user blocks, it may be higher.  Regardless, create all of them contiguously.  Attached is an example where I created 4 Columns' worth of bits, ColA, ColB, ColC, and ColD.

The Data-Block's block number is the "Block#" in the two instructions above.  So you would use an "index" of 32 for the "column" index for ColA, 33 for ColB, 34 for ColC, and 35 for ColD.

Hence, you could easily use V0 and V1 as your two 0-based array indexes, but then use V2 as the Block Number calculated from V0+32 in a MATH:

MATH V2 "V0 +32"

If you are doing Boolean logic, you could easily do that in MATH instead of LADDER using the Boolean && || and ! operators:
MATH C100 "REF(V2, V1) && REF(V2, V1+22) || !REF(V2-1, 0)"  // yes, the REF parameters can be expressions, so you could just use V0+32 as the sub-expression for the block#

or to write the value of C100 into a 2D reference:
REFWRITE C100 V2 V1

[franji1]

I ran a little test just to see... and it worked perfectly!
I made a String of 32 Characters, and the bits in, and bits out of 512 bits each.
Here are my screenshots:

You do NOT want to do this with STRINGs.  MEMCOPY is a low-level memory copy.  So for STRING's it's a simple way to do bulk transfers of STRINGs of the SAME MAXIMUM LENGTH into/out of bulk storage.  The bit values would be writing over the .MaxLen and .Length structure members, causing extreme side effects.  Hence, do NOT use MEMCOPY Strings with actual used memory (e.g. a set of bits that are read/written).  Use MEMCOPY for copying to other STRINGs or into (say) D or V memory as bulk storage that you will later move back into STRINGs of the same MAX LENGTH.

SS0-SS9 (10 64 char STRINGs) => D100-D269 OK (do not manipulate D100-D269)
D100-D269 => SS10-SS19 OK, because D was sourced from STRINGs of MAXLEN 64 characters
D100-D749 => SL10-SL19 (10 256 char STRINGs) NOT GOOD! because the strings in D memory were a byte by byte copy of 64 character STRING structures (including the .Length and .MaxLen values), but are being written into memory expecting 256 character strings.  Note how the 10 LONG strings calculated the expected D memory buffer range to go from D100 to D749, NOT D269 like the sourcing MEMCOPY instruction.

I added a screenshot of this example so you can see where I get my D ranges from.

[franji1]

So, in lieu of MEMCOPY, just use the STRGETB - String Get Bytes Out of a String and STRPUTB - String Put Bytes Into a String

[plcnut]

Makes perfect sense on the Strings and MEMCOPY Mark, I could see that causing some real problems.
I tried using REF and REFWRITE in the early days of Domore, and could not get it to work properly (that was in my "buggy" days , maybe it will work better now with a clean fresh CPU.
The other limitation I ran into, was the number of user blocks I am allowed to make...

Are there any plans to implement 2D/Multidimensional arrays?

[franji1]

Are there any plans to implement 2D/Multidimensional arrays?

Currently no, but we can add it to our list of Potential Future Features.

[Controls Guy]

What I’m actually trying to do, as I’m sure you’re aware, is use strings for indexed bulk archival storage of regular memory, not the reverse.

I should have chosen my words with more care.  By “MEMCOPY” I meant “type-agnostic memory copying”, forgetting there were separate instructions to do that with strings.

I’m still a little unclear on why I couldn’t use strings in this way, so long as I don’t overwrite the .MaxLen member position while the block is in regular memory.  Your example assumes that memory originally retrieved from 10 SS’s would end up getting written to 10 SL’s, which would definitely cause problems, but why would anyone ever do that in the first place??  It would violate the entire concept of the scheme.  No matter, as STRGETB/PUTB should do just what I’m looking for.  REF/REFWRITE looks like it would also work, but I think I’d end up needing more user memory blocks than with strings and STRGET/PUTB.  I’ll play around with it.  REF/REFWRITE obviously a powerful tool and I need to use it enough so it comes to mind when I’m trying to do things like this.

Thanks for the guidance!