aggregate profit target for cumulate orders

Forums ProRealTime English forum ProOrder support aggregate profit target for cumulate orders

Viewing 13 posts - 1 through 13 (of 13 total)
  • #183888

    When using cumulate orders, SET TARGET %PROFIT sets separate targets for each entry.

    What’s the best way to code an aggregate target, so that all positions close at the same point?

    eg  positionprice * 1.02 ???

    #183889

    At least one point of warning :

    Personally I can’t get this working in Live the same as in BackTest (I did not try Demo);
    With all the “power” I have in me, I will obtain net results in the positive all right, but always with losing individual additional position. And this is because the BackTesting *does* show individual positive results (which is what my targets are anyway). So I seem to be out of control …

    Is this what you kind of run into too ?

    #183890

    This is what I mean (attachment). Only the top-one and the 3rd make profit in each position. Still the profit of both (each time) is more than what backtests show (also forward). Thus I seem to find it OK. But it feels totally wrong.

    #183898

    Don’t set any target. Manage it yourself, instead,

    PositionPrice is the average entry price. Each bar compute the TARGET price and place a pending order (Limit or Stop, accounting for the required distance, as well):

     

    #183904

    can’t get this working in Live the same as in BackTest

    backtest does seem to get confused by cumulate orders – number of trades and the bar count is often off – but I don’t get the problem you describe.

     

    Manage it yourself, instead,

    Thanks Roberto, that is the sort of thing I had in mind but I don’t understand what Distance is for if I just want PositionPrice + 2% ?

    why it would be a Stop order? Surely the target is always going to be at a better price and therefore a Limit Order, no?

     

    #183907

    You can never tell what happens in a single bar, thus accounting for all options isn’t bad.

     

    1 user thanked author for this post.
    #183926

    backtest does seem to get confused by cumulate orders – number of trades and the bar count is often off – but I don’t get the problem you describe.

    It may be too hard to explain by me, but while I do exactly as Roberto suggests (“do it yourself”), I tried to warn you for *then* running into the issues I described. In other words, this may urge for solutions you ask for and *those* I would not be able to code (e.g. * 1.02). Thus :

    If you’d do it like Roberto suggests, it is out of control.

    I know this is related to the spread not being incorporated into PositionPerf while I can exactly mimic and counteract all that. Thus, up to the cent I have all equal to what the backtest (or forward running) does/executes, but it is not equal to what Live makes of it. And adding whatever spread to it does not help a thing. And mind you please, all Enters and Exits happen at exactly the same points in forward backtest vs Live (this tells me something about decency in the coding).

     

    number of trades and the bar count is often off

    That is not my experience if you only know how to look at it. Thus, each additional entry is another trade (the exit is only one which is correct when you ditch all at the same time) and the barcount of the additional trade is always 0 (this is just a way of representing it, and officially is not correct but who cares). This is when you exit all at once (which is what you implied as a request, I think ?).

    Summarised (and I hope I can make this clear) : when you additionally enter, you also grab additional spread and the calculation of that seems off in Live (!).
    I could suggest : if additional entry would imply twice the spread as a kind of penalty, *then* I could understand something of it. But it’s my estimate that this is not so. 😉

    Lastly, when the profit of the additional enter is sufficiently high you won’t notice this (see the two higher-profit trades in my earlier screenshot) because you are satisfied with the result; only if you know that your (additional) trade impossibly loses because you won’t exit (apart from running into SL), then you notice. And I repeat : if all goes well in backtest, how to design something that works out in live with different behaviour ?
    Oh, maybe I should mention that I have no issues whatsoever with “single positions”. With this I am not claiming that is it not me, but it is either the backtest not understanding something, or the Live doing something odd. And because the backtest acts to my expectations, it can be the latter ? … I like to repeat this too : the net result in Live (for combined trades) is better than in backtest, but how to (psychologically) live with the individual (small-ish) losses you see happening ?

    Roberto – somewhere you told that you “additionally buy” all the time. What is your experience regarding this ? (“never saw anything wrong” is an answer !)
    Thanks !

    #183942

    there are different ways of using cumulate orders. I only add entries within a specific range ie not too far from the original entry, or sometimes only at a better price, so I treat it as one aggregate trade. Then I use a breakeven or trail based on positionprice, so they all get the same stop. Exits tend to be exactly as expected. I don’t know what you mean when you say that Live gets the spread wrong? You’re going to exit at the bid price or the offer price +/- any slippage (which of course is not calculated in backtest) … what else is there?

    I’ve never bothered to check the live performance vs backtest, but I don’t put much faith in backtest results in general – it’s just a vague indicator that the algo ‘might’ work in real trading conditions. Live trading is the acid test, and if that’s working for you then I’d say forget about whatever weirdness you see in the backtest 😁

    As for the bar count, I always have a max number of bars any trade can stay open so yes, it does matter. But I’m not sure whether the aggregate closes all together, or separately? doesn’t happen that often, so I’d have to watch out for it.

    #184178

    Roberto – somewhere you told that you “additionally buy” all the time. What is your experience regarding this ?

    I can’t remember when I said that, but… yes, I sometimes write strategies that accumulate positions. They require greater starting Capitals due to higher margins & drawdowns, and they certainly imply more efforts when coding. Apart from that I have no objections to using this approach.

    I probably can’t understand thouroghly the question about the spread paid on a single contract or on additional contracts. If spread is 1 point, you will pay 1 point for each contract, no matter if you buy 1 contract now, then an additional one after a few bars later, instead of buying 2 contracts now.

    Is that what you meant?

     

    #184205

    Dear people,

    (maybe skip because it is too hard to explain)

    In order to explain what I mean, I best describe practice :

    When you fill the spread in de (backtest) Editor, you (I) can easily see that it behaves exactly as expected. In attachment 1 and 2 this is the yellow line, and it perfectly matches the spread vs contractamount. Also, my self-calculated gain (not via PositionPerf) always matches the backtest and forward testing. Until … until I start to add position underway. Now, it is relatively complex to check the merits of everything because we’re obviously dealing with averages for position and taken spread (mind you, still backtest / forward test). And, I don’t think I have to tell you that once I have a gain of +100 and take extra position, the gain drops steeply, like 50% when adding the same amount of position as already was in there *plus* additional spread. I can summarize this with : No, I can not mimic that myself, graph it like the examples in the attachments and *now* that I am doing this 100% OK.

    This lead to using PositionPerf instead of my own calculations, with the lucky outcome that now my graphs do what I expect, only by a simple replacement of MyOwnGain with PositionPerf. Except …

    Except for that PositionPerf does not contain any spread at all;
    Nicolas explains in his documentation that no BrokerFee is contained in PositionPerf (which is logic) but this thus also doesn’t contain spread. Well … in Backtesting / Forward testing that is, and how to know it is there in Live …

    I was able to add the theoretical spread myself (PositionPerfReal – PositionPerf + Spread) and as I told in the earlier post, that matches to the cent what appears in the closed orders list (and the gain), *also* for added position. Thus, it seems that I overcame the hurdles and at least now can do how the backtesting has been programmed. Unfortunately that does not match reality. A reality which I also always can “match” and sync with forward (or back) testing (except for the varying real spread), but I can NOT accomplish that with additional position.

    If you’d scroll back to my first post with screenshot of live … compare that with the 3rd attachment of backtesting below. This is not from the same data (time period), but you will believe me if I tell you that none of these “0 bars” exits ever goes negative, because I just don’t allow it (although the lot could run into a very occasional StopLoss). Thus with backtesting / forward testing this is always 100% positive + positive, while with live this is in 90% of cases positive with negative. And this is because my mechanisms to also make that additional trade positive, apparently don’t work. And in the base it uses the exact same PositionPerf + Spread to see what I’m at.

    I can make it even more challenging by telling that I surely am able to let all be positive + positive in Live, but this is with my own math of the gain, and unfortunately I can not graph that (it is just too complex to do because of too many variables must be taken into account …).

    In the 4th attachment I try to show you how complex things actually are, while telling you that here the graphing works as should. The blue UpArrow buys additional position, which readily makes drop the gain line (green) right above the white vertical line, but where the vertical scaling is not adjusted.
    We know that a. the spread hammers upon that additional buy and b. that in this case the price also drops right after the buy (see the pink cross and eventually the pink triangle). Thus is seems evident that there can’t be any gain in this second buy. Still the backtest shows 277,52 for the original position and 105,78 for the additional buy. My graph shows 368 prior to the first drop you see and it shows a final PositionPerf incl. spread of 232. The 368 ~ resembles the two trade results (277 + 105) and the 232 is nowhere close. And you know what ? the real Live trade would show probably 350 or so minus ~20 for the additional trade. And with all the cases I examined, this looks right. Same as you see in the 3rd attachment … this looks right to lose in the additional trade. But it looks right with my own graphing ?

    So I am in a kind of vicious death circle. I can’t control it.
    And then to think that this was the answer to nontheless’s question. 🙁

    #184210

    Here the screenshot of the last described situation; LastPositionPerformance is including spread (added by myself). All works with that, and the table under it shows what the backtest makes of it for profit. if I’d leave out the spread it changes only little (say 50) but if I really leave it out, the trade obviously runs very different.

    Thank you for listening. 🙂

    #184214

    If spread is 1 point, you will pay 1 point for each contract, no matter if you buy 1 contract now, then an additional one after a few bars later, instead of buying 2 contracts now.

    Of course. The difference with what normally happens (e.g. nonetheless may additionally buy at the lower price), I buy additionally in the trailing trajectory. Now spread suddenly matters a lot because it could eat the further profit to get easily. But this is thus also how I notice it all quite easily.

    I think the conclusion must be that the Live environment is fine, and that the backtesting fails on this part. All what happens for net result is that I can’t create something with fairly predictable results. In the end I am to blame myself, just because I can’t get the debugging (graphing) to work with this.
    Why PositionPerf does not includes spread (this is the base of the issue) is something else, because it would be able to do that, if only the spread is fully consumed at the entering (filling)of the order(s). The backtest works like that perfectly for self-calculated gain. Live should resemble that as well, no matter spread may be eaten in two stages (if so) – at enter and at exit.

    Lastly, the fun is that I come from IB where Commission applies and no way that is incorporated in PositionPerf (if can’t). This is how I am used to it in the first place (and never used PositionPerf). But this (IB testing) was without aggregated positions …

    #184312

    When you fill the spread in de (backtest) Editor, you (I) can easily see that it behaves exactly as expected. In attachment 1 and 2 this is the yellow line, and it perfectly matches the spread vs contractamount.

    Well, not so exactly. Thus this is where it starts to go off, I now know (thank you @zilliq). The point is, it does something, but what it does is not correct.
    IMPORTANT : BIG BUG ON SPREAD !

Viewing 13 posts - 1 through 13 (of 13 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login