Severe : Optimization Variables are stored with wrong values
08/27/2023 at 6:48 PM #219877
I have been reluctant to post this, but since I don’t think I am going to work with PRT to solve this (this is all to no avail (really !) or will take ages to solve anyway), I hought the best I could do is warn people so others are going to work on solving this. If only PRT themselves (of which we are told they monitor this board) would read this and pro-actively go out and work on this …
I started to see anomaly 3 or 4 weeks ago, when I started to be unable to compile a System into a system for ProOrder. The message : Syntax Error on line 1.
Since you’re completely stuck with this because where to look (BackTesting works just fine) there’s nothing else to do than call PRT support, which of course have never heard of the problem (unless it won’t backtest as well because of a real syntax error somewhere) and it just stopped for me. Until yesterday when I found some time to dive into this.
I got the hunch to remove all the code from the editor and see what happens, because … indeed, the error message stayed.
This clearly told me that the error was in the Optimization Variables. This with the notice that it happened quite some times before that they caused havoc. In other occasions it was a matter of starting over from scratch, but in this case it is caused by copying the system via formal PRT procedure. Thus, System A is fine, and the from that copied system B fails.
I started deleting variables from the bottom onwards (with 30-35 or so in there) and at having deleted half of them, the error disappeared. This lead to variable StopPointsB causing it all.
I copied again from A to B, deleted StopPointsB and added it at the bottom and all was fine. Well, sort of, because copying from B to C again caused the issue right away again and it was on the same StopPointsB variable. “All right”, I thought, “then I am going to delete and add that variable each time I continue copying that system”.
Then at testing the lot I already saw completely different backtesting results, depending in which stage I did what.
Because the system could now be given to ProOrder, I could look in the generated code to see what it actually does with it. This with the notice that I wanted to do this for weeks already in order to solve the Syntax Error, but a system with a syntax error won’t arrive in the ProOrder system, so nothing much to see. But now I could do this !
Shock awe etc.
The 1st screenshot shows that by me it is given the value 0.0009 as a fixed value, but in the right hand you see the generated code and there it received the value of 1.0.
What the relation is between this very variable causing errors at copying of the code and it receiving a wrong value once re-added and given to ProOrder, I don’t know.
The way how I found out is frightening too because something more coincidental I can’t think of.
Because this variable relates to Trailing in my System and I already could not understand many of the Trails which did not work out as intended, I am now 100% pretty sure that my Systems don’t do what they want because PRT messes up with my code. Today I can just copy the behavior (in Backtesting) !
I have been telling PRT support a dozen+ times the past couple of months, that they feel no responsibility for a financial application which is about a lot of money for the user. It is getting worse and worse, and now this. This is an issue we cannot see. It should work flawlessly.
And indeed … In the second screenshot you see that ProOrder uses 0.00109, which looks to be derived from the from/to data (see at the right). There too it should have been 0.0009, but it is not so. In a system which is Live !! In this case started at August 17. God knows how long this is going on.
Interestingly, screenshot #4 shows a version of July 24, 2023, and there it was 0.00109 indeed. Did the handing to ProOrder use old data ? …
Regarding the latter : another bug exists which does not allow to make changes in the Optimization Variable data and receive their values right away in the ProOrder screen; that requires new loading into the Editor first. Another bug which doesn’t get solved (actually as severe if you don’t know about it), but I know about that so my workflow adapts to it.
1 user thanked author for this post.08/27/2023 at 7:26 PM #21988308/28/2023 at 6:10 AM #219894
I have 43 variables for that System. The variable I am focusing on (StopPointsB) is/was at position 30.
Right from the moment I added the last variable – or actually when I for the first time could not compile to ProOrder, I had the hunch it was about too many Optimization Variables.
So … what do you have in mind ?!? 🙂
N.b.: At making a last screenshot for this topic, I noticed that the System which was fine regarding the Syntax Error om line 1, – see screenshot with the proof of it – again did not want to compile. Thus, the fix (ahem) of deleting the variable and adding it again, lasts until PRT is closed and restarted ? Btw, the one of this screenshot is the one of the first screenshot in the first post, containing 1.0 instead of 0.0009.
To picture it for people, this variable is about pips. So 0.0009 (or 0.00109) is really something different than 1.0. I tried that 1.0 in backtest and it really would break someone’s bank.
Please notice something many will know already : such a variable, ever being somewhere in the middle of the list – now at the end – will remain in the same position in the Backtest Results. See the 2nd screenshot for that. I am sorry to say that for me this is the proof that PRT’s developing methods s*ck all over.
It proves that something with old data is being done, be that on purpose or be that a bug in itself.
Below in the 3rd screenshot yet another example of such a thing; This fraction is not mine. It appears in various forms and seems to be about back and forth “math” with division and back-multiplying. Without infinite precision, you get things like this. I have them ending at .000002, .000001, .000004, .000003 (I did not count the zeroes) and it is as dangerous, if you only see yourself comparing with if RangeEnterLB = 1.7, the value I put in there. This If will give False for result in this case because RangeEnterLB was turned into something else behind my back. It is one of the 2000+ tickets I filed, this one 3-4 years ago.08/28/2023 at 9:26 AM #219921
So … what do you have in mind ?!? 🙂
Use 2 Systems, duplicates codewise, but …
- System 1 has variables 1 to 20 in the optimiser and variables 21 to 40 etc values in the code.
2 . System 2 has variables 21 to 40 etc in the optimiser and variables 1 to 20 values in the code.
A frustrating pain I know, but it may prove something and / or enable you to continue to function until a proper fix is implemented by PRT.08/28/2023 at 9:28 AM #21992208/28/2023 at 9:41 AM #219929
No, just a hunch as seems logical there would be a limit beyond which results / outcomes are untested (by PRT) and may therefore become unpredictable?
I generally do not use Systems with more than 8 to 10 variables as not suited to my quick-fire optimising methods.08/28/2023 at 9:51 AM #219931
A frustrating pain I know,
A way round copying individual values from one System to another would be to send System 2 to Proorder and then copy the values (which are automatically entered at the top of the code) from System 2 into System 1 to appear at the top of System 1.
System 1 would need to be initially populated with variables names & values (from System 2) at the top in order to be able to operate the above process.
Hope above makes sense, I’m sure you will say if it doesn’t! 😉
1 user thanked author for this post.08/28/2023 at 1:46 PM #219942
Apart from that people better stop using PRT instead of us finding backdoor solutions …
I think I see what you are heading. But it won’t solve the issue of loading-back the variables into the Optimizer (so to speak). Until a year ago or so I was used to always make the variables definitive by re-activating them in the code and removing them from the Optimizer, but since then I got used to leaving them be in the Optimizer, which already starts with using them as “start up parameters” – something I almost found out myself (you may recall my post about this – though that was more than 2 years ago). I even had to “teach” Support about this. So today I am really using (utilising) this feature and I can’t do without any more. This is all related to Money Management and starting-through (after PRT threw out a system per Broker failure or whatever).
I don’t think this is related to the number of Variables. As said, quite some times before things went bad in there. The way it has been set up stinks.08/28/2023 at 2:00 PM #219946
But it won’t solve the issue of loading-back the variables into the Optimizer
Why would you need to do above?
When you have an optimised System 1 you would be setting it going on ProOrder?
You can save System 1 and System 2 (as per my example) on your PC or leave in Code Editor so you have these 2 versions ready for next time you need to optimise?11/22/2023 at 4:28 PM #224153
Some of the bugs are that obscure it leaves me thinking … did that just happen?? Most of them are to do with backtesting. Take 1 for example … lots of times, when I have entered a fixed value for variables (in the boxes in the optimiser) and then I press backtest (as I want the fixed values to be set for good) the optimiser decides to optimise again … even though I now have entered fixed values!! Re … the set for good comment … lots of users may not realise that if one does not do the – set for good – then the values going forward to ProOrder could well be the values from the penultimate backtest!
So that. And yes that goes through to ProOrder. This is how I found out in the first place. And in Live btw.
But nobody cares much, or just does not see-though the possible impact ?11/22/2023 at 4:37 PM #224156