News:

  • August 22, 2026, 07:23:49 PM

Login with username, password and session length

Author Topic: H2 DM memory issue  (Read 8032 times)

amos

  • Full Member
  • ***
  • Posts: 39
H2 DM memory issue
« on: February 04, 2020, 11:33:38 PM »
I recently did an upgrade to a process with a domore and ran into the 256 limit on Memory Blocks. Is there any plan on increasing the limit? I guess if the Memory Blocks could be 2 dimensional I could get away with less than 50.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: H2 DM memory issue
« Reply #1 on: February 05, 2020, 09:05:24 AM »
If you need 2D arrays, emulate it with a 1D array.  This is how simple multi-dimensional arrays work in C, so this is common practice in the Computer Science world.

Say you want a 2D array of REALs called AR, 5 rows by 7 columns.  You would normally index it as AR[row#][col#].  AR is really just a block of memory containing 35 REALs (5 x 7).  The index lookup is where the power of multi-dimensional arrays works.

But it's easy to calculate a 1D index via a 2D row, column index.

I like to use symbolic constants in Do-more.  So create a symbolic constant for the number of COLUMNs in AR, e.g. AR_NUM_COL equal to 7.

Here's the simple formula for a 1D index (V99) from a Row value (say V0) and Column value (say V1).

Code: [Select]
V99 = (V0 * AR_NUM_COL) + V1

[R][C]
[0][0] is 0
[0][1] is 1
. . .
[0][6] is 6
[1][0] is 7
[1][1] is 8
. . .
[4][0] is 28
[4][1] is 29
. . .
[4][6] is 34

I'm sure you are using some kind of "lookup" with REFREAD/REFWRITE to generate a block # index (it may must be a simple MATH box, or a bunch of relational comparison/assignments, regardless)

This new array index calculation can be a simple index (not a block #):

MATH V42 "(V100 * AR_NUM_COL) + V101"  (replace V42/V100/V101 with your actual V array index values)

Then, simply index AR with V42 in any relational contact or instruction or wherever as AR[V42]

Here's a 2D FOR/NEXT loop to initialize all the values to a random number using RANDREAL() MATH function:

Code: [Select]
FOR V100 0 4  // row # 0..4, inclusive
  FOR V101 0 6  // col #  0..6, inclusive
    MATH V42 "(V100 * AR_NUM_COL) + V101"
    MATH AR[V42] "RANDREAL()"
  NEXT
NEXT

What's also good, is that the 2D array indexes can be anything - constants, D memory, a struct member, but the result 1D array index must be a V to be utilized in any instruction.  So, you could easily initialize the 2nd column (0-based column index 1) across all 5 rows to a Random number as follows:

Code: [Select]
FOR V100 0 4  // row # 0..4, inclusive
  MATH V42 "(V100 * AR_NUM_COL) + 1"  // the "+1" is the column index for the 2nd column
  MATH AR[V42] "RANDREAL()"
NEXT

or initialize the 3rd row to a random number (0-based row index 2):

Code: [Select]
FOR V101 0 6  // col #  0..6, inclusive
  MATH V42 "(2 * AR_NUM_COL) + V101"  // the "2 * " is the row index for the 3rd row
  MATH AR[V42] "RANDREAL()"
NEXT
« Last Edit: February 05, 2020, 09:09:38 AM by franji1 »

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6172
  • Yes Pinky, Do-more will control the world!
Re: H2 DM memory issue
« Reply #2 on: February 05, 2020, 12:41:20 PM »
And depending on how the second dimension is to be used, you might also be able to use a UDT.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

amos

  • Full Member
  • ***
  • Posts: 39
Re: H2 DM memory issue
« Reply #3 on: February 05, 2020, 08:44:45 PM »
Thank you franji1. Yes that could have easily worked. I'll have to think of that in the future. After all, all the memory blocks are less than 100 words long. I did look at UDT's too. It would have been a lot of work to change the design of the memory structure.
  Thank you for the replies.