Make the library more Options friendly

[majdzadeh]

This pull request contains a number of changes to make the library more Options friendly:

• Use multiplier for Options instead of hard-coded values
• Make get_increment() work properly for an Options order

Description by Korbit AI

What change is being made?

Modify the calculation of order value for options by multiplying with a generic multiplier instead of the fixed value of 100 in the _on_filled_order method of strategy_executor.py.

Why are these changes being made?

This change generalizes the code to accommodate different option contract sizes other than the fixed multiplier of 100, enhancing the flexibility and accuracy of the order value calculation for various option types. This approach is necessary to support assets in markets where the multiplier might not be 100, providing a more adaptable solution.

Is this description stale? Ask me to generate a new description by commenting /korbit-generate-pr-description

[korbit-ai]

Important

Required App Permission Update

Noise Reduction Improvements

This update requests write permissions for Commit Statuses in order to send updates directly to your PRs without adding comments that spam notifications. Visit our changelog to learn more.

Click here to accept the updated permissions

_{To accept the updated permissions, sufficient privileges are required}

[korbit-ai]

I've completed my review and didn't find any issues.

Files scanned

​

File Path	Reviewed
lumibot/strategies/strategy_executor.py	✅

Explore our documentation to understand the languages and file types we support and the files we ignore.

Check out our docs on how you can make Korbit work best for you and your team.

Loving Korbit!? Share us on LinkedIn Reddit and X

[majdzadeh]

@grzesir
Whenever you're free, would you please share your thoughts?

[grzesir]

@grzesir

Whenever you're free, would you please share your thoughts?

This looks good except for the get increment part. Could you explain your reasoning there?

[majdzadeh]

This looks good except for the get increment part. Could you explain your reasoning there?

Thanks a lot for your feedback @grzesir
In case of Options, when we sell, we a get a premium therefore, we have a positive cashflow. On the other hand, when we buy, we pay a premium therefore, we have a negative cashflow.

[grzesir]

This looks good except for the get increment part. Could you explain your reasoning there?

Thanks a lot for your feedback @grzesir In case of Options, when we sell, we a get a premium therefore, we have a positive cashflow. On the other hand, when we buy, we pay a premium therefore, we have a negative cashflow.

That makes sense, but how is that different from any other asset?

[majdzadeh]

That makes sense, but how is that different from any other asset?

Currently and in the context of get_increment(), regardless of the underlying asset of an order, if it is a selling order, we get -order.quantity and if it is a buying order, we get order.quantity. I believe this should be vice versa in the case of an Options order. As a side note, the previous behaviour of the method is kept untouched.

[majdzadeh]

@grzesir
Kindly let me know if you think a modification is required; otherwise could you please approve the PR? Just to reiterate, the original behaviour of the method (get_increment()) is kept untouched.