michaelchu / optopsy

A nimble options backtesting library for Python

Home Page:https://github.com/michaelchu/optopsy/wiki

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Parameters selection

erv4gen opened this issue · comments

Hi Michael,
First of all, thank you for sharing your project with the community.
I've done a few tests over your code and find out that for a single leg spread (short put for example), your algorithm requires "leg1_delta" to be specified.
in optopsy/checks.py:

def singles_checks(f):
    return "leg1_delta" in f and _date_check(f) and _type_check(f)

Why you chose this parameter to be mandatory and is it possible to run a backtest without "leg1_delta" parameter?
Thanks!

Hi Valdimir,

Thanks for your interest in the project, you are right in that it is possible to run a backtest without "leg1_delta" parameter. However, my intention here is that even though you can theoretically use any parameter, when creating spreads there should be at least one parameter that specifies approximately where the legs should be. These parameters can relate to delta, price percentage, spread price, etc.

I happen to chose delta as i thought it would be the most likely used param to specify such information. I am open to expanding it, perhaps it would better to whitelist certain params that makes sense for the spread?

The problem with a delta is that it usually finally known only after the market is closed. So it's not the most reliable parameter to specify the spread.
I'd rather use price-related parameters (price percentage, spread price, leg price, etc) for minimal required parametes.

Do you happen to have intraday options data to test with? I have EOD options data, so delta would have been calculated and usable for me.

I use EOD data as well. The problem is that all greeks in the EOD dataset are recalculated after market close. That means that we can figure out the where or not the spread should be open only when the market is close already.
Using price percentage/spread price and other price-related parameters will be more realistic, imho

Good point,

i will turn this into an issue and address this in a future release.