CSV to FXT but no HST.

New comment
 
Hi!

I could get tick data from somewhere in csv format. I converted into 'yyyy.mm.dd hh:mm:ss; #.####' format so the script called 'simple_csv2fxt' could convert it to fxt format without any problems. I cannot get it to produce the hst file for the tick data, though.

Now, if I copy the fxt file to tester/history, and run the tester, what does the tester do with the situation of not having a hst file (bar bata), just fxt (tick data)?
To ask a direct one: where does EMA gets calculated from during testing? The testers .fxm, or the platform history's hst?

Is it going to work correctly whithout the matching hst (I just need data, not the graph), or do I need the hst file as well?
If I do need it, how can I make one?
(If Slawa reads and replies, why do the imported generated .hst returns 0s, and some 1700000s for price? The .fxm is okay, I tested it...)

A solution would solve all of my backtest problems I guess...
Thank you in advance for replying!

Zap
 
About hst from ticks see Period_Converter_Opt custom indicator. But if You've converted hst from your ticks, then You cannot reconvert the same ticks back from hst.

If "Recalculate" button does not checked, tester use existing fxt file

During testing, the tester hst is collected from the fxt file. This is why EMA gets calculated from the testet hst not platform hst

Article about testing coming soon
 
Zap :
Hi!

I could get tick data from somewhere in csv format. I converted into 'yyyy.mm.dd hh:mm:ss; #.####' format so the script called 'simple_csv2fxt' could convert it to fxt format without any problems. I cannot get it to produce the hst file for the tick data, though.
.....
Zap

A little late, sorry, but your problem comes from the fact that 'simple_csv2fxt' write a wrong HST header (6 bytes shorter than a right one, so all the offsets are wrong). Its easy to fix it, just take a look at Period_Converter.

New comment