runDonor returns different results every time it is called?
Author: aykuts
Creation Date: 3/18/2014 9:13 AM
profile picture

aykuts

#1
Hi,

I have a simple strategy that takes 3 parameters; say p1 p2 and p3.

I wrote a code piece that basically loops over parameter 1, modifies the xml file appropriately, and then, let RunDonor to run it and yield some performance results. The code follows basically as follows (unnecessary parts are excluded):


CODE:
Please log in to see this code.


**
This loop gave me the NetProfit values for every p1_value alternative, programmatically, perfect! (Huge saving of time and big jump in the reliability of performance test, great!)

Then, I realized that the numbers that this loop yielded varied every time it is called.

So, i devised a very simple test to see whether I am or the runDonor is wrong.

The test procedure has been as follows:

First of all, i kept every variable constant. .i.e.:
1- I left the date range unchanged for each of the runs;
2- i kept the ticker unchained at each run;
3- I did not change the scale, nor position sizing setup as well,
4- i did not change the code of the donor strategy as well (only the p1_value changed programmatically with the help of this loop)

So, given this setup, I run this very same loop (for 5 alternative p1 figures), for 7 times.

That way, I retrieved 7 Net Profit figures for 5 alternative p1_values.

**

If everything was fine, each of the 7 Net profit figures, (for, say, the first value of p1) should be exactly the same.

In other words, this loop should return the same results for a given p1 value whenever it is called.

**

The outcome is really horrifying; of this 7 calls of the same loop for 5 different p1 values, the Net Profit results (that runDonor(DonorStrategy) returned) were completely different!!, not even close!!

To give a hint, the following is the list of ` 7 Net Profit results of a donor strategy, for the first value of the parameter p1. Theoretically, these 7 values should be exactly the same given that the parameter, data range, code, scale...everything kept unchained at each of these 7 runs):

List of p1 results for repetitive runs of the same code:
p1 = 1, NET PROFIT = '1482526.16000003'
p1 = 1, NET PROFIT = '1497802.42000003'
p1 = 1, NET PROFIT = '2679251.32000005'
p1 = 1, NET PROFIT = '2491140.16000005'
p1 = 1, NET PROFIT = '2465272.34000004'
p1 = 1, NET PROFIT = '2059570.21000003'
p1 = 1, NET PROFIT = '2364506.35000004'

In theory, these values should be the same!! Calling one method and getting different results every time is very scary and reduces to a great extent the reliability of the rundonor approach and programmatic calls of the strategies.

(And I hope it is me doing something wrong)


**

Here is my question:

- Is there any way (or need) to flush the previous calculations and global variables from this PerformanceResults - before it is recalled by the code?

- Or, what might be happening in the code and the very same code returns different values each time it is run?

Additional notes:
- i checked the state of the xml file, and it seems that it is updated appropriately before the runDonor method; So, that narrows the problematic area down to the runDonor method, i think.

- I checked another Result.property (Position.Count) and again, the code returns different results every time it is executed.

- I also checked the `correct` values (through manual run of the same strategy from Open>Strategy). None of the values I presented above were even close to the value I got through manual run.

- I switched off the commissions for backtesting to keep things simpler.


** Thanks,

Please help; being able to run alternative setups of the strategies programmatically is a huge efficiency and accuracy jump for me and I am this close to achieve that.

Best regards,

Aykut Saribiyik


profile picture

Eugene

#2
Already explained it to you yesterday. See my reply #50 here (first paragraph):

Accessing SystemResults

profile picture

aykuts

#3
Eugene,

With all due respect, I am not satisfied with your answer regarding this problem.

Let me tell you briefly the procedure I followed to test the results of runDonor method.

Meanwhile, please have a look at the documents I attached to this post (when I mention them throughout this post).

That way, I am sure, the problem will be clearer so will be the remedy.


1. The donor strategy is adbBandOnly.xml
- Please have a look at adbBandOnly.xml attached to this post.
- As you will notice, the position sizing mode is the simplest 1mn Dollar (RP) mode.
- Position priority is properly assigned
- and this strategy will not be modified for the rest of the test


2. I wrote another strategy that basically calls adbBandOnly as the donor strategy:
- Please have a look at TESTING_RUNDONOR.xml attached to this post.


3. Now, here is my path of test, and my observations:

A.
- I launch wealthlab > open the strategy > open adbBandOnly.
- Set the position size as 1mn Dollar (RP) > set up parameters > click to one ticker> and a result returns.
- Please see the jpg called GARAN60Result.
- Lets note down the Net Profit as 1,492,147.74 => This is the CORRECT value. Lets keep it in our mind.
- And, one important note; for the rest of the test, I will not change the ticker, the date range, and the row profit / fixed dollars mode; all of these will be constants.


B.
- I close this strategy > open another strategy > TESTING_RUNDONOR
- Keep the position size, keep the date range, keep the ticker, keep the scale
- I run this strategy (that basically performs the task of calling adbBandOnly through RunDonor(adbBandOnly) )
- the result is displayed on the Debug Log. Net profit is 110,280!


Finding 1:
the result is 110,280 and this is not equal to what the original strategy returns (1,492,147). Something is wrong here!

Finding 2: the commission is not applied to simulated trades (from file > preferences> commissions). So, the difference cannot be explained with the commissions (in contrast to what you have previously suggested)

finding 3: the position priority is setup properly within the strategy. So, the difference cannot be explained with the position priority (in contrast to what you have previously suggested)

finding 4: the position size is rp-fixed dollars, so there might not be any missed trades due to insufficient capital. So, the difference cannot be explained with insufficient capital as well. (In contrast to what you have previously suggested)

C.
I also made some other observations - which i believe will help us find the issue here:

- While TESTING_RUNDONOR is open, I changed the Position Size (on the top-left section) from 1mn to 10mn
=> Result did not change! (Net profit = 110,280)

- While TESTING_RUNDONOR is open, I changed the ticker (from GARAN60 to something else)
=> Result did not change! (Net profit = 110,280)

- From within the TESTING_RUNDONOR, i modified the parameters from X,X,X,X to Y,Y,Y,Y > run the test
=> Result changed!! (Still not the correct number, but at least i observed that whenever the xml file is modified, the result changes)

- While TESTING_RUNDONOR is open, I changed the Position Size (on the top-left section) from RP FIXED DOLLAR TO RP FIXED SHARES
=> The result changed (still wrong)

FINDING 5: (and these are even more interesting findings)
- While TESTING_RUNDONOR is open, i changed the position size (on the top-left section) from rp fixed dollar to portfolio simulation mode with fixed dollars 1mn > clicked run strategy button!
=> The result changed (understandable)

I did not change anything, did not touch to anywhere of the platform, just clicked again the run-strategy button
=> the result changed!!! (Why why why, this is something i dont get)

I did not change anything, did not touch to anywhere of the platform, just clicked again the run-strategy button
=> the result changed!!! (Why why why, this is something i dont get; this structure should be deterministic in nature, should find the same results given the same strategy code, same setup, same market data!!)



MY QUESTION:
Eugene, i think the RunDonor code that i apply here returns a different number than either I calculate, or I recall. So, I think I cannot set properly the Global Objects while RunDonor, or, I cannot recall the write statistic after RunDonor is called.

My kind request is; please do the very same test on your side given
1) TESTING_DONOR.xml I provided,
2) BANDSTRATEGY.xml I provided
3) And follow a similar path of testing I described herein this post (with any set of 60-min data and the ticker).
4) I am sure you will observe the similar findings.

That way, you might come up with a different suggestion than what you have already detailed in `Accessing SystemResults` thread.

My final word:
- I think I cannot setup properly SetGlobal/RemoveGlobal during this test;
- it is not related to trade size, or trade priority, or the ticker etc; I simply cant create properly the PerformanceResult object.
- Please suggest me something so that the runDonor result (currently 110,280) approaches sufficiently to the correct result (which is 1,492,147)

**

I gave my 1 and half hours to wrap up this post, so I hope you make it worth it.

Thanks in advance for your help;
profile picture

aykuts

#4
I forgot to attach to the previous post the dataset I use.

Please use this DataSet to replicate the test; that way, all of the numbers would compare well to my findings.

Thanks,

profile picture

Eugene

#5
Thanks goodness for Notepad++ with TextFX plugin. And again I've edited your reply, bringing it to "Sentence case" where possible. Otherwise I have a permanent impression that your ALL CAPS text with exclamation marks is shouting at me.

The Position.Priority is NOT being assigned correctly:

CODE:
Please log in to see this code.


This way, randomization happens whenever Open[bar+1] gets above the BuyPrice, distorting the results. Commenting that line out gives me a stable result at all times:

CODE:
Please log in to see this code.


The resulting strategy (with shouting exclamation marks removed ;) ) to be executed on-the-fly on the first symbol of the DataSet is included. For me, it produces identic results in either RP or PS mode:

CODE:
Please log in to see this code.


Although it took me a considerable effort to fix the solution, the end result produced by this workaround may still be inaccurate (i.e. different from the Wealth-Lab's own simulation result) for some reason I couldn't see in my development of it. This has been especially true with systems utilizing AtStop and AtLimit orders. I recommend AtMarket orders. It's only an approximation.

If you still can't get desirable results for your Strategy, you might want to try out a totally different approach: using SetShareSize in your strategy, keep track of portfolio equity in a DataSetSymbols loop like Cone's examples in posts #12 and #15 illustrate:

Limit Monthly Drawdown / Portfolio Equity Tracker

UPDATE: slight code edit (corrected Priority assignment)
profile picture

aykuts

#6
Thanks, once again, for your time and suggestions.

I will try the solution you proposed first thing in the morning and let you know.

(And, Eugene, It should be obvious that I never meant to shout while using these upper cases - I am not that kind of client/person. On the contrary, the words with upper case letters were those that appeared to me at first sight that I discovered something important! :-), a bug or something, one big invention about wealth-lab :-)

(and looking at your answer, they are simply not but a newbie's strugglings. Anyway, maybe I will discover something next time :-)

(And, I hope I am not leaving an expression on your side guys this guy should have left :-)
http://www.wealth-lab.com/Forum/Posts/utility-RunDonor-32623

Best regards,

Aykut
profile picture

Eugene

#7
Re: shouting text. I should've inserted a smilie. I do appreciate your posts full of thorough, detailed analysis. I wish we had bug reports and other inquiries of this quality from every customer. ;) But for my eyes, an ALL CAPS text is simply harder to perceive.


On second thought, assigning the fixed 1.0 value to Position.Priority in your code basically invalidates the concept. The idea is that higher numeric values are taking precedence whereas you made them identical. You might want to try assigning a meaningful value e.g.

CODE:
Please log in to see this code.


(Applied the edit to the code above.)

QUOTE:
finding 4: the position size is rp-fixed dollars, so there might not be any missed trades due to insufficient capital.

FYI: Yes they still can, if the trade size is not enough to take just 1 share of the instrument in Raw Profit mode.

UPDATE

Actually, I've just re-ran the Strategy code above (edited) again on various spans of Dow 30 (Yahoo! EOD data) and found that it's producing identical results. For example, on 500 bars: $99.37K vs. $99374, on 10 years: $33.84K vs. $33.842.
profile picture

aykuts

#8
Eugene,

I copied the code, done additional modifications (such as the one you just mentioned at your follow-up post #7), also added some additional code regions to capture certain inputs from one MySql table...

and things are just fine now;
1- the result the code returns simply matches with the correct value;
2- and, the `re-run` of the same code, for the same set of data, with the same set of global and strategy-level parameters, yield identical results.

Maybe, what I can suggest for future reference would be; Before using RunDonor, a wise move would be to generate a new DataSet:
=>I created a brand-new DataSet for one ticker only (over which I would call the code)
=> I run the strategy (you provided at post #5) at that new DataSet (which included only one ticker)
=> If there exists anomalies between what the code returned and what the user expected, then the user should consider to suspect from RunDonor and the flow of the code.

The reason I am saying is that:
=> I copied/pasted the code at post#5, ran this code at my new DataSet, and the results appeared ok.
=> Then, I took my old code, and ran this code again at my new DataSet, the results again appeared ok.
=> So, proper design of DataSet (before calling RunDonor) plays crucial role in the reliability and correctness of the results.

Sorry, I kept too long.

Thanks once again,

Aykut Saribiyik,


profile picture

Eugene

#9
Aykut,

Glad to have helped.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).