3 ms·

Not op, but I assume it means that there's rank polymorphism (i.e. data can be of arbitrary dimensions, and there's support for things like functions working on

Not op, but I assume it means that there's rank polymorphism (i.e. data can be of arbitrary dimensions, and there's support for things like functions working on both N-dimensions, without having to specify n, or maybe setting constraints on n), and that the polymorphism can be used on the programmer side (so it's not limited to just a handful of language builtins) through the oop equivalent of subclasses and interfaces.

goldenCeasar 1y ago
A question, would you interpret this as rank polymorphism? schema do input do array :regions do float :tax_rate array :offices do float :col_adjustment array :employees do float :salary float :rating end end end end trait :high_performer, input.regions.offices.employees.rating > 4.5 value :bonus do on high_performer, input.regions.offices.employees.salary * 0.25 base input.regions.offices.employees.salary * 0.10 end value :final_pay, (input.regions.offices.employees.salary + bonus * input.regions.offices.col_adjustment) * (1 - input.regions.tax_rate) end result = schema.from(nested_data)[:final_pay] # => [[[91_000, 63_700], [58_500]], [[71_225]]]
- CraigJPerry 1y 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 1y ago
    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 1y ago
      Just had a quick browse of the kumi readme - very cool, i like it
      - goldenCeasar 1y ago
        That means a lot, thanks!
- npalli 1y ago
  I didn't downvote but was utterly puzzled with your example. After your response below, it occurs to me that you are confusing Employee rank (a business concept) with Array rank a mathematical concept. Either that or it is very strange explanation for rank polymorphism.

goldenCeasar 1y ago

A question, would you interpret this as rank polymorphism? schema do input do array :regions do float :tax_rate array :offices do float :col_adjustment array :employees do float :salary float :rating end end end end trait :high_performer, input.regions.offices.employees.rating > 4.5 value :bonus do on high_performer, input.regions.offices.employees.salary * 0.25 base input.regions.offices.employees.salary * 0.10 end value :final_pay, (input.regions.offices.employees.salary + bonus * input.regions.offices.col_adjustment) * (1 - input.regions.tax_rate) end result = schema.from(nested_data)[:final_pay] # => [[[91_000, 63_700], [58_500]], [[71_225]]]

CraigJPerry 1y 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 1y ago
  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 1y ago
    Just had a quick browse of the kumi readme - very cool, i like it
    - goldenCeasar 1y ago
      That means a lot, thanks!
npalli 1y ago
I didn't downvote but was utterly puzzled with your example. After your response below, it occurs to me that you are confusing Employee rank (a business concept) with Array rank a mathematical concept. Either that or it is very strange explanation for rank polymorphism.