Remix.run Logo
CraigJPerry 8 days ago

I think i'm misunderstanding, rank is explicit throughout this example but i'm not familiar with this syntax (ruby maybe?) but whatever the case i don't see the rank polymorphism.

If i'm reading the syntax correctly, this would translate in kdb/q to a raze (flatten) on the 3 dimensions (regions, offices, employees). Probably more likely to be expressed as a converge but in either case, the calculations here are not possible in a rank polymorphic way.

goldenCeasar 8 days ago | parent [-]

The broadcasting handles the rank differences automatically. When bonus (at employee level) multiplies with col_adjustment (at office level), each employee's bonus gets their office's adjustment applied, no flattening or manual reshaping. The structure [[[91_000, 63_700], [58_500]], [[71_225]]] was preserved.

This is from a Ruby DSL I'm working on (Kumi). Probably the broadcasting semantics are very different from traditional rank operators in q/APL?

Edit: I realized that I missed the input structure:

  Region 0: Office 0 has 2 employees, Office 1 has 1 employee
  Region 1: Office 0 has 1 employee
CraigJPerry 8 days ago | parent [-]

Just had a quick browse of the kumi readme - very cool, i like it

goldenCeasar 7 days ago | parent [-]

That means a lot, thanks!