Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

32 bit version of KDB+ is now free for commercial use

kx.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: 32 bit version of KDB+ is now free for commercial use

#21

Post by silentbicycle »

rcxdude wrote: post #19
tiredandgrumpy wrote: post #13

Earlier quoted context omitted.

If you look closely at it, there's not much there - it's actually easy to understand - defines a variant struct and an bunch of accessors to the different types within the embedded union. He prefers short names, and finally years later, java recommends short variable names for lambdas too!

Short names make sense if they are easily understandable locally: This means either something extremely common throughout the codebase (I think the most common example being localisation wrappers for string literals. They should ideally be linked to a more clear explanation easily, e.g. from renaming import statements), or defined (clearly) and used only within a very small area of code. This API is neither of those.

Short names also make sense if the same conventions appear over and over throughout the code base. While they can be quite opaque at first, they're very consistent, and people with experience in other APLs will recognize many of them.

Re: 32 bit version of KDB+ is now free for commercial use

#22

Post by igorii »

ryanobjc wrote: post #20
tiredandgrumpy wrote: post #13

Earlier quoted context omitted.

If you look closely at it, there's not much there - it's actually easy to understand - defines a variant struct and an bunch of accessors to the different types within the embedded union. He prefers short names, and finally years later, java recommends short variable names for lambdas too!

So, I guess I need to look closer than the pixels then: typedef struct k0{signed char m,a,t;C u;I r;union{G g;H h;I i;J j;E e;F f;S s;struct k0 k;struct{J n;G G0[1];};};} K; Sorry I guess I'm just not seeing the "not much there and actually easy to understand" Whatever a 'H' is

It definitely is strange to look at, but it's quite easy to understand if you know k/q.

H is a short in k/q, so H refers to a short here as well. This naming scheme is true for all of the above letters.

Re: 32 bit version of KDB+ is now free for commercial use

#23

Post by oddthink »

jmnicolas wrote: post #9

Except financial applications what is it good for ?

It's great for basic data-analysis tasks, where you just want to slurp in a few CSV files, join them together, filter out some rows, and spit out the results.

Sure, you can do the same in R or python, but the whole process is very quick and easy in q.

Re: 32 bit version of KDB+ is now free for commercial use

#25

Post by tiredandgrumpy »

ryanobjc wrote: post #20
tiredandgrumpy wrote: post #13

Earlier quoted context omitted.

If you look closely at it, there's not much there - it's actually easy to understand - defines a variant struct and an bunch of accessors to the different types within the embedded union. He prefers short names, and finally years later, java recommends short variable names for lambdas too!

So, I guess I need to look closer than the pixels then: typedef struct k0{signed char m,a,t;C u;I r;union{G g;H h;I i;J j;E e;F f;S s;struct k0 k;struct{J n;G G0[1];};};} K; Sorry I guess I'm just not seeing the "not much there and actually easy to understand" Whatever a 'H' is

This convention is used within the type system throughout kdb+. i for 32bit integer, j for 64bit int, h for 16bit int, e for real, f for float etc. Anyone who knows q will automatically recognize these types in the the c-api. They'll also recognize the ref count r, the type t and experienced c programmers will recognize the trailing array idiom.

Re: 32 bit version of KDB+ is now free for commercial use

#26

Post by beagle3 »

ryanobjc wrote: post #20
tiredandgrumpy wrote: post #13

Earlier quoted context omitted.

If you look closely at it, there's not much there - it's actually easy to understand - defines a variant struct and an bunch of accessors to the different types within the embedded union. He prefers short names, and finally years later, java recommends short variable names for lambdas too!

So, I guess I need to look closer than the pixels then: typedef struct k0{signed char m,a,t;C u;I r;union{G g;H h;I i;J j;E e;F f;S s;struct k0 k;struct{J n;G G0[1];};};} K; Sorry I guess I'm just not seeing the "not much there and actually easy to understand" Whatever a 'H' is

Well, it is kind of pointless to look at the KC interface without knowing K. If you read the Python.h it would be about as understandable (assume you don't know what a "class" is when studying the Python.h file - because K does a lot of things in ways different enough from most languages).

To elaborate: K uses one letter mnemonic codes for all of it's basic storage types:

    G = General = 8-bit unsigned int
    H = sHort = 16-bit signed int
    I = Integer = 32-bit signed int
    J = bigger integer = 64-bit signed int
(Note how G,H,I,J follow each other?)

    E = 32-bit floating point "rEal"
    F = 64-bit Floating point
(Again, they are near each other)

    S = Symbol
    K = "general list type", the central K language type
And that's mostly it; the last unnamed union (with fields "n" and "G0") is for vectors, n being the length and G0 being the data.

The only other field you are ever going to need is "t" for type (saying whether which union member is actually in use). The rest are internal implementation details, but are also easy to remember: r=reference count; u=flags; m and a have something to do with memory mapping and allocation).

There are a few more basic types: b=boolean, t=time,d=date,p=datetime,u=month - but they are merely different interpretations of the EFGHIJSK members above; to access data from C, all you need is the list given above.

Re: 32 bit version of KDB+ is now free for commercial use

#27

Post by kthielen »

Careful with these guys. I once built an open source implementation of the q language, and these guys immediately threatened to sue me, my employer, and our clients. The language is not that interesting, it's easy to reproduce, and these guys will threaten you if you prove this.

Re: 32 bit version of KDB+ is now free for commercial use

#28

Post by juziozd »

tiredandgrumpy wrote: post #13
miecio13 wrote: post #12

I'm not sure about the Q language, but their C API reads like obfuscated C contest entry: http://kx.com/q/c/c/k.h

If you look closely at it, there's not much there - it's actually easy to understand - defines a variant struct and an bunch of accessors to the different types within the embedded union. He prefers short names, and finally years later, java recommends short variable names for lambdas too!

This is my favourite:

  // remove more clutter
  #define O printf
  #define R return
  #define Z static

  ...
Removes clutter indeed... :)

Re: 32 bit version of KDB+ is now free for commercial use

#29

Post by tiredandgrumpy »

kthielen wrote: post #27

Careful with these guys. I once built an open source implementation of the q language, and these guys immediately threatened to sue me, my employer, and our clients. The language is not that interesting, it's easy to reproduce, and these guys will threaten you if you prove this.

and now they'll sue you for libel ;-)

Re: 32 bit version of KDB+ is now free for commercial use

#30

Post by jibberia »

jmnicolas wrote: post #9

Except financial applications what is it good for ?

Almost 10 years ago, I did an undergrad independent study at NYU contributing to some PhDs' Query by Humming music search engine. We used q to query a kdb full of catchy-melody time series data -- short sequences of "is this pitch higher, lower, or the same as the last?" and "is this note short, long, or medium?" (and, of course, gobs upon tons of variations as we iterated!).

I barely did any q / kdb; only made a functional and usable UI, and did some prototyping of new ideas in other languages (Java, Max/MSP, Csound). I spent some time looking into q and was thoroughly baffled. Still am. It was really, really fast, though!

As I vaguely understand and can explain it, the k/q system made it easy to do fuzzy searches and deal with missing pieces of data. If the user missed a note, or our pitch detection failed, or our source data was bad, we were still able to find matches. (Yes, I wish I'd been able to understand this more at the time. Bygones, now...)

Post reply on HN