Rework the commission into maker and taker commission about nautilus_trader

[scoriiu]

Cool, will keep this in mind. I agree that performance increase totally worth the effort. This is the reason I ended up here after all 👍 .

I also use old fashion print statements, combined with temporary raise statements in order to be able to follow the stack trace.

[scoriiu]

Your solution is pretty elegant, well done! I guess we can close this PR.

[cjdsellers]

Absolutely, let's extend the commission model.

[scoriiu]

@cjdsellers What is the purpose of using a rates dictionary in the commission calculator. Does commission changes from day to day for forex?

[cjdsellers]

So for some brokers there are sometimes different commission rates for certain products e.g. CFDs, or even certain FX pairs. The rates dictionary allows you to model that. The calculator also allows you to set a default rate, so if there are no special cases then that will be the rate returned for any query.

[scoriiu]

Shall I remove the minimum variable from the commission calculator since the rebates can be negative? Or leave it and convert it to a percentage instead?

[scoriiu]

Opened a WIP #50. Waiting for your feedback regarding the "minumum" value, but also feel free to comment on the PR.

[cjdsellers]

So the minimum is for the TAKER side, when the commission is calculated it is sometimes the min(the calculation involving the notional value, some minimum defined value). For instance IB has a minimum per order for different asset classes https://interactivebrokers.com/en/index.php?f=1590&p=fx
Its probably pedantic because a decent sized trading operation is always going to be above the minimum, however this models the actual commission pricing structure most closely.

So I'd say we need to change the param name to minimum_taker. Or even extract out a CommissionModel base class. Then for implementations such as BitMEX which have no concept of a minimum we just won't have that parameter in the inheriting class.

I can leave it to you to come up with a cool solution for that, or simply just re-implement so the minimum is ignored for a MAKER, and I'll come up with something.

[scoriiu]

Ok, please have a look. For now I renamed it to minimum_taker and ignored it for maker

[cjdsellers]

Great, I think what I'll do now is extract a base class and create a GenericCommissionModel which will include the minimum param, and a MakerTakerCommissionModel which includes seperate taker_rates and maker_rates as per BitMEX https://www.bitmex.com/app/fees.

[scoriiu]

Sounds good. Will the taker and taker rates be a dictionary which will hold the rates for all the exchanges or will it be up to strategy to configure the maker and taker rates in the MakerTakerCommissionModel?

[cjdsellers]

It'll hold the rates for all exchanges at this stage, because the Symbol includes both the code and venue, we can throw them all in there. It'll be up to the user to create that dictionary in a sensible way somewhere before passing it in.

In the domain model, a Venue can be an exchange, brokerage, wherever the trading takes place.

[cjdsellers]

We could keep some hard coded rates somewhere also for ease of use.

[scoriiu]

Ok, looking forward to see the code. On a separate note, my experience with cython is limited and yours is pretty reach, I wonder if you know of a way to debug by placing breakpoints inside the cython code?

[cjdsellers]

Ok, so I finished that refactoring. I've taken the rates out of the config dict because it depends on the type of commission model, it gets passed into a BacktestEngine just after the fill_model. So it's much more straight forward and extendable.

Thanks for setting up the extra testing there too. MakerTakerCommissionModel works properly.

I renamed SimulatedBroker to SimulatedMarket and in general want to get away from the broker centric language throughout the platform too.

[cjdsellers]

For Cython, it gets easier with some exposure. The performance increase is really worth the effort.

With debugging its a bit of a pain, you have to recompile all the extensions with LINE_TRACING = True in the setup.py
Probably not what you want to do. I tend to just setup really methodical unit tests and work through the logic slowly, or the good old temporary print statements.

If you ever do need/want to recompile everything from scratch though. The easiest way is to run the cleanup.py in the scripts folder. Then python setup.py build_ext --inplace and everything will recompile.

[cjdsellers]

A yes the temporary raise RuntimeError() is a great technique to get that trace! or throw in a value to the message too.