Column order/selection strategies with cash_sharing and flex_simulate_nb

[shiosai]

I'm currently using the from_order_func for maximum flexibility - so far without cash_sharing activated. To have a more realistic portfolio I would like to activate cash_sharing (everything is one group) but it seems to make only sense when using it with my own column order as the last columns might be at a disadvantage (no more cash left) otherwise.

It seems flex_simulate_nb gives now that flexibility 👍 as I can define a custom order (e.g. call_seq_out as in example ). It would be nice if someone could help me to clarify the following points:

• In the example sort_call_seq_out_nb is used to create the new seq by sorting after order_value_out. I don't understand the arguments like size though - at this point I might not know yet how many to order? Do I even need this function or are there other ways to create a valid call_seq_out?
• If a a sell order is given, would the cash be available right away (for follow up column) or only in the next row?
• Not directly related but I was wondering about running simulations multiple times when the outcome is non-deterministic (e.g. with reject_prob argument or a random element in column order) - is there already a way to aggregate multiple pf statistics or similar?

[polakowo]

@shiosai

• Calling sort_call_seq_out_nb is optional - it's for pure convenience, you can use this function in the case when you know exactly what orders you're going to issue so it produces a right call sequence for you. But you can always do it manually by changing call_seq in the non-flexible mode or by returning a column index along with the order in the flexible one. You don't need to create call_seq_out, just return column indices in the desired order in flex_order_func.
• After processing a buy/sell order, cash is removed/added right away.
• You can replicate your simulation column-wise, just tile your columns n times to create n independent simulations. Or to not waste memory, simulate and concatenate the results manually.

[polakowo]

@shiosai I should also say that this not only works as well but is actually much faster :)

[shiosai]

@polakowo So its not just simpler but faster and was there all along already. Your package is still full with surprises !

[polakowo]

@shiosai believe me, even I'm occasionally surprised haha

[shiosai]

@polakowo as a side note, repeating the same cash_sharing backtest multiple times with randomized column order leads (probably not surprising) to way better out of sample results when comparing different strategies.

Just the runtime increases linear with number of repetitions - so as next step I might try your suggestion to put all runs as extra groups/columns to have one test. Besides having the bonus of automatic statistics aggregation, do you think this would actually speed up the whole thing.. or does the runtime still kinda increase linear with column numbers (assuming one backtest has already ~400 columns - so instead of 10 runs ala 400 we have one run ala 4000)?

[polakowo]

@shiosai repetitions usually scale better for big shapes. Since you already have 400 columns, I'd go with a for-loop.

import vectorbt as vbt
import numpy as np
import pandas as pd

%timeit vbt.Portfolio.from_orders(np.full((10000, 400), 1), size=np.nan)
243 ms ± 2.44 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit vbt.Portfolio.from_orders(np.full((10000, 4000), 1), size=np.nan)
2.79 s ± 103 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit [vbt.Portfolio.from_orders(np.full((10000, 400), 1), size=np.nan) for _ in range(10)]
2.45 s ± 12.9 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Small shapes still love to be stacked:

%timeit vbt.Portfolio.from_orders(np.full((1000, 400), 1), size=np.nan)
23 ms ± 62.6 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

%timeit vbt.Portfolio.from_orders(np.full((1000, 4000), 1), size=np.nan)
217 ms ± 8.16 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit [vbt.Portfolio.from_orders(np.full((1000, 400), 1), size=np.nan) for _ in range(10)]
230 ms ± 1.69 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

But the difference is negligible. You should definitely benchmark and decide what's more convenient for you.