In my previous post on modeling, we saw how in a simple simulation of fairly random events (with equal likelihood of success or failure) we could end up on a positive aggregate outcome even if the individual event outcomes seem random. We saw this result when we reduce the amount of loss from an individual event by 50% while keeping the amount of profit the same from an individual event. In other words the payoff matrix was changed from (-1,1) to (-0.5,1). With this new pay off matrix when we played the same random game, we saw that the total outcome or aggregated outcome is far more superior. In other words our chances of success or total profits jumped from 44% to 95%, or in other words we have an increased level of certainty.

To illustrate this phenomenon in a practical situation, we could use high frequency trading as an example. If we could design a fairly random stock picker that is not really good, which means that I get roughly equal chances of picking the right stock and equally probably chances of picking the wrong stock. If we could somehow minimize the losses associated with a wrong stock (alternatively you could also try to slightly improve the gains with the right stock) meaning if we could change the pay-off from our random stock picker application we can get profits that is far more disproportionate to the quality of my stock picker.

What we have arrived at is a fairly important conclusion, even though it is probably known widely in the academic circles and is not something new. However the benefits of any theory are not realized unless we operationalize it. We will set out to operationalize the conclusion by identifying the requirements of a software application that would have a pay-off matrix that would improve over time.

Software Application Characteristics

If we were to somehow operationalize the above conclusion then our ideal software application would have the following characteristics.

  1. Improve the aggregate outcome even when the proportion or count of individual outcomes seen as a failure or success doesn’t change.
  2. The aggregate outcome should be based on aggregating individual event outcomes in a finite period of time, possibly minutes, hours, days, weeks or one month.
  3. Point number 2 also creates an implicit assumption on the nature of events as well. If we were to aggregate something over minutes, then several events should occur within a minute

Well creating the desired characteristics of a software applications is easy but how do we build one such application. In the next few post we will talk about building the so called “Cognitive Applications” and how Big Data is rather symptomatic of an opportunity where events happen at a very fast pace and therefore could result in a profitable outcome if we only we could identify what the outcome is.

If you find this post interesting, you may also find my other posts interesting, some of which are given below

  1. Modeling Luck and High Frequency Trading
  2. Planning and Decision Making
  3. Seeking New Laws – Richard Feynman
  4. Five Minus One = Four Billion
  5. Innovation in the Cloud