enlist[q]

I am going to assume that you all know what is a fibonacci sequence (FS). If you don’t, you can read up about it here. In my last post, I talked about using the adverb over. In this post, I will show you how over can be used to generate FS.

Main thing about FS is that you need to take sum of the current value and previous value to get the next value in the sequence. The trick to tackling this task is starting with a pre-defined list with values 0 and 1 since those are always the first two values in FS. Once you have that, you can add new values to it as you run your function. You can use over to specify how many times you want your function to be run over the initial list.

One of the first things I was told by my ex boss was to never use for/while loops unless it’s a matter of life and death. And he was dead serious. I had just taken two c++ classes in college so wasn’t sure how I would be able to replace for/while loops. They are easy to use and make your life easier. BUT that’s not the case in q. There are better alternatives there. Thing to remember with q is that it loves lists. If there is any operation where you can use lists, then do that!

In this post, I am going to cover two adverbs, scan and over, that you can use instead of for/while loops.

I used to hate functional queries. Part of me still does. They are hard to write, look like gibberish and not as simple to understand as qsql queries. I can’t believe I am saying this but as you get more familiar with q, you start seeing their advantages and point of their existence. q is a functional language and the best way to unlock its full potential is via functions.

For me, functional queries are most useful when I am trying to run them on a remote process/db. Instead of wrapping a qsql query in string and then sending it via IPC, I prefer to use functional queries. This is especially important when you want to pass arguments to a query…yes, basically treating it as a function. That is when having a functional query helps because it allows you to easily pass locally defined parameters to a remote process. Anyways, that’s a discussion for another time. Today, we will look at how to actually write them.

If you have spent some time working with kdb+, there is no doubt that you have had to use some sort of join in your query. Joins are essential to data analyzing. kdb+ query language is called qsql which, as you probably guessed by name, is based on popular query language, SQL. I don’t have much experience with SQL so I can’t tell you about how joins work in SQL but I can discuss joins in qsql.

There are different types of joins offered in qsql…some of them are very similar so make sure to pay attention to details. I will try my best to provide some good examples to make the difference clear. The available joins are: left join, plus join, inner join, equi-join, union join, asof join and window join.

Real-time databases are easy to understand as everything is happening in memory. Historical databases are a different story. Recently, I have been getting much more involved with hdbs at work and just the way they work is incredible and fascinating to me. If you are serious about kdb+, you should make sure to know how hdbs work under the hood. It will also help you understand the reason behind writing qsql queries a certain view (specifying date parameter first). It will help you understand that moving data from one hdb to another hdb is not as simple as copying it from an rdb to another rdb.

In this blog post, I will cover how data is stored on disk (splayed/partitioned tables) and why that makes data retrieval fast. I will also touch attributes briefly.