Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Reformat/cleanup OptionStrategies This file was breaking pretty much every style convention in LEAN. There are other things that should be addressed in here that weren't, such as passing non-argument names as argument names for ArgumentException, as well as preferring constructors over property initializer syntax, but such changes aren't being made to keep this commit strictly reformatting instead of refactoring. Added braces and reformatted long lines to make code more legible. * Add abstract base class for OptionStrategy Option/UnderlyingLegData This allows us to create either or and later use the Invoke method to push it into the appropriate list on OptionStrategy. * Replace O(n) option contract search with 2 O(1) TryGetValue calls A better improvement would be resolving the correct symbol in the strategy, but this immediate change is instead just focused on removing the O(n) search inside a loop. * Add BinaryComparison and supporting methods in ExpressionBuilder We're going to use these binary comparisons to make it possible to create ad-hoc queries against a collection of symbols. Using these expressions, along with type supporting composition of these expression, we'll be able to define predicates that can declaratively define how to match an option strategy with an algorithms current holdings. * Make GetValueOrDefault defaultValue optional Was receiving ambiguous invocations leading to neading to invoke this method explicitly (LinqExtensions.GetValueOrDefault) instead of being able to use it as an extension method. Making the default value optional seems to have resolved this ambiguity, leading to cleaner code in the OptionPositionCollection (forthcoming) * Add OptionPosition and OptionPositionCollection OptionPositionCollection aims to provide a single coherent interface for querying an algorithm's option contract positions and the underlying equity's position in a performant, immutable way. The immutability of the type is necessary for how the options matcher will operate. We need to recursively evaluate potential matches, each step down the stack removing positions from the collection consumed by each leg matched. This will enable parallelism of the solution as well as simplifying the mental model for understanding due to not needing to track mutations to the collection instance. * Add Option test class for easily creating option symbol objects * Add OptionStrategyLegPredicate and OptionStrategyLegDefinition The definition is a composition of predicates, and each predicate supports matching against a set of pre-existing legs and a current position being checked for the next leg (this leg). In addition to the matching functionality, it also supports filtering the OptionPositionCollection, which is where much of the work for resolving potential option strategies is done. By successively filtering the OptionPositionCollection through successive application of predicates, we wil end up with a small set of remaining positions that can be individually evaluated for best margin impacts. All of this effectively unrolls into a giant evaluation tree. Because of this inherent structure, common in combinatorial optimization, the OptionPositionCollection is an immutable type to support concurrent evaluations of different branches of the tree. For large position collections this will dramatically improve strategy resolution times. Finally, the interface between the predicate and the positions collection is purposefully thin and provides a target for future optimizations. * Add OptionStrategyDefinition and OptionStrategyDefinitions pre-defined definitions The OptionStrategyDefinition is a definitional object provided a template and functions used to match algorithm holdings (via OptionPositionCollection) to this definition. The definition defines a particular way in which option positions can be combined in order to achieve a more favorable margin requirement, thereby allowing the algorithm to hold more positions than otherwise possible. This ties into the existing OptionStrategy classes and the end result of the matching process will be OptionStrategy instances definiing all strategies matched according to the provided definitions. * Add OptionStrategyMatcher and Options class, w/ supporting types OptionStrategyMatcherOptions aims to provide some knobs and dials to control how the matcher behaves, and more importantly, which positions get prioritized when matching. Prioritization is controlled via two different enumerators, one controller which definitions are matched first and the other controller which positions are matched first. Still unimplemented, is computing multiple solutions and running the provided objective function to determine the best match. When this gets implemented, we'll also want to implement the timer. For anyone looking to implement these features, please talk with Michael Handschuh as there's a particular way of representing these types of combinatorial solutions (a 3D tree) that can be used as a variation of the linear simplex method for optimizing combinatorial problems. * OptionStrategyMatcher: Address PR review comments * Ensure created OptionStrategy legs all have the same multiplier Each leg definition match gets it's own multiplier which indicates the maximum number of times we matched that particular leg. When we finish matching all legs, we pick the smallest multiplier from all the legs in the definition and use that as the definition's multiplier. When we go to create the OptionStrategy object we MUST make sure we're using the multiplier from the definition and not from the individual legs. This change fixes this issue and also provides a guard clause to ensure that we're not trying to use a multiplier larger than what was matched. * Add XML docs for OptionStrategyDefinitions from OptionStrategies
- Loading branch information