@backtrader said in Matching of stopLimit orders:
@sandro-böhme said in Matching of stopLimit orders:
If you see other problems please tell me as well as I plan to trade real money with that code.
You need to see the problems and think twice about your money.
Thanks for taking the time to respond @Backtrader. That's much appreciated!
Are you expecting people to read and debug your code for you? Problem #1.
No, I don't but I wanted to give the opportunity that people can do that if they want.
I wasn't sure why you was assuming 6.9994 is the Limit price. I worried that you actually had a look in the code and I made a mistake there and mixed something up.
Log things properly, because I can have a quick look at the log and you can today relate the code to the log. When you look at the log in the future you won't know what it relates too. If there are ohlc values and trigger and limit prices, log it all. And log the version of the code you are working with if you ever want to relate the log to the actual code. (you may log a git sha hash or something, but something that lets you relate the log to the actual code)
Thanks for the hint. I agree that it makes sense to at least log the ohlc values and trigger and limit prices.
In any case, setting the Limit
price of a sell-StopLimit
below the trigger price means you want to give money away for free.
Let me explain why I do that so you can correct me if I'm wrong.
Assume I set the limit order to have the same price as the trigger price to not give away money for free.
As I send a stop limit sell order I expect the market price to drop when the order is triggered and the limit sell order is added to the order book.
But if the price drops very fast not all the other sell orders before mine could have been bought away by buyers before the market price is below my limit sell order. Then my sell order would be too expensive for the buyers and not get filled.
The lower my limit price is compared to the trigger (stop) price the higher the chance that my sell order gets filled.
This is why I would say I give away the money to pay for lowering the risk of the sell order not to get filled.
@sandro-böhme said in Matching of stopLimit orders:
Thanks a lot, that's a very good point!
Problem #2.
It's not a good point. It is simply the point. It doesn't matter if 6.9994
is your trigger or limit price. It is never reached when your order is alive. Your order can be neither triggered nor executed.
Of course you are right again.
I just haven't checked it by myself at that time and wasn't sure if there is maybe (also) a bug in my code which is why I didn't know yet it was the point.
I'll compare it with the other bar and I guess I'll see the difference.
If I don't I'll try to find the matching logic and debug the code to better understand the behavior.
You don't need to understand the matching logic. It is as easy as: it cannot be matched if the order prices are not in the range of the bar.
You are absolutely right. Again... :-)
You need TRADING experience.
Absolutely. I'm working on that as well. To be precise I would say I'm towards the end of the "Conscious Incompetence" stage of the stages of competence. So at least I should have left the Dunning-Kruger effect behind me ;-).
In this thread I already learned quite a bit thanks to your feedback!
When you have TRADING experience, how and when orders are matched will be obvious to you. My suggestion: spend several hours see how things work in a market.
There is no doubt that will happen. Not only regarding trading in general but also when I run my code with real money agains an exchange. I plan to set breakpoints, examine the actual values I get from the exchange and thus always have the chance to stop the code from running. Even though I cannot stop the exchange to execute the order I have send some buy orders already with prices well below the market price to see if they show up on the exchange the way I expected. I also did that with careful debugging and examining the actual values of the objects.
See this other recent thread: Community - Stop Order execution price? Why does the poster believe he has found a flaw in the logic for the execution go a Stop
order?
- Simple: the poster has NO trading experience.
Yes I've seen that as I read some threads (and docs of course) before posting. This thread was actually the reason I was specifically talking about a stop-limit order and not only about stop-loss.
@sandro-böhme said in Matching of stopLimit orders:
Basically submitting the sell-StopLimit takes the time of a candle
Problem #3. This is a completely wrong statement. And very dangerous. The candle you are working with contains PAST prices. Here and China. Order submission DOES NOT take the time of a candle. The candle DOES NOT longer exist. You work and can only work with PAST information.
The order is submitted and can ONLY be applied and evaluated with the next set of incoming prices.
Sure I'm sorry that I wasn't more specific to be really clear.
I'll try to describe how I understand that more clearly now so you can correct me if I'm wrong.
The next()
method runs after a candle has been closed when all final ohlc data for that candle is available. Judging from the logs the notify_...()
methods seem to get called directly after the first next()
and before the subsequent next()
. One could see this as the time during the candle.
I submit the sell order when I get the "cancel" notification in notify_order()
. This is after the previous next()
call and before the subsequent next()
call. As written above I think this is the time the ohlc data for the subsequent next()
candle is created. Technically I cannot really know that it takes the full time of the candle as I could as well get the notify_order()
call at the last minute of the 15m candle. So of course you are right that this is a wrong statement.
@sandro-böhme said in Matching of stopLimit orders:
I think the ParabolicSAR assumes that I can get the order accepted at the same candle
Problem #4
The ParabolicSAR
assumes nothing. The indicator simply delivers a value. It is a math formula. You are making the assumption. Don't put the the blame on the math. And yes wording is important because it shows how you perceive things.
If I would like to make use of it as a stop price as in (Stop And Reverse) I guess I need to find a way to get the order send and accepted at the beginning of a candle or more precisely during a candle with the current PSAR value. Currently I always have a candle where there is no sell-stop-limit order set as I submit the order during notify_order()
which is before next()
and get it accepted after next()
.
But of course you are right. The indicator simply delivers a value as every other indicator.
@sandro-böhme said in Matching of stopLimit orders:
Is there a way I can get the next() and notify_...() methods called multiple times during a candle independent of the time frame e.g. in a 1m timeframe during backtesting and live trading?
Problem #5
Is there any way in which you can get future information? Yes, by entering the vortex which is generated with tachyon particles and a thoron emitter whilst the frequency of the shields is remodulated to match the rotating harmonics of the reverse polarity of the feedback impulse traveling over the tractor beam.
Oh yes, you will read about replaying: Docs - Data Replay. But of course, you will then have to decide when to make the trade within the bar and even with replay ... the prices you see are already PAST prices. What you see is always PAST data.
Thanks for that information that is very helpful! I'll have a look into data-replay.