The RBM gives me constant warnings about training the RBM w/ S4 values. Only visible, if run from R-Studio. Any attempt to solve this, was unsuccessful.
I continued w/ SAE.
Running the SAE through the EA-Tester gives every time a different result, although the input data is always the same, and nothing was changed in R-code or EA-code. The differences are huge. From almost total loss to profit. The problem I found is, that for each new run, randomUniForest comes to a different conclusion (random) and subsequently the network decides differently.
When you launch the EA, there is no way to know in advance, if randomUniformForest has done a good job, or not. Only later, when you run into losses, you know, probably not.
There is also no way to optimize parameters, when you shoot at moving targets.
The take away from 1 weekend of testing is that the thing produces random bullshit!
I performed 3 identical test-runs; no change in code, no change in parameters, no change in historical data. MT4 was started every time new to avoid potential effects from previous runs. The results are terrible! Please refer to the attached files.
Vladimir, I think you would really do a great favor to everybody, if you put this thing on the tester to understand the issues, most of the people have here. If we cannot run this thing on the tester, it will never get out of the mud!
funny thing that the nimber of k lines cannot exceed 100 when I test it in EA, It always crash when variable i goes up to 100
for(i = 0; i < lim; i++)
o[i] = Open[i+1];
hi[i] = High[i+1];
lo[i] = Low[i+1];
below is the log, is there sth that I missed?
1 21:25:36.646 TestGenerator: unmatched data error (volume limit 2630 at 2017.10.04 15:00 exceeded)
2 21:25:36.709 1970.01.01 00:00:00 e_DNSAE inputs: Lots=0.1; TakeProfit=50; StopLoss=45; magic=654321; cor=3; n=34; z=37; soft=1; Kmin=10; limit=1000;
0 21:25:37.398 2017.05.17 10:00:00 e_DNSAE AUDCHF,H1: 1
0 21:25:37.409 2017.05.17 10:00:00 e_DNSAE AUDCHF,H1: lim:1000i:0
0 21:25:37.409 2017.05.17 10:00:00 e_DNSAE AUDCHF,H1: lim:1000i:1
0 21:25:37.409 2017.05.17 10:00:00 e_DNSAE AUDCHF,H1: lim:1000i:100
1 21:25:37.409 2017.05.17 10:00:00 e_DNSAE AUDCHF,H1: array out of range in 'e_DNSAE.mq4' (143,22)
3 21:25:37.409 2017.05.17 10:00:00 Testing pass stopped due to a critical error in the EA
0 21:25:37.409 AUDCHF,H1: 1 tick events (2466 bars, 8359005 bar states) processed in 0:00:00.703 (total time 0:00:45.469)
its the usual confusion about starting to count from 0
your array is of dim [lim], hence i runs form 0 to lim-1 (i<lim); if you refer to i+1 you are out of boundary by 1.
if lim = 100, the i runs from 0 to 99 = 100 steps. i+1 is 101.
check if you have enough Bars in the chart. you need 101
OK, I think I found a real problem.
Whenever I run the NN training on the same set of randomUniformForest output, I receive constant output from the NN.
Everytime I rerun randomUniformForest ON THE SAME price data and indicators, I receive a different output from ruf! depending on ruf, the balance of the NN is totally different. I attach my files from yesterday, since I dont see them im my previous post and I attach a file w/ 2 ruf-runs. You can see the difference. The right col makes profit, the left col is terrible.
Everytime I rerun randomUniformForest ON THE SAME price data and indicators, I receive a different output from ruf! depending on ruf, the balance of the NN is totally different. I attach my files from yesterday, since I dont see them im my previous post and I attach a file w/ 2 ruf-runs. You can see the difference. The right col makes profit , the left col is terrible.
There is nothing strange in this. It's RANDOM. Random models always behave like this. Try setting the set.seed (12345) in the squeak before the model build line.
RandomUniformForest is used only to determine important predictors. You can completely eliminate this step from the script. Or use other algorithms to select important predictors.
Thank you for your series of publication. I really appreciate all the details that you shared.
I managed to run the SAE version in MT4 tester, by pre-loading the "limit" 5000 bars, and adding a sync option if in tester.
Another thing I discover is that ifelse(dbr > 0, 1, -1) is not equal to sign(dbr) . sign() might return a "0" besides "1" and "-1". It will crash the markovchain if 3 states, instead of the initial 2 states setup, is passed into predict().
else RExecuteAsync(hR, RUN);
> sig.cor <- sign(dbr)
> sig.cor <- ifelse(dbr > 0, 1, -1)
Спасибо за вашу публикацию. Я очень ценю все детали, которыми вы делились.
Мне удалось запустить версию SAE в тесте MT4, предварительно загрузив «предел» 5000 баров и добавив опцию синхронизации, если в тесте.
Еще одна вещь, которую я обнаружил, это то, что ifelse (dbr> 0, 1, -1) не равно знаку (dbr) . знак () может возвращать «0», кроме «1» и «-1». Это приведет к краху марковчаина, если 3 состояния, а не начальная настройка состояний 2, передается в pred ().
Thanks for the response. It's interesting with the tester.
I will check the last remark about the signal. I did not experience such a mistake in the experiments.
Good luck and see my latest articles on deep networks. It will be interesting.
I'm thinking of starting a new branch of RuserGroup, regardless of the language of the participants. Would this be an intersex?
I will continue to read the series of article.
Please PM me if you have the said group. its good to experiment together.
could you please elaborate a little, how you synch'd the tester and R-Term??
I also had the idea to use the synchronous execution, but that doesn't help me.
What happens is that the tester continues to pump 1 min candles as "ticks", which are ignored in the expert "on Tick", because the thread is still in R-Term. Hence all 1 min candles are blown into nowhere and when the NN comes back into the expert, having learned, everything is already over. The only way to overcome this I currently have is starting the tester in visual mode and setting the speed slider to minimum. Then when the NN has finished learning, I move the slider to fast. However I am not sure, how many candles are skipped, nevertheless.
2nd, If I put more than 1000 candles into limit, the tester! (not R-term) crashs; how comes that you can put 5000?
MT4 and SAE
would be interested in an R-group for NN as well!
Please PM, when established!
usage of rminer::holdout parameter.
You use mode="stratified" or "random" in your code/explanations. In these cases, the input values (remind you candles) are randomly chosen.
sampling mode. Options are:
stratified – stratified randomized holdout if y is a factor; else it behaves as standard randomized holdout;
random – standard randomized holdout;
order – static mode, where the first examples are used for training and the later ones for testing (useful for time series data);
 1 7 2 4 10 8 6 9
 3 5
However, candles are time series (sequential). Isn't therefore the choice of random disrupting the price flow and confusing the NN??!!
Shouldn't "order" be used!!
 1 2 3 4 5 6 7 8
 9 10