The practicalities of solving the neocybernetics challenge
To truly call yourself or your organisation innovative, you need the right mindset, not just the right technologies. In quantitative finance, this is especially true. This is a rapidly evolving sector, but without collaboration and diversity of thought, this sector is at risk of stagnation. That’s where neocybernetics comes into play. However, executing it the right way has it’s natural challenges, and that’s what Paul Bilokon, Founder, CEO, and Chairman of Thalesians is here to show us.
To fully solve the problem of neocybernetics, we need to approach it holistically. One challenge is that the problem is multidisciplinary. It is not only a scientific problem. It is also an engineering and business problem and it spans over several areas:
Theoretical computer science:
- Concurrency – low-latency, high-throughput real-time systems are usually concurrent by necessity; concurrency in this setting is not very well understood, hence the need for science.
- Real-time computing, also known as reactive computing – we need to understand this very well, since in many applications, notably medium – to high-frequency trading, we must guarantee response within specified time constraints, the so-called real-time constraint.
- Theory of Functional Reactive Programming (FRP) – we need to understand this well, since this is our programming paradigm of choice (for production, not for research); this paradigm is relatively new and is still being developed, hence the need for science.
Machine learning:
- Feature engineering (theory and practice) – since we need to extract as much information from individually uninformative time series as fully as possible.
- Feature selection and regularisation (theory and practice) – since we need to prevent overfitting and deal with (multi-) collinearity.
- Neural networks (especially their applications to time series data; theory and practice) – since this appears to be the most potent method of forecasting time series.
Software engineering:
- Functional Reactive Programming (FRP) – few frameworks nowadays have been tried and tested in the high-frequency, high-throughput real-time setting, we need to roll out our own.
- Concurrent programming – needed to facilitate the intra- and intertransactional concurrency in the FRP framework.
- Distributed computing – required to make it possible and straightforward to roll out neocybernetic systems of any scale with individual components running in different processes, on different system.
- Library design – economy of scale is achieved by making components reusable at all levels; extremely high standards must be applied to library code to make this possible, since libraries must be efficient, maintainable, easy to use correctly, and hard to use incorrectly.
- High-throughput, low-latency messaging, such as the former 29West’s Latency Busters Messaging (LBM) – to facilitate communication between the distributed components.
- High-frequency time series databases (TSDB), such as kdb+/q – to store data for backtesting and auditing purposes, but may also be used as middleware, storing both snapshots and state deltas.
- High-performance computing (HPC) – since the calibration of machine learning models is a computationally expensive process, which gets more and more challenging as dimensionality increases – both due to an increase in the number of observations and due to an increase in the number of features. We should keep an eye on quantum computing, since it may make the calibration of much larger and more realistic models feasible in medium to near future.
User experience design
In all neocybernetics applications, one needs to be able to monitor and control the system in real time. (Some users may be restricted to monitoring-only, “read-only” access.) The visualisation and control GUIs need to be really user-friendly to be useful. They need to be configurable to make it possible to roll them out quickly for new applications and new user roles. Separating the UI components into a self-contained library enables their improvement across multiple applications. For most neocybernetics applications UI components must be networked and run in a separate process and potentially on a separate machine to the one running the real-time calculations.
Business organisation
In order to facilitate the work, agile and cohesive teams of experts must be instituted and fostered. The common components must be separated into core technology and data science teams. We also need teams dedicated to applications. It is highly non-trivial to manage highly gifted technical personnel, facilitate their productivity, and enable them to grow as individuals.
Requirements gathering
Dedicated business analysts are needed to drive domain-specific applications. They need to speak both the neocybernetics language and the language of the application domain.
The blind men and the elephant
While there are many excellent experts in each of these areas, all too often these experts (especially if they are really good in their respective area) have a one-sided view of the entire playing field. They tend to regard their area as the playing field, underestimating the importance of all the other areas. For this reason, they tend to behave like the “six men of Indostan, to learning much inclined, who went to see the elephant (though all of them were blind), that each by observation, might satisfy his mind”[1]. Each of the six men feels a particular part of the elephant – the side, the tusk, the trunk, the knee, the ear, and the tail – and concludes that the elephant is, respectively, like a wall, a spear, a snake, a tree, a fan, or a rope.
And so these men of Indostan, disputed loud and long,
each in his own opinion, exceeding stiff and strong,
Though each was partly in the right, and all were in the wrong!
The unfortunate outcome of this situation is indeed that all of them end up in the wrong, and the problem remains unsolved.
In particular, people with statistics background often lack an appreciation of enterprise-level software engineering. People with enterprise-level software engineering backgrounds often lack an appreciation of statistics. Technical personnel often lack appreciation of business aspects, and vice versa.
A little learning is a dangerous thing
Indeed, even within each particular area, we are likely to fall into a trap, the trap identified by Alexander Pope in An Essay on Criticism (1709):
A little learning is a dangerous thing;
drink deep, or taste not the Pierian spring:
there shallow draughts intoxicate the brain,
and drinking largely sobers us again.
“A little learning” does not take us part of the way towards the goal – it is actually detrimental. We end up with a very shallow understanding of the playing field, muddled thinking, and incorrect answers to problems. What’s worse, we don’t even realise this, lulled into a false sense of security by “a little learning”. “A little learning” increases the number of blind spots and introduces biases.
The art of choosing the right abstractions
The power of both mathematics and software engineering is in abstraction, which Wikipedia defines as “the process of extracting the underlying essence of a mathematical concept, removing any dependence on real world objects with which it might originally have been connected, and generalising it so that it has wider applications or matching among other abstract descriptions of equivalent phenomena”.
Too much abstraction is bad. Too little abstraction is bad. We need the right amount of abstraction. Moreover, we need the right abstractions. The quality of a mathematician’s (software engineer’s) abstractions is an important factor in that mathematician’s (software engineer’s) success. Unfortunately, coming up with the right abstractions requires a lot of skill and experience and it is an art more than a rigorous science. (See Alla Babkina’s talk The Art of Choosing the Right Abstractions on YouTube.)
Here are some examples of extremely successful abstractions in other areas.
Mathematics: axiomatic probability theory
Modern (axiomatic, measure-theoretic) probability theory took its rise in Andrei Nikolaevich Kolmogorov’s seminal Grundbegriffe der Wahrscheinlichkeitsrechnung, which appeared in 1933. Kolmogorov’s work sidestepped the deep philosophical questions – what probabilities are – inherent in any discussion of probabilities and instead focussed on how probabilities behave, starting with some simple (but right!) axioms. In his paper he wrote: “The theory of probabilities as mathematical discipline can and should be developed from axioms in exactly the same way as Geometry and Algebra.” What we nowadays take for granted was not at all obvious at the time.
Kolmogorov’s abstractions were based on earlier abstractions – those of measure theory – developed in successive stages during the late 19th and 20th centuries by Émile Borel, Henri Lebesgue, Johann Radon, Maurice Fréchet, and others.
Modern probability theory has become the formalism of choice in mathematical finance (largely displacing the formalism of differential equations) and machine learning (largely displacing the formalism of deterministic logic). This is happening nearly a century after Kolmogorov’s original work, which testifies to the amazing durability of his approach.
Computer science: data structures
Data structures, such as the array, stack (proposed by Alan M. Turing in 1946), linked list (developed in 1955-1956 by Allen Newell, Cliff Shaw and Herbert A. Simon at RAND Corporation), B-tree (invented by Rudolf Bayer and Edward M. McCreight), and AVL tree (invented in 1962 in the USSR by Georgy Adelson-Velsky and E.M. Landis), have greatly increased the level of discourse in computer programming. These theoretical abstractions have become foundations of the engineering abstractions such as the highly successful STL (started by Alexander Stepanov in 1979) and the Java collections framework (JCF) developed by Joshua Bloch on the basis of Doug Lea’s earlier Collection package.
As above, so below – as below, so above
When is the right time to think about the abstractions? At the same time as working on the applications. If we come up with abstractions in isolation, we risk excessive idealisation and irrelevance. The resulting abstractions are unlikely to be useful. To use an analogy from machine learning, we end up underfitting. If we focus on the application alone, our abstractions are too close to the metal. We are neither obtaining useful general knowledge that will help us approach other applications, nor bringing the know-how (either explicit or implicit) from other domains into this particular application. To use an analogy from machine learning, we are overfitting.
Our goal in neocybernetics is to achieve economies of scale both in terms of being able to solve more problems through better abstractions and in terms of better abstractions through honing them on more problems.
In the School of Athens painting, the more heavenly (“abstract”) Plato (pointing upwards), carrying the esoteric Timaeus, is walking next to the more earthly Aristotle, carrying the Nicomachean Ethics gesturing towards earth in a characteristic way. The two, however, are looking amicably at each other and are walking side by side.
One should also get familiar with Alfred Korzybski’s structural differential and become proficient at moving from higher to lower levels – and vice versa – fluently, and repeatedly.
I would have written a shorter letter, but I did not have the time
The above (in French) appears in Blaise Pascal’s Provincial Letters: Letter XVI (4 December, 1656). We are aiming for simplicity, but we underestimate how much time and effort must be expended to achieve simplicity.
When we look at Kolmogorov’s axioms of probability, they appear simple. But years of work have gone into them. In particular, the choice of countable additivity, is a stroke of genius. A user of probability theory will have to work hard why this is the case.
Perhaps controversially, Fréchet[2]wrote:
It was at the moment when Mr. Borel introduced this new kind of additivity into the calculus of probability – in 1909, that is to say – that all the elements needed to formulate explicitly the whole body of axioms of (modernized classical) probability theory came together.
It is not enough to have all the ideas in mind, to recall them now and then; one must make sure that their totality is sufficient, bring them together explicitly, and take responsibility for saying that nothing further is needed in order to construct the theory.
This is what Mr. Kolmogorov did. This is his achievement. (And we do not believe he wanted to claim any others, so far as the axiomatic theory is concerned.)
We hope that our abstractions will get crisper / smaller, rather than grow out of proportion, through deeper thinking on a wider range of problems.
Writers rather than readers
We hope that our abstractions will also help our people to become creative at solving new problems instead of simply being able to appreciate others’ solutions to existing problems.
One problem in data science (and mathematics) is that there are too many “readers” (who don’t admit to themselves that they are merely readers) and not enough “writers”.
We hope that our philosophy and toolkit will help create more writers. Unfortunately, the step from being a reader to being a writer is orders of magnitude harder than the step of becoming a reader. (This is the problem of most undergraduate courses: they prepare readers.)
Make systems and processes easy to use correctly and hard to use incorrectly
A variant of this phrase, “Make interfaces easy to use correctly and hard to use incorrectly”, occurs as the heading of Item 18 in Effective C++ (third edition) by Scott Meyers.
This is particularly important in life-critical applications, such as medicine.
What form does the product take?
A neocybernetics organisation is simultaneously a research and business organisation.
It is a research organisation because the field is in its infancy. We want to achieve something that no-one has achieved before.
It is a business organisation because we must make the organisation sustainable and independent, and prevent it from degenerating into a Leviathan.
The resulting product is more like an operating system than a single application.
Do not reinvent the wheel
We are not being overly original in this. Many neocybernetics problems have been solved but the solutions are restricted to a particular problem domain – industrial electronic market making, such as the cross-asset market making undertaken by the Markets Electronic Trading (MET) group at Deutsche Bank, similar projects at Goldman Sachs and XTX Markets.
We need to take advantage of this experience, while broadening the domain.
This isn’t restricted to technical experience. This should include business structure, e.g. partitioning the data science teams into core and domain-specific (within market making – asset-class specific), etc.
Join Paul Bilokon at QuantMinds International and find out more about neocybernetics in his presentation.
[1] John Godfrey Saxe, The Blind Men and the Elephant (1872).
[2] Fréchet, M. Exposé et discussion de quelques recherches récentes sur les fondements du calcul des probabilités. Actualités Scientifiques et Industrielles 735 23–55. Hermann, Paris. In Wavre (1938–1939), second fascicle, entitled Les fondements du calcul des probabilités.