Here is one of the most severe bugs – it already is that because I warned for it myself (two+ years ago);
1
2
3
IfClose+TrailAfterUnderS<TrailUnderValuethen
TrailUnderValue=Close+TrailAfterUnderS
endif
Bug #395 is about the variable TrailAfterUnderS not being declared (hence was not assigned a value);
I copied over some featured code from another strategy and forget to copy this line to somewhere at the top of the program code :
1
OnceTrailUnderValue=Close// 15-05-2022,PS.
Now, looking at the first snippet, and knowing that this is about a Short, some guru at ProRealTime decided that it is convenient to not have declared your variables and treat them with a value of 0. A real treat that is. But Close + whatever is in TrailAfterUnderS (43 in my case) obviously never will be smaller than 0. Yes I lost money on this one.
I just analysed this situation and a 1000 backtests would not have shown this because of various coincidental happenings. One of these is that when a Long would be the first trade in the sequence (for the time this strategy runs), the If in the first code snippet is the other way around
1
2
3
IfClose-TrailAfterUnderL>TrailUnderValuethen
TrailUnderValue=Close-TrailAfterUnderL
endif
and if there TrailAfterUnderValue would be 0, all is fine because next it will be assigned a real workable value. After this all stays fine, except that it also requires a reset to close of the variable after each trade (which line I forgot to copy just the same). In this case the trades won’t run efficient, but it won’t be a lose running train (like happened over the course of Monday to Tuesday).
It is forbidden to just use 0 for the value when a variable was not declared or assigned a value. ProRealCode is the only “language” I know of where this happens. N.b.: This was introduced in V11 and when I presented it as a bug a “no no no, this is convenient ! (when it is used as a switch)” was the response. The one who told this should pay me back the lost money. And might he dare say it is my own fault then I will sue him on top of it.
That’s what I’m calling programming. Indeed there is no variable declaration, thus all variables have 0 as a default value. If you know that as a coder, you know how to handle it in your own code.
I’m moving this topic from prorealtime support to ProOrder support as it is not related to platform technical issue.
Nicolas, please, this was made so by ProRealTime because otherwise nobody is able to run his/her code but which was actually caused by other reasons in 10.3 (and before). This is a statement from ProRealTime and I am not making it up. So yes that was a pain. But that does not mean that the behaviour should be as it is not (V11) which – and I repeat – is not done by any language or else I am happy to learn which. And mind you, this is not about languages (mainly interpreters) which don’t require declaration. This is about assignment.
What this comes down to is that when I make a typo in a variable name, my strategy fails and I won’t know why. Unless the quite many examples (I gave only one) where PRT decides to give an error message after all. Btw, which you (smartly ?) call a Warning.
I must assume that you never make typos.
We can continue this discussion if you find it interesting, which probably only can happen if you don’t call me a lousy programmer.
Btw, I obviously talked to PRT about this with reference to this topic and they readily agree with me (strange eh ?). A possible solution could be a popup telling which variables have not been used. Yes, similar to 10.3. That does not work either.
Just an error message when a variable is used without assignment, and no stupid arguments that otherwise people can’t run their code. This is more ridiculous than what I encountered anywhere, were it about using software of whatever kind. So those people *are* allowed to lose money ? (I know, you did not say this – PRT does).
I am not allowed to lose money because I so-called know what I am doing (or whatever it is you are trying to tell me), but those more poor-people who know less *are* allowed to lose money ? Really …
.
