My next side project will be an Azure app that aids people in decision making via interactive algorithms that analyze the data underlying the interactive controls, the data stored about the specific user, and the general data stored in the system that is relevant to the particular decision.
Examples of the types of decisions the app will aid people in making are:
- financial investment portfolio asset class allocations
- choosing between different employment offers
- choosing between different residences (including buy vs. rent)
- choosing between different vehicles
- choosing between different colleges
I plan to start developing the app with a focus on aiding in investment decisions. In 2008 I created software for backtesting parametrized technical indicators commonly used in trading. That software did not result in an strategy algorithm that produced annualized returns that were sufficiently high and consistent, but I did learn a things from the experience that will help with the architecture, design, and implementation of this app.
- The backtesting software and the investment strategy being tested need to be high performance and parallelized, as the results never come out fast enough. This means the backtesting software needs to at least be multi-threaded and optimized native code. It would be even better if it were distributed across multiple machines as well.
- While very tight coupling between the backtesting code and the strategy code provides significant opportunities for optimization, it does not allow trying out different investment strategies without also changing the backtesting software. This means the backtesting software developed initially needs a well defined interface. Creating more specialized backtesting software should be deferred to the future even if that means higher operating costs now.
- Software is needed for analyzing and comparing the results of the backtesting runs on investment strategies, but runtime performance isn’t a gating factor for this software. This mean this code can be written in Python or IronPython.
- Software is needed to manage the results data and tie it to the specific version of the code the produced. The results data is too large to commit to source code revision control systems. This means a reliable and durable mechanism is needed to map strategy code and backtesting code to specific results and vice versa.
This app meets the goals I set for my next side project as it will be an Azure app and I’ll be able to make use of my recently created multi-threaded C++ unit testing framework in the development of the backtesting software. I may even find it necessary to enhance the framework to support multi-processed applications if single-process multi-threaded performance proves underwhelming.
Now I just need to come up with a name for this project and get started!
Josh Heitzman on Codecrafting 
Hi.
What happened to your last project Cloud Hydra? You gave up on it developing?
For me as a very interesting product would turn out.
P.S. Sorry for the English.
Translated from the Russian by google translate 🙂
Egor, thank you for expressing interest in Cloud Hydra. You are the first person to express interest in Cloud Hydra. I did stop investing in Cloud Hydra due the lack of expressed interest. I have noted your interest in Cloud Hydra. Perhaps by the time I next assess what project to pursue, I will have received sufficient expressions of interest in Cloud Hyrda that it will rise to the top of my list.
Josh,
I wish you would have said something, “That software did not result in an strategy algorithm that produced annualized returns that were sufficiently high and consistent…” I have had my best luck with a level 6 polynomial of the price or index value to indicate time to sell in a peaking market cycle…
Send me your current e-mail, I will send you some stuff and maybe you can run your software against this concept for consistancy…
For me the biggest issue has been correlating timely decisions with the commonly published indicators, because they are lagging indicator. I am getting my best results with pattern analysis, recognizing outliers and the polynomial.
I am currently trying to generate the polynomial myself use for the decision algorithm. While that is being tested, my next thought I am trying to investigate is a possible forecasting indicator or better momentum indicator than what I have seen to date… My confidence level is high, but I am trying to box in an automatically generated timely decision recommendation with a highest degree of consistency (I think I am at the 80:20 rule or better level now in concept).
Ernie…
Josh, about CloudHydra: This is a legitimately rad concept – it kills me to see good ideas being ignored… mostly because I can relate to the frustration. Are you still pursuing development, or has your return to MS derailed the project? I’m working on a similar app (lighter weight and soc net oriented) but that’s beside the point. As an end user pure and simple, I’d love to see this released! Will it be? -N8
Q: Hypothetically, would your decision-making app be capable of identifying known unknowns of the ideal type or strictly limited to generating comparative valuations in AvB scenarios? For example, could you point it at the mobile app space and identify a supply / demand vacuum if sufficient usage / purchase data were available? Developers could then use the app to inferentially generate the next app that needs to be created…
Nathan, the initial focus of the decison-making app is consumer oriented rather than business oriented so the initial version wouldn’t cover your example. It is comparative but it is not limited to the comparison of two things. I plan to handle the interface differently depending on the size of the set, moving from in depth side-by-side comparisons, to tabular comparisons or relational graph comparisons, to tabular or relational graph comparisons of groupings with the ability to drill into individual groups. With sufficiently granular usage data I think it should be possible to determine where apps need enhancement, and in some cases a set of identified enhancements might be sufficient for a standalone app and then the purchase data of the relevant apps could tied in to determine if market demand would be sufficient to support the app. The determination might benefit from the use of inference (Bayesian), but that its possible that other techniques might be more beneficial.
Thanks for the feedback on CloudHydra and I’ll keep that in mind when assessing what future projects to take on.
Pingback: Midas51, hello and meet Grail42 | Josh Heitzman on Codecrafting