kdb+k

Converge (fixed point) syntax difference in q and k


We should use square brackets when flattering all levels in list:

q)b:(1 2;(3 4;5 6);7;8)
q)raze/[b]               / flatten all levels
1 2 3 4 5 6 7 8
q)raze/b
'/
  [0]  raze/b

But why one forced to use raze/[b] for Converge syntax instead of simple raze/b?

Why this syntax works in k, for example {x+y}/1 2 3 but doesn't work in q?

My assumption that it's been made to prevent qbies errors when using / adverb instead of %. I think there may be a discussion about it in some dev channel, but I've found only Shakti discussion group for now at https://groups.google.com/forum/#!forum/shaktidb, and kx.com also shutted down community wiki, so I don't know where to find an additional info - asking here

The / is quite overloaded in k too: see (not official ref though) https://github.com/JohnEarnest/ok/blob/gh-pages/docs/Manual.md#over - over, fixedpoint, for and while. Pretty the same as in q, right? But why the interpreter 'ban' the k syntax in q context, - is there a technical reason why q can't recognise a user intention as it k does?


Solution

  • The reason that, say, cos/1 works in k but not q is that q has no ambivalence. That is to say that all q operators are not overloaded on valence, as noted in section 6.1.2 in q4m.

    With any of q's adverbs (each:', over:/ scan:\, prior::, eachright:/:, eachleft:\:) the resulting derivative function is interpreted by q to be dyadic, unless you uses []'s to specifically pass one argument.

    For the example above q interprets cos/ as do rather than converge and so requires the left argument specifying the number of iterations (Note the results of 0 cos/ 1, 1 cos/ 1, 2 cos/ 1, etc.). The preferred way to resolve is to use []'s: cos/[1].

    (cos/) 1 works because user defined functions can never use infix notation, so the expression is automatically interpreted as applying monadically. This is also why 2 (cos/) 1 fails. To resolve this you would again have to use []'s: (cos/)[2;1].