TheTank

Hey of course, happy to meet and exchange about our fun projects. You can send me an email using the address in the above comment and we'll setup something!

Hey, yes I can do that. I will brush this up, package all the bits (3d files, pcb files, code etc), and add to github.

On another note, would you happen to live in London? If you really want to try this I could hand you one which will save you plenty of time finding the parts, printing the case, ordering PCBs, and soldering. You can reach me on first_name dot last_name hat gmail dot come. The name is at the top of the original post.

I'm afraid not because it would only run on the device so you'd need to make one using a raspberry pi pico and the exact same display (Pimoroni display pack) as it leverages its graphics library to draw text and shapes. So far, the only way I've been sharing this was by handing out devices as gifts with the game preloaded.

I recently started another version which runs on desktop using python/PyGame which I could package up and share and has very similar mechanics except it's faster-paced and intended to look and feel like a sensory-overload arcade game (sounds, lights, music, flashes, announcer voice etc). It's also a 2-player 'versus' game which can be played locally. The intent behind this was to build an arcade station around it, but it can be played on the computer directly using a keyboard.

It looks like this [1] but it's not yet in a playable state and would be hard to pick up as is. I'll continue working on it and then post a link to the github.

[1]https://imgur.com/a/b4qMs6f

Thanks for the feedback. Yes it takes some practice to be able to read and understand an orderbook, and I find that visualisations help a lot, so does making your own derived metrics (for example calculating vwap prices, distance to fair in basis points for each level etc). What this game does is provide a feel for it, for your relative position, and for visualising pockets of liquidity, but it's also quite limited by the form factor.

I drafted another version of this game which is more arcade-based (and does not run on handheld but a computer or arcade box) and the game is essentially about fighting over an orderbook to (a) be in the best position possible to capture the flow that you want, (b) monitoring for orders with a positive edge and sniping them faster than the other player (or even pick off the other player before they have a chance to move). The values next to the bid and ask quantities are the edge in basis points relative to faire value. If you see some positive edge somewhere you want to go and cross the book to pick out the price.

[1] https://imgur.com/a/b4qMs6f

It's a tough question because most of what I learned was on the job and I don't really remember books specifically on the topic. It also depends on what product and market you are trading, and on what channels (on exchange, over the counter etc.)

I would say it starts with knowing the product you trade and their dynamics inside out. How to make a price for it, what dynamics can change that price etc. It's also a good idea to understand related instruments as typically you would use them for price formation and hedging [1][2].

The second bit is to understand electronic trading infrastructure and the market microstructure such as how orderbooks work, and some trading algos [3]

If you're also interested in the infrastructure behind related to low latency, you can read about FPGAs, Exchange co-location etc. There is a fascinating blog on the network infrastructure [4] and the author (Alexandre Laumonier) also wrote a few books on that topic.

A lot of market-making is bespoke and proprietary. For example your pricing model, hedging model, etc. It's also constantly changing depending on events (e.g. the elections) or market conditions (correlations changing). But a good place to start is to use some simple pricing model such as making a blend of other prices in other venues, or for derivatives making up the price based on the underlying price and other elements which vary depending on what the derivative is.

While you would not be able to gain direct market access to, say, the NYSE, a lot of crypto platforms offer APIs for users to build trading bots as a training ground. For example Bitmex, or Deribit. But before doing this I recommend understanding the contract mechanics inside out. For example, the perpetual futures have a very particular mechanism which means they are priced and traded differently than normal futures you'd read about in the Hull book.

I have a few friends who built bots and make small markets on random cryptos for fun. In this particular case, you'd have to think a bit harder on how you hedge your positions (e.g. can you sell an illiquid coin and hedge with a liquid one for cheap?). One way of doing this may be to look at correlations between coins to find the best hedge. Another consideration for crypto is the fee structure which you'd need to account for in your price.

I don't know if it's a good idea to start doing this in crypto besides for fun though, mostly because it's a business that requires scale to derive a meaningful profit. But as an exercise it's definitely fun.

[1]Options, Futures, and Other Derivatives (J. Hull)

[2]The handbook of fixed income securities (Frank J. Fabozzi, Mc Graw-Hill Gb)

[3]Algorithmic Trading & DMA (B. Johnson)

[4]https://sniperinmahwah.wordpress.com/

There isn't any library for the trading UI or graphics elements. The only library in this case was the display graphics library which allows to draw simple primitives such as squares, lines, circles, text, etc. [1]

The UI is a bunch of elements you would see on various trading systems (orderbook, trade blotter, market depth chart, intraday rolling chart, scrolling news ticker etc). But they had to be implemented from scratch using these primitive shapes and coordinates on screen.

For example, the chart element is rendered by looping over the recent prices, calculating the min/max values to derive a range and adding a buffer on either side. Then calculating the price interval of each pixel (difference min-max divided by the number of pixels of my chart area). I then iterate over the prices, calculate their positions on the display in pixels, and draw series of lines between consecutive prices.

[1] https://github.com/pimoroni/pimoroni-pico/blob/main/micropyt...

They did continue participating but it's true that this became a sort of electric train where daddy buys it for the children and ends up playing the most with it.

The trading game did not capture their interest further than watching colourful flashes for a few minutes. It's probably too complicated for their age and hard to understand without knowing some basic financial markets knowledge.

However I used the same device to make other more appropriate games and keep them involved. I could ask them what game they would want, and I would make most of it but involve them in the parts of the code that can be meaningful to them. I found that while they like understanding how it works when I walk them through some small bits of code, writing code (even heavily assisted) is still daunting at their age so they prefer tools like MIT scratch.

You're right and besides that, it's not an interesting game for them. I continued involving him using the same platform, but we made more age-appropriate games. It's easy to upload a different game over a USB cable so I could just remove the trading one and upload some other.

Some of the games we made were a quizz platform (times tables, French words etc.), a version of etch-a-sketch where they can move a cursor around, draw, and change the color, and a 2d space shooter game.

It was a good platform to introduce them to code on some of the more tangible bits such as explaining that the screen is a grid of pixels, and that hitting the move button means incrementing your position variable by a few pixels. It's also quite cool for them to be able to bring this to school and to explain how it works, both from an electrical standpoint, and for some of the simple software bits.

Author here. Thanks for reading this post. I had fun making this and thought the path that led me to this might be interesting for others.

I’m really interested in feedback and ideas on things I could improve and add. I found this really inspiring as it got me more into programming, discovering electronics, and 3d printing.

I have no desire to ever make this project commercial, but it’s been a great platform for me to learn and experiment new things so I’ll take any idea be it for the gameplay or purely technical. Some features I have in mind are:

- Multiplayer over bluetooth where one device is the ‘game-master’ running the exchange and can monitor and guide players while injecting events.

- Additional quoting algos such as pegging one side of the order book and fighting for position

- A tutorial and better UI. The game is hard to pick up for the first time and probably needs to be made more intuitive etc.

While all of this was made with no practical use in mind (there are a lot of markets and products, and you’d trade them in different ways, so you’d need a different game to speak to a volatility trader for example), some people I work with at various trading desks found it useful for interviews or as an introduction to the idea of market-making for junior people.

Author here. You are right this is convoluted and confusing.

I wanted to write an informal introduction to options using a more tangible example for those who are put off by the maths but still would like to gain an intuitive understanding. At the same time I wanted to show things I found were interesting in the data.

It may have been better to separate the two ideas. As you rightly say, one is confusing the other in the current form.

Congrats on launching. It looks like it’s only email login. Do you have an idea when you will release Oauth logins?

Thanks! Indeed we are still light on available aggregations. Right now we are focused on building a fast infrastructure to support them, for example Swissmap / "rosti" for keyed aggregations. Next steps will include multi-pass algorithms. Once the infrastructure is done (and fast), adding functions will be much easier.

Thanks for your question!

The main value proposition is raw performance which translates into hardware efficiency and ultimately, costs at scale.

To get a rough idea of how we compare, you could try to running `select cab_type, count() from trips` and `select passenger_count, avg(total_amount) from trips`. They are the equivalent of queries (1) and (2) of this benchmark [1]. In this benchmark, BigQuery took 2 seconds for each query.

Our server runs both in hundreds of milliseconds. And this is actually slow because this is the same server which is currently being hammered by HN users. Also, we are scanning more rows. Our dataset contains 1.6 billion rows while the benchmark attached runs on 1.1 billion. Lastly, we only use one 24-core CPU from one server while the top of this benchmark is clusters or GPUs.

Of course this is only approximation but I hope to be given the chance to feature in this benchmark when we are ready.

[1] https://tech.marksblogg.com/benchmarks.html

The trips table takes 313GB. QuestDB is not an in-memory DB. The data sits on SSD EBS volumes.

Tanks for the feedback.

WHERE queries are slow indeed. This is not because of the load but rather because WHERE clauses are not yet implemented under the fast path. Currently they run under an old model which is single-threaded which is why they are painfully slow.

We will make these as fast as the rest soon.

Will do. Thanks for offering help!

Yes, this is part of the roadmap. Right now, we don't have any interesting query to showcase that would use these columns - they are here because they are part of the original dataset and we are keeping them for when we demo further releases.

Very accurate!

Regarding the theme of joins, I would just add that QuestDB also has a concept called SYMBOL which allows to store repetitive strings into a table as an integer in the background, while letting the user manipulate strings. This means that instead of storing something like 'sensor_id' and then looking up the corresponding 'sensor_name' using a join, you can manipulate 'sensor_name' directly and skip using joins.

Thanks for the feedback, we'll look into it!

We will definitely make QuestDB distributed in the near future. Today, our focus is to extract the maximum performance out of a single node. If we start scaling out too early, it may become harder to improve performance after the fact. So all improvements we get today are foundational: they will have multiplicative effects once you start to scale out.

One step beyond good Java GCs is to write fully zero-GC Java code. The advantage of it is complete control over your performance which means your software is going to be consistently fast. The disadvantage is that it is relatively difficult to obtain.

If you want to see an example of fully zero-GC Java, you can check out QuestDB on Github [1] - Disclaimer I work for QuestDB.

[1]https://github.com/questdb/questdb

Thanks for sharing. Do I assume correctly that this tool takes in dividend expectations and not only announced dividends?

Building a portfolio around dividend expectations is definitely useful for many reasons. But predicting dividends is hard. I imagine the dividend payouts for upcoming seasons will be far off previous seasons, and way short of previous analyst forecasts. How do you build or source your forecast levels for this tool, and how do you adjust expectation levels in the light the current economic context?

Thanks for sharing. Do I understand correctly that this requires loading the whole file in memory along with an ordered list of keys? Or is it just the first n bytes that are loaded in memory? If the former, then it seems very expensive in terms of RAM, particularly if your data file has multiple columns.

As an alternative I used is to load the file in a database, then sort by the key I want (which only loads the key in memory) and then output the result into a file. It does go through disk but you can address larger files as you only need the key in memory, and not the whole file.

I find the concept interesting and I can see real applications for something like this (delaying someone's access to a file). For example, one could use that to disseminate press releases ahead of time without actually revealing the contents.

That said, it seems the current implementation is impractical because you will "on average" decypher after a certain time, but that time can vary greatly. Are there plans or methods to explore in order to make this more deterministic?

Interesting project. Out of curiosity, why did you compare against kdb+ since the models are very different? KDB is mostly used for in-memory time-series while your seem to be a graph-oriented DB. Also, why did you choose to build your own language instead of using an existing one [1]?

[1]https://en.wikipedia.org/wiki/GQL_Graph_Query_Language

Thank you for your kind comment! We would consider offloading to a GPU when the time is right. It feels right to fully utilise CPU capabilities before jumping to GPU.

In the future, we will release other products with features geared towards enterprises. We don't think that having our code open will harm the business.

On the contrary, it will hopefully help us gain some popularity by allowing any developer to access latency levels only seen in trading. We hope that QuestDB will allow them to stop worrying about database performance bottlenecks.

Window functions are in draft, we will release them imminently. We will support moving averages. In fact we plan to support generic multi-pass and window functions. Having multi-pass will allow you to do things like `select sum(x -sum(x)) from tab`.

QuestDB | Head of Dev Rel / community manager |Remote, London/SF QuestDB is a an open source SQL database to process time-series, faster. The founding team comes from low-latency trading; fast software and timestamped data are part of our DNA. Through QuestDB, companies can harness the power of real-time and big data processing in a wide array of use cases and industries, from financial data to IoT and connected cars. We are funded by leading European VCs.

Helping developers solve their problems is at the center of what we do. We are looking for a head of developer relation to spur developer adoption and usage, grow the brand and empower developers with faster software that kicks Moore's law (or rather the end of it) in the teeth.

Find more information about this opportunity (and others) on https://www.questdb.io/careers

It is a good strategy (and an interesting product). The execution side might be complex for retail traders. Execution is particularly important because although you get a cheap structure (selling one leg, buying the other), you end up crossing the spread twice.

This sort of trade is usually done OTC or alternatively using a contingent algorithm (wait passively on one side for one leg, and fire the second leg automatically as the first leg is filled) which allows going from paying 2X spread to 0 - but the latter has the tradeoff of taking longer and potentially missing the opportunity.

I know they are sometimes called like this, but I find the naming "credit spread trading" confusing. Are these strategies different from collars? I traded credit in the past, and my immediate understanding of "credit spread trading" in this context is shorting bonds of Boeing and buying treasuries (or trading US rates) for example. It would also be a valid strategy in this case that would use credit and rates instrument as a vehicle rather than equity instruments, but not accessible to retail traders.