Live errors out due to Optimzation Parameters

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

Author

Posts
05/28/2022 at 10:43 AM #194052 quote
PeterSt
Participant

Master
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 :
```
defparam cumulateorders = false
defparam preloadbars = 2000

ONCE BandOffset = 1.81
ONCE BreatheBarsSetL = 3.0
[...]
ONCE TrailAfterUnderL = 11.0
ONCE TrailAfterUnderS = 10.0

TimeFrame(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 :
```
defparam cumulateorders = false
defparam preloadbars = 2000

timeframe(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 :
1. People encounter the same but don’t bother to proceed on it. They find another functional solution. Or they go to MT4, whatever.
2. People don’t use Optimization Parameters at all.
3. People did not know about the possibility of the “Input” parameters (likely, because there’s no manual where this is written in).
4. 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.

image_2022-05-28_111220826.png image_2022-05-28_112420757.png
05/28/2022 at 11:59 AM #194063 quote

GraHal
Participant

Master

PeterSt wrote:

not 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 #194065 quote

GraHal
Participant

Master

PeterSt wrote:

I 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.

PRT
Improvements
Log

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 #194066 quote

phoentzs
Participant

Master

I 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 #194067 quote

GraHal
Participant

Master

PeterSt wrote:

Here 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 #194068 quote
PeterSt
Participant

Master
I 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.

GraHal wrote:

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).
```
timeframe(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 #194069 quote

PeterSt
Participant

Master

GraHal wrote:

So 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.

GraHal thanked this post

05/30/2022 at 2:23 PM #194192 quote
PeterSt
Participant

Master
Assumed 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 :
```
timeframe(60 seconds,UpdateOnClose)   // This is my first TF command and it equals the TF of the chart.

ONCE BandOffset         = BandOffsetB        
ONCE BreatheBarsSetL    = BreatheBarsSetLB   
ONCE BreatheBarsSetS    = BreatheBarsSetSB   
ONCE PriceOffset        = PriceOffsetB       
ONCE PriceOffsetTrailL  = PriceOffsetTrailLB 
ONCE 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 :
```
ONCE BandOffsetB = 1.81
ONCE BreatheBarsSetLB = 6.0
ONCE BreatheBarsSetSB = 6.0
[...]
ONCE TrailAfterUnderLB = 11.0
ONCE TrailAfterUnderSB = 12.0
ONCE TrailStartAtGainLAB = 300.0
ONCE TrailStartAtGainSAB = 290.0

timeframe(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 :
```
defparam cumulateorders = false
defparam preloadbars = 2000

ONCE BandOffsetB = 1.81
timeframe(60 seconds,UpdateOnClose)   // This is my first TF command and it equals the TF of the chart.
ONCE BandOffset         = BandOffsetB
```
This 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.

image_2022-05-30_145421227.png
05/30/2022 at 2:52 PM #194198 quote

Nicolas
Keymaster

Master

I’m not sure it will help, but: it is not allowed to “declare” (giving the same variable a value) in different TIMEFRAME in the same code.

05/30/2022 at 2:58 PM #194199 quote

PeterSt
Participant

Master

Exactly. 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. 😉
Author

Posts