Principles of Quant Innovation

What improves the chance to introduce an innovation that becomes a classics of the future?

About building…the story from the simple to the complex

Complex systems may be result of the repeated application of a few building blocks, rules or programs. Think of words and natural language or Lego bricks empowering the construction of practically "everything".

Let's think of a Lego-type-building a little deeper.  With the basic bricks you can build a lot of static things, for mechanisms you'll have  special elements. You may want to control the mechanism, say, you want to build robots…you want to control them…program them. The smarter you want your things be the more specific and complicated the physical building blocks become.

What's behind is geometric, kinematic, dynamic modeling, control theory, sensor processing…robot programming…

To make your toy robots autonomous you need to cognitize them and if you want them to interplay, connect them.

This is a toy world, but in the large you may also apply a kind of innovative spiral from simple elements to complicated components to complex systems. Your quant innovation may help developing, producing or running such a (complex) system.

Smart, connected products

Things built evolutionary: static --> mechanized --> electrified --> computerized --.> cognitized --> connected

Empowered by quantitative technologies that's capabilities developed evolutionary as well: monitor --> control --> optimize --> empower autonomy --.> connect

Think of the systems driving the evolution of "car intelligence".

The evolution of tools

Remember, the history of tools from the fist wedge to the computer is characterized by building higher level tools by lower level ones. In smart computing, tools at all levels of the development evolution are still available.

Wolfram Engines are built in C, UnRisk Engines are built in C and Wolfram Engines. UnRisk VaR Universe its built in UnRisk and Wolfram Engines...

This enables a lot of choices guiding your innovation. If the selections are good or bad needs principles…that go beyond the making.

This is why I introduced The Quant Innovation Mesh.

The Principles of Quant Innovation

Most of the systems that require quantitative treatment (computation) have a clock, flows, events, transformations, massive information requirements…Most of the problems suggest a function-oriented decomposition and the bottom up composition of computational tasks, based on modeling, control, simulation, optimization, cognition, interplay…characterized by object transformations and events…on each level.

Mathematical problem solving has three steps: 1. transform a non mathematical problem description into a mathematical model and transform the model into one of good nature for calculation --> 2. calculate --> 3. interpret the results. This fits into the general model: preprocess --> process --> post process. Each of the steps has its traps and subproblems and may run into a crisis…and the solutions may offer some striking findings.

Each of them, let's call them tasks, from the micro to the macro layer, create Beginning hooks, Middle builds and Ending payoffs

Consequently, innovations that have the potential becoming a classics of the future should have the following flows
  1. Set-up  Edit: Constructors
  2. Problems 
  3. Crisis 
  4. Solution
Each element, component...of your innovation should have it. On each evolution level, it may be required to ask "what if?" and apply kind of counterfactual regret minimization (If I haven't overheated, then …)…(Those  questions become indispensable in a complex interplay of agents…)

It applies to your basic functions, processes, tasks and the system as a whole. They all need a constructor, experience problems and maybe even run into crisis…finally it's all about the solution.

In our Quant Innovation scheme I fill out the most important phases of the whole system. Preprocessing. Processing. Postprocessing (but never forget the workflow, tasks, functions…).

Remember, never organize a complex system of tightly coupled components. Never. Desires, requirements, events…may force immediate regime switches.

Be suspicious about unconditioned integration, centralization, supervision, linearity…one-approach-fits-all…

It's a striking finding and it has been (again) inspired by Shawn Coyne's blog: The Five Commandments of Storytelling in this case.