Creation of Data Block as 2D Array

[Controls Guy]

I want to create a 2D data block, and the only way I can think to do it is to create a UDT for the second dimension with enough elements for the second dimension, then create an array of that.   So then the elements of the UDT have to have names, which means the final syntax is like MyBlock[1].Fld2, as opposed to MyBlock[1][2] or something like that.   Is there a way to get a generic unnamed second dimension?

[RBPLC]

See recommended approach:
https://forum.hosteng.com/index.php?topic=2773.msg22378#msg22378

[Controls Guy]

Yeah, I remember that way, but since then there was some official support for multi-dim arrays and I couldn't remember if it was arrays of UDTs that were themselves in effect arrays or if there was something more direct.

[RBPLC]

Yeah, I remember that way, but since then there was some official support for multi-dim arrays and I couldn't remember if it was arrays of UDTs that were themselves in effect arrays or if there was something more direct.

Direct support of multidimensional arrays (2-D at least) needs to happen.

[franji1]

N-dimensional arrays can easily be done via a single dimension array.  Oh, and it works with a block of UDTs (not just built-in types).

The C programming language has been doing this since the 70's.  Just write a subroutine or a MATH box to do the calculation.

Believe it or not, the MATH box will be MUCH faster than anything we have to do "natively" since the "native" must be implemented generically.  So if you don't mind slow array lookups on a 5 dimensional array, we'll implement it "natively" also. 

[Controls Guy]

Believe it or not, the MATH box will be MUCH faster than anything we have to do "natively" since the "native" must be implemented generically.  So if you don't mind slow array lookups on a 5 dimensional array, we'll implement it "natively" also. 

OK, let's do that! Actually, just trying to abstract it one more level for mental-model's sake, and not worrying too much about speed.  Having it as an option would be ideal because you can choose between syntax and speed.

[rlp122]

So if you don't mind slow array lookups on a 5 dimensional array, we'll implement it "natively" also. 

Personally I don't mid it being a bit "slow".  I write programs to be readable by a third grader if possible.  I'd rather give up a bit of speed and avoid phone calls than have someone calling every ten minutes going; "What's this do???"

[BobO]

There are real and varied structural limits in how we reference image register. Changing that would be hard.

If we eliminated the requirement that the data be stored in image register, or more specifically, that it be referenceable as image register, we have a great deal of flexibility. The answer to that is tables, which we've mentioned before. I think we are going to do that.

Some thoughts on tables...
1. A table is a 1 to n dimension collection of simple or complex data elements.
2. There may be the ability to have small tables in retentive memory, but generally they will live in non-retentive bulk ram.
3. There will be a normal heap item associated with each table. It will contain stats on the table, and likely some private data with implementation details.
4. I'd expect multiple forms of table: FIFO, LIFO, sorted, multi-dimension array, etc. TBD.
5. There will be multi-scan instructions for adding, inserting, removing, etc records from tables.
6. There will be standalone instructions for reading and writing records, as well as MATH box functions for the same. In general, record read/write access is single scan blocking, while the instructions from #5 are generally multi-scan non-blocking. Unsorted append might be an exception.
7. We are thinking the MATH box grammar might be something like MyTable{dim1exp, dim2exp, ..., dimnexp} and would have both l-value and r-value variants. Using the curly brace would help in the parsing, and make it easy to discern table access from function calls.
8. Because table entries aren't normal image register, comm/status would be provided through a difference mechanism, but we should be able to provide reasonable access.
9. TBD...