Severe : Optimization Variables are stored with wrong values
-
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.
GraHal thanked this postI 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.
- You must be logged in to reply to this topic.
Summary
This topic contains 10 replies,
has 2 voices, and was last updated by 
2 years, 2 months ago.
Topic Details
| Forum: | Platform Support: Charts, Data & Broker Setup |
| Language: | English |
| Started: | 08/27/2023 |
| Status: | Active |
| Attachments: | 7 files |
