5 ms·
I use both. R is slow as a dog, Q/KDB+ is (almost) as quick as C. R is ugly, Q/K is beautiful and elegant. R has a wealth of open-source packages, Q not so m
by gd1 11y ago
I use both. R is slow as a dog, Q/KDB+ is (almost) as quick as C. R is ugly, Q/K is beautiful and elegant. R has a wealth of open-source packages, Q not so much.
Best solution is to do most of your work in Q and call into R when you want to use a package. The R integration works well, see http://code.kx.com/wiki/Cookbook/IntegratingWithR http://code.kx.com/wiki/Cookbook/IntegratingWithR.
The reality is that if you are using (and paying for) Q/K, you are likely doing so because you're dealing with billion+ point datasets. At least. R just melts and falls apart at that kind of size (without using native code, which isn't really R then is it?). So I often end up just translating R functions into K equivalent, and just using R for the nice-to-have features like latex/brew/ggplot/etc.
- wrp 11y agoGood comments. The way I have viewed the role APL languages is that you use a general purpose language to do everything up to the point where you have a clean data array, then send it to APL for array juggling, then take the result back into the GP language for all follow-up tasks. Does this sound like the workflow for Q/K and other APL language users? My reading of IBM's APL2 literature is that they intended this workflow with Tcl as the GP language. The two big things I'm trying to get here are a comparison of how APL-family compares to R in that role and in reaching beyond that role to handle the stuff before and after.