Entries in k (2)

I know k sits under q. By porting q code to k, will it run faster?

No. The interpreter boils it down to the same bytecode.

Consider Problem 1 from Project Euler: sum the multiples of 3 and 5 which are less than 1000. You may want to try this before reading further. The problems from Project Euler are great exercises for learning q!

The code below shows one solution written in both languages; f is written in q, while g is written in k.

q)f: {(+/) distinct where (0 = x mod 3) | 0 = x mod 5}
  g: {+/?&(0={x-y*x div y}[x;3])|0={x-y*x div y}[x;5]}

You can see the bytecode for a function (as well as some generally more useful information, like the function's arguments) by calling value on it:

q)value f
k){x-y*x div y}
"{(+/) distinct where (0 = x mod 3) | 0 = x mod 5}"

As you can see, when passed a function, value returns a list. The first element of that list is the function's bytecode. Now it is easy to show that f and g have the same bytecode:

q)first value f
q)first value g
q)all (first value f) = first value g

In q, however, you probably would have written the solution a tiny bit differently:

q)f: {sum distinct where (0 = x mod 3) | 0 = x mod 5}

This results in a q version that is actually two bytes smaller and (maybe) a hair faster:

q)first value f
q)first value g
q)\t do[100000; f til 1000]
q)\t do[100000; g til 1000]

Thanks to Charlie Skelton from kx for pointing out errors in the original version of this article.

Is the q language simply syntactic sugar on top of k?

Not really. There's been a meaningful expansion in the language to support tables and such. If you are curious, take a look at the code in $QHOME/q.k, it will help you understand what portions of q are implemented natively vs in k.