Create the optimization possibilities looper

[thinkjrs]

Creating the Optimization Possibilities Loop (OPL)

In sim-exchange we have a standing queue where orders sit, waiting to be matched via a price on demanded cash flows, given user parameters.

Though the ranking/matching itself takes place via the MatchingAlgo, by unordered dicts of likely possible matches, the OPL is responsible for ultimately choosing which portfolios to send to the MatchingAlgo.

Choosing which combinations to calculate and store

To accomplish this task, the OPL needs to store a queue of possible portfolio combinations of queued investor-user or asset-user cash flows, depending on the parent owner of the OPL instantiation. As these cash flows are simply packages risk, return, times, and feature objectives (say 'pop music' or 'aggressive investor'), the target discretization selected will be critical and should be based on target portfolio outcomes.

Start with simple mean-variance optimization

Assume no short-sales to start (though this can be relaxed later) and simply allocate cash flows in the respective dealers' queue. Your optimization targets are based on the discretization selected.

Selecting the discretization

Remember, you're given a tolerance from the firm.

1. Pick an initial partition for risk and return parameter (why not start with our sample cash flow set +- tol? for parameters)
2. Divide range evenly for each parameter and allocation for all combinations of targets

OPL API

class OPL:
    """
    # `OPL` - Optimization Possibilities Loop

    Given strips of supply and demand calculate possible portfolio combinations.
    """
    def __init__(self, asset_queue: list, investor_queue: list):
        """
        ## Parameters
        - `asset_queue`: a list of asset user Python Dataclasses
        - `investor_queue`: a list of investor user Python Dataclasses
        """
        self.asset_queue = asset_queue
        self.investor_queue = investor_queue
        self.combos = ... # dict-like storage of fully-allocated combinations
        self.queue = ... # FIFO queue to send chunks of ports to MatchingAlgo

Tasks

Add to these as/if/when requirements evolve!

• [ ] Naive implementation of the following:
• [ ] OPL class
• [ ] combos datastructure (should include auto communication mechanism if one is not developed separately)
• [ ] queue datastructure. This can be a simple [Python queue] Let's wait for @RKoulikova to work on this--she has a cool tree implementation coming along. (https://docs.python.org/3/library/queue.html) but investigate using SimpleQueue over Queue.
• [ ] Assess and critique design choices in this issue
• [ ] Add additional requirements + specifications as needed herein
• [ ] Document technical usage of OPL in READMEs and inline

[Zhrong25]

Implementation Ideas:

• Considering using mean variance and scipy.optimize function to meet curtain threshold and optimization functions (return, holding period, risk, genre, investor-diversity, asset-cap, etc)

• There will be a queueing mechanism or lock to finish OPL computation before adding or removing orders, probably should be implemented in the Dealer class which holds the OPL

• Could add multithreading to facilitate the computation of OPL for each investor

I am still confused about how matching engine and OPL should coordinate with each other. Suppose OPL in the investor side gives optimized allocations, based on my currently understanding, the matching algo will rank the those optimized portfolio? and how these ranked combos will be simulated to be traded between dealers.

[yzhao0429]

Some idea about Implementation (caveat: ignored the dealers):

1. artists' fund requirement can be partially filled (let remaining fund requirement = R_i)

2. try to allocate every dollar of investors, as long as there are enough artists (let remaining capital = K)

3. Therefore, the matching problem becomes a mean-variance optimization (among group of artists with target genre and expiration date), with the constraint that, the portion allocated on each artist is between 0 and R_i/K, and the total amount of investment exactly equals to K

[thinkjrs]

Some idea about Implementation (caveat: ignored the dealers):

1. artists' fund requirement can be partially filled (let remaining fund requirement = R_i)
2. try to allocate every dollar of investors, as long as there are enough artists (let remaining capital = K)
3. Therefore, the matching problem becomes a mean-variance optimization (among group of artists with target genre and expiration date), with the constraint that, the portion allocated on each artist is between 0 and R_i/K, and the total amount of investment exactly equals to K

And flip this around, exactly for investor users:

1. Investors' fund investment requirement can be partially filled (let remaining investment requirement = R_i)
2. Try to allocate every dollar of the asset users, as long as there are enough investor users (let remaining capital = K)
3. MVO (among group of investors w/target genre and expiration date), constraint that the portion allocated by each investor is between 0 and R_i/K and the total amount invested equals K

See what I did there? This is why we have separate dealers--they're solving the same problem but exactly backwards. Investor-users exchange a immediate cash flow for the asset-users' future cash flow.

[thinkjrs]

Implementation Ideas:

• Considering using mean variance and scipy.optimize function to meet curtain threshold and optimization functions (return, holding period, risk, genre, investor-diversity, asset-cap, etc)
• There will be a queueing mechanism or lock to finish OPL computation before adding or removing orders, probably should be implemented in the Dealer class which holds the OPL
• Could add multithreading to facilitate the computation of OPL for each investor

I am still confused about how matching engine and OPL should coordinate with each other. Suppose OPL in the investor side gives optimized allocations, based on my currently understanding, the matching algo will rank the those optimized portfolio?

This is exactly what I was thinking: the matcher actually helps us decide whereas the OPL is tasked with providing information for that decision, quickly & efficiently.

and how these ranked combos will be simulated to be traded between dealers.

Not sure yet! I do know that we'll need some type of "space-shrinking" strategy in the dealer design, since actually calculating out every possibility at O(N^2) is literally impossible. Let's be sure to chat about this today.

[thinkjrs]

@yzhao0429 @Zhrong25 I wanted to comment on something I said above, so as to minimize confusion:

actually calculating out every possibility at O(N^2) is literally impossible.

Users (asset users and investor users) for a Dealer arrive over time via our simplistic Poisson process assumption. Of course we could calculate the N^2 space of all of the users in the book--no problem, trivial.

Why is N^2 impossible?

What I mean by "impossible" is that we should not assume our current set of users is anywhere close to the actual population of users from which we have to allocate cash flows.

I claim we (me, you, and most everyone else) don't have a clue of actual supply/demand for digitally exchanged cash-flow assets that haven't yet been exchanged! If this is the case, then it must be that we do not yet know about the "investment universe".

Investment Universe - OPL magic

The OPL you two are building is actually part of the solution to "finding" the true investment universe and is really exciting. From our calls, remember that you're creating a mechanism to use current user information for risk/return bounds, then "smartly" calculating out potential portfolios and saving those, on a grid.

[yzhao0429]

OPL_primitive.txt