Sunday, December 23, 2018

Clojure quick tip: efficiently find last element in vector satisfying some condition

Trivial, but I keep forgetting about rseq:

user> (first (filter #(even? (do (println "x:" %) %)) 
                     (rseq (vec (range 1 100)))))
x: 99
x: 98
98
user> 

Vec is very nice; it'll alias JVM arrays. Anyway, doing (last (filter ..)) would traverse the entire vector which isn't very effective.

PS: Merry XMAS. :)

Wednesday, December 12, 2018

A list of #mistakes update: you cannot process events in simple sequential order during live trading

NOTE: I'll keep adding more updates like this under the #mistakes label.

This might be pretty trivial and even obvious, but I keep having to remind myself of this as I "rediscover" it in several somewhat similar situations.

During backtesting you can pretend that you always get events one by one in perfect order and process them in sequence as such because you are in control of time here -- but during live trading you will sometimes get a bulk of events in one go and your strategy, order or event handling code will probably need to be aware of this in order to make good decisions.

E.g.:
  1. You are passed a bulk of events.
  2. An earlier event in the bulk informs you about an order update (e.g. partial fill) which you generate a response to.
  3. A later event in the bulk informs you that the position related to that order was closed for whatever reason.
  4. ...based on §3 your response in §2 might not make sense anymore.
You might think that this will not be a problem for you because your system will be fast enough to handle the events before they queue up anyway -- but this is not only about your system, but also about network and exchange/broker lag. I.e. you are not in control of time here!

As I learn more and more about "stream processing", the more multiple full passes of bulks of data seem to make sense. Sequential processing is an oversimplified view of reality --- it is still useful during simulations though.