My goal is described in my old post:
Only here I am trying to take into account daily upper and lower bound of price for target order.
target order or not, I did try to follow your suggestion in old post, but:
Having a custom Sizer
This wont work for me since my order are with specific size, a global custom Sizer will be overwritten.
2.Having a commission scheme
I read the custom commission scheme, dont see how this will work. The
def _getcommission(self, size, price, pseudoexec)
only pass in the execution price for orders, not previous bar's (when the order is created) close price, I wont be able to compare these two prices thus impose an inf commission accordingly.
Official name for such trading restriction is called daily maximum price fluctuation I think, and it is common in commodity futures as well, might be a good idea to implement such feature natively.
@backtrader Every trading day is composed of thirteen 30 min periods. Each single trading day is also broken up into four 2 hour periods. Each trading day has 6.5 hours in it. 6.5 is not evenly divisible by 2 hours. This means that one of the four 2 hour periods will be using data that is actually 30 mins long. Backtrader makes the 2 hours period that is composed of 30 mins worth of data as the first 2 hour period of the day (this is the first 30 minutes of the trading day). When trying to compare a strategy that was created using a different platform, like tradingview.com, the 2 hour period data is inconsistent. Tradingview.com, as well as real time data for live trade execution, uses the last 2 hour period/candle stick of the day as the 2 hour candle stick that is composed of 30 min data (because remember, 6.5 is not evenly divisible by 2 so this last candle stick of the day would equal the .5 remainder), as opposed to backtrader which uses the first 30 mins of the data from the day to print (the .5 remainder) 2 hour candle stick. In backtrader, is there any way I can change the 2 hour period that is using 30 mins worth of data(the .5 remainder) to the last 2 hour period of the trading day instead of it being the first 2 hour period/candle stick of the trading day?
I settled on:
Adding a step to the broker's next method that will update each comminfo (possibly one for each data feed) with the new respective FX rate
Update the methods of a new commission class that extends CommissionInfo as per the original suggestion.
My first post was just confused. With the 2 changes here, the commission info objects have the current rate and apply it to the calculations, and only one minimal change is needed to the broker, and no changes to Trade or other classes are needed.
You may want to enlighten us and let us know where that comes from. There isn't such a thing.
Ahh, good point. It is a variable I'm keeping track of in the strategy to count the number of times I put on or take off a hedged position.
Docs - Analyzers
Docs - Analyzers Reference
Thank you. bt.analyzers.PositionsValue seems to give me what I need when I add cash=True.
One is telling you the leverage that will be applied to an asset when acquiring it.
The other is telling you the actual leverage of your account, which is obviously 1 if nothing has been bought.
It's in the topic you link to:
@backtrader said in get_leverage() calls:
@ThatBlokeDave said in get_leverage() calls:
However, self.broker.get_leverage() appears to be doing a different calculation
It's not a different calculation. It's different altogether. Invoking that method, which is intended for user consumption unlike the one above, reports the actual leverage level in the market.
@backtrader said in bt for low-frequency / trend following trading:
You don't have any other approach if you want to operate before the close. You need to have the price updated before you operate.
Ok, and how can I get it? Alpaca live account isn't allowed for me. What API with paper-trading abilities should I use ?
It seems you have missed the meaning of the answer above.
A single account broker means that any action on an asset, regardless of the origin strategy will affect what the other strategies are doing
From a logical point of view strategies are run in parallel. The implementation executes them sequentially because Python doesn't have parallel thread execution (the thread model is valid for I/O bound threads but not for CPU bound threads which is the case here)
What you want is clear, but it's not there.
Hi @diamonddogs95, I used https://github.com/xFFFFF/Gekko-Datasets to generate a database in SQLite. Then I open it and run this query https://github.com/rodrigo-brito/backtrader-binance-bot/blob/master/dataset/queries.sql