Using Key operator to make a game but need more tree depth to create a more complex tree

Question

I am working on a game using the Key operator to create simple parent tree nodes connected with children. Like (1 3 2 7 11 12) with 1 as a parent node and 3 2 7 11 12 children. The array has all the information via Key to create the nested array. Of course its extremely fast. But I actually need 2 or 3 more depth. I can create a different tree construction shown on the 'same' array - second image. This different encoding (1 2 1 1 2 3 1 3 3.....) allows arbitrarily nesting vector depth and works perfectly. - with just a simple array.

There could be enough information with the Key transformation on the array then more code to connect the children nodes - for needed depth. Are there any same or similar APL/Co-dfns for (1.) transforming the array into the tree (2.) - and back? I am new to APL and focusing on the rectangular. Tree wrangling is down the road. I need almost the same for Key speed due to very long arrays and their nested arrays.

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
   1 2 1 1 2 3 1 3 3  3  1  1  2  7  8  9 16  4 

Using Key:
{⊂⍵}⌸1 2 1 1 2 3 1 3 3 3 1 1 2 7 8 9 16  4
(1 3 4 7 11 12) (2 5 13) (6 8 9 10) (14) (15) (16) (17) (18) 

Using maybe Key and something else....

     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
1.   1 2 1 1 2 3 1 3 3  3  1  1  2  7  8  9 16  4

2. (1 3 4 (7 14) 11 12) (2 5 13) (6 (8 15) (9 (16 17)) 10) (,18)




1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
1 2 2 2 2 2 1 7 8  3 10 11 10 10 10 15  9  
(different array for same tree encoding)

(1(7(8 (9 17)))) (2 3 4 5 6) (10(11 12) 13 14 (15 16))

({⊂⍵}⌸⍠ 2) 1 2 1 1 2 3 1 3 3 3 1 1 2 7 8 9 16 4

Perhaps using Variant on Key down the road?

Answer 1

There are some ways to do this, but the best method will depend on what you want to do with the results. If you really do have very large arrays, then producing the "nested children" representation of arrays is going to be expensive no matter how you compute them, because the underlying representation is expensive (though, no more expensive than the same sort of representation in another language).

Section 3.2 of (Hsu 2019) discusses this in detail:

"A data parallel compiler hosted on the GPU". Hsu, Aaron W. https://scholarworks.iu.edu/dspace/handle/2022/24749

Generally speaking, if you intend to work with the data in some way, it is almost always faster and easier to work directly with the parent vector or depth vector representation instead of first converting to a record-type style representation.

One technique is to query the data in parent vector form first, to identify the relevant nodes over which you intend to work, and only then to extract the children nodes for that limited set using primitives like membership (∊) or where (⍸).

If you can describe the sort of operations you intend to perform over these nested representations, there might be a better algorithm that does not require the conversion.

If you do wish to simply create the full record-type representation, there is some conversion code in (Hsu 2019). You can also look at the P2D and D2P functions in the Co-dfns compiler:

https://github.com/Co-dfns/Co-dfns/blob/master/src/codfns/P2D.aplf

https://github.com/Co-dfns/Co-dfns/blob/master/src/codfns/D2P.aplf

These may give you some additional help in converting between the formats.

If you need to convert directly between the parent and record-type representation, you can use something akin to this:

kids←{0=≢k←⍸p=⍵:⍵ ⋄ ⍵,∇¨k~⍵}¨

And apply it to the root nodes of your tree like this:

kids ⍸p=⍳≢p

where p is your parent vector.

There is also the child vector representation:

      p
0 1 0 0 1 2 0 2 2 2 0 0 1 6 7 8 15 3
      ⊢k←(p=⍳≢p)↓¨k⊣k[p],←⍳≢p⊣k←(≢p)⍴⊂⍬
 2 3 6 10 11  4 12  5 7 8 9  17      13  14  15              16     
      0⊃k
2 3 6 10 11
      k[0⊃k]
 5 7 8 9  17  13     

I hope this helps!