Live errors out due to Optimzation Parameters
Forums › ProRealTime English forum › ProRealTime platform support › Live errors out due to Optimzation Parameters
- This topic has 9 replies, 4 voices, and was last updated 2 years ago by PeterSt.
-
-
05/28/2022 at 10:43 AM #194052
So on we go with Bug # 389. And counting.
Yesterday we came to speak about me not being able to leave my Optimization Parameters where they are and hand the Strategy to Live (or Demo-Live, does not matter). This immediately errors out with what you see below. “An internal error occurred”.
Now what does PRT make of my Optimization Parameters when it transfers them to the code :12345678910defparam cumulateorders = falsedefparam preloadbars = 2000ONCE BandOffset = 1.81ONCE BreatheBarsSetL = 3.0[...]ONCE TrailAfterUnderL = 11.0ONCE TrailAfterUnderS = 10.0TimeFrame(60 seconds,UpdateOnClose)You feel it comin’ right ?
The stupid thing does not respect my very first TimeFrame command in there. This, while I carefully had to declare all my variables which are to be Optimization Parameters, under that specific TimeFrame.
So mind you, the beginning of my code is like this :1234567891011defparam cumulateorders = falsedefparam preloadbars = 2000timeframe(60 seconds,UpdateOnClose) // 24-04-2022,PS, Like this because it now nags about it being different than 1 minute.// Define Optimization Parameters.//*** ONCE BandOffset = 1.81//*** ONCE BreatheBarsSetL = 3.0//*** ONCE BreatheBarsSetS = 2.0[...]and thus all the Parameters are defined under the 60s TF.
Now I change the backtest version of this so it becomes the same as what PRT makes of it when putting it to Live. Thus, the Once declarations above the TF command as shown in the first snippet above. Now the error in the 2nd attachment is totally clear. It is the dreaded error we all hate when working with MTF (Multiple TimeFrames) because it is kind of against us (probably unavoidable). Like now (avoidable !). N.b.: Chart is in 1 minutes, which officially is not equal to 60 seconds.
Now maybe someone can tell me :
389 bugs or less or more, I am always the only one with the issue. Yes, I am marked for that. But how is it possible that with actually all the things I come up with, I am the only one ? Here are some suggestions :
- People encounter the same but don’t bother to proceed on it. They find another functional solution. Or they go to MT4, whatever.
- People don’t use Optimization Parameters at all.
- People did not know about the possibility of the “Input” parameters (likely, because there’s no manual where this is written in).
- People see the error, but don’t investigate further and work around it (looks like #1).
#4 is explicitly me. I am so numb by now about all the bugs which never get solved and which takes quite A LOT of time to describe with screenshots and all, that I virtually have given up on it.
Do notice that it does not matter whether I put in “teasing” topics like this one; ProRealTime monitors this board and they did not solve a single thing of all I put in there.
Technical reports ? don’t make me laugh.
And there goes my mood again.
But I shouldn’t, because like with all, I learned to live with it.05/28/2022 at 11:59 AM #194063not being able to leave my Optimization Parameters where they are and hand the Strategy to Live
Does this (also) happen if you use Timeframe (1mn, updateonclose)?
I NEVER get this happening to me and I am optimising dozens of Algos per week.
Although I don’t use MTF much.
So next question is … Does quote above happen if you don’t use MTF??
05/28/2022 at 12:15 PM #194065I am always the only one with the issue
Not so … I experience all / nearly all the same bugs as you do. Hence I guess why it is nearly always you and me (only) who are on here moaning about oddities! 🙁
Due to lack of time, not allowing a bad mood to progress, wanting to get an Algo into Forward Test … I mostly find a work around and move on.
If I am in the right mood, and other (non-PRT Tasks) not competing for my time I do submit Suggestions to PRT. I stopped posting them on here … as you say, it achieves nothing, not even others (1 or 2 do yes) saying … Yeah I get that problem also!
I did continue (our aborted efforts from a while back) to have a central repository for (my) Suggestions submitted to PRT.
I have resigned myself to the reality of us 75K ish Auto-Traders using PRT are a low priority for PRT when compared to the > 900K users who use PRT for non-AutoTrading (manual trading, price display etc etc).
05/28/2022 at 12:25 PM #194066I think many errors tend to happen in small TF, maybe in the seconds range, and are therefore hardly noticeable in larger TF like M5 or M15? I think there aren’t many people using the very small TF, maybe because there isn’t enough history?
05/28/2022 at 12:29 PM #194067Here are some suggestions :
Users make up a combination of all 4 Reasons to various %.
I am #1 and #4.
05/28/2022 at 1:29 PM #194068I forgot one option (could not edit it in any more) :
5. People don’t use Multi TimeFrame or don’t use at least one Timeframe command (this wouldn’t be really MTF but will yield different results).
This latter is an obvious one, because the erroring out springs from that only.
Does this (also) happen if you use Timeframe (1mn, updateonclose)?
Yes, I tried that right away when I wrote about it. So there is really no escape.
Anyway, as we have seen, it is a similar problem to at first the Once commands were injected before the DefParam.In the end the solution could be to see this as a bug instead of something which can hardly be solved. Thus solution IMO :
- People need to learn to define the Variables they use for Backtesting and Optimizing in the same TimeFrame of the chart.
- People need to learn to start their code with a TimeFrame command which is in the same TF of the chart. This is probably not easy because in the code 60 seconds and 1 minute really can’t be mixed. See code snippet below this list (my comment).
- The PRT software needs to find the first TF command and inject the Once variables right after that (similar to how it is now done after the last DefParam command).
1timeframe(60 seconds,UpdateOnClose) // 24-04-2022,PS, Like this because it now nags about it being different than 1 minute.Let me make the remark that the Optimization Parameters / variables can always be declared in the TF of the chart, as long as they don’t readily assign something with periods for averages etc. That would be rejected then. And / but also, if *you* define the Optimization Parameters lateron under an other TF, there will just be no other solution than at putting live, inject them yourself at the appropriate (TF) place.
PS: I was told that for V12 a manual is being made. Well, looking forward to that !
05/28/2022 at 1:39 PM #194069So next question is … Does quote above happen if you don’t use MTF??
Superfluously perhaps : No no, I tested that this morning. Well, see my first post. Sort of thus;
When I put the Once variables myself under the first TF command, all is fine. When I put them myself above it (no need for PRT to do it wrongly) then I receive the TF error from the 2nd attachment in the OP.
So undoubtedly, if no TF commands are in there, it will be fine. That is why I should not have forgotten option #5.Also maybe superfluously :
Any TF command will change the TF explicitly, no matter it is the same as how it was. Thus, a chart with a TF of 1 minute, has another TF before the first TF command than after it. So if I use Once prior to that 1st TF command, while the real further assignments com after that first TF command, then the error is yours. This urges for a #6 :6. People don’t overwrite the value of an Optimization Parameter lateron.
Thus, *that* is actually the culprit here – that I give such a variable a value, after it was set before the first TF command by PRT. The shown Trailing Parameters are typically prone to that. They receive an initial value, and later (during a trade) they will be changed. And that then happens under another TF, no matter it is the same functionally (technically for PRT it will be a different one). Thus I now think I know how to solve that … similar to my “A” versions mentioned elsewhere. I will test that later and show the example if it works out.
1 user thanked author for this post.
05/30/2022 at 2:23 PM #194192Assumed someone could be interested in an automated solution to this, this is what I did :
A.
I added all the Optimization Parameters – variables I use in the program code – with a suffix B. See the Attachment.
N.b.: I used B, because I use A already for similar reasons/issues.B.
The top of my program code, but under the first TimeFrame command, now contains lines like these, for each of the Optimization Parameters as obtained in the list you see in the 1st attachment :123456789timeframe(60 seconds,UpdateOnClose) // This is my first TF command and it equals the TF of the chart.ONCE BandOffset = BandOffsetBONCE BreatheBarsSetL = BreatheBarsSetLBONCE BreatheBarsSetS = BreatheBarsSetSBONCE PriceOffset = PriceOffsetBONCE PriceOffsetTrailL = PriceOffsetTrailLBONCE PriceOffsetTrailS = PriceOffsetTrailSB[..]In the left hand column you see my original Parameters; in the program code it is those names which are used (and were used already).
C.
I now hand the code to “Prepare for Automatic Trading”, and that will make this of it (apart from making the sequence alphabetical) – Prepare for Automatic Trading injects it above my first TF command :12345678910ONCE BandOffsetB = 1.81ONCE BreatheBarsSetLB = 6.0ONCE BreatheBarsSetSB = 6.0[...]ONCE TrailAfterUnderLB = 11.0ONCE TrailAfterUnderSB = 12.0ONCE TrailStartAtGainLAB = 300.0ONCE TrailStartAtGainSAB = 290.0timeframe(60 seconds,UpdateOnClose) // This is my first TF command and it equals the TF of the chart.This is what happens in practice for the execution of the ocde, supposed we have one Optimization Parameter only :
123456defparam cumulateorders = falsedefparam preloadbars = 2000ONCE BandOffsetB = 1.81timeframe(60 seconds,UpdateOnClose) // This is my first TF command and it equals the TF of the chart.ONCE BandOffset = BandOffsetBThis code executes 100% the same as if you had the Optimization Parameters active in Backtest.
Thus you can blindly add all your Optimization Parameters to the top of your code (but under the first TimeFrame command which in itself must be right under DefParam commands, would you have those), and make them equal to the same variable names with suffix B.
05/30/2022 at 2:52 PM #19419805/30/2022 at 2:58 PM #194199Exactly. This is why this solution was presented.
(I hope this is clear ?)
So without this, re-assigning an Optimization Parameter a value in the code, would go wrong by the “Time Frame error” (as mentioned elsewhere in this topic).In the end it is about being able to blindly doing all correctly. This is what I have tested now for myself and it works. All it requires is creating the “B” parameters, obtain that list of assignments one time in the code, and use it forever.
And maintain the list of new or obsolete Parameters, of course.
If someone could ask PRT to disregard the Graph(OnPrice) commands in (Demo-)Live trading, then it would really be the press of a button. 😉
-
AuthorPosts
Find exclusive trading pro-tools on