(As mentioned before, my algo is mainly in Python (converted from Matlab..), so my questions are mainly focusing on Zorro/Python.
I tried the following simple code, in .c, set Python vars with OHLC(and V) from the last bar, and the last bar time wdate(0) and call Python code. This is on BarPeriod = 1 // 1-min bar
>>> function run() { pySet("pO", priceOpen(0)); pySet("pH", priceHigh(0)); pySet("pL", priceLow(0)); pySet("pC", priceClose(0)); // pySet("pV", marketVol(0)); pySet("pV", 0); // FX no volume! var wd = wdate(0); pySet("pTf", wd);
pyX("rcode = Py2(pO,pH, pL,pC,pV, pTf)"); >>> My question are: 1) Is the last closed bar timestamp best to use wdate(), or other better calls? 2) Some of the timestamps are not on minute edges, i.e., [276: Mon 19-03-25 09:58] (1.13190) wdate = 190325 09:58:02, OHLC = [1.1319 1.1319 1.1319 1.1319]
This means, the bar closed at 9:58 is timestamped as 9:58:02 (2 sec extra?) --> I assume it's because the next tick *AFTER* 9:58 closes the 9:58 1-min bar? If this is indeed the case I am concerned that, in after-market trading where trades might be sparse, say, between 9:57 and 9:58 there're ticks, but no ticks until 9:59:05, then the 9:58 1-min bar's 'closing time' is 9:59??
2) when the Python code gets big, it's extremely hard to debug with stand along Python (needs to write extra/complex Python drivers). Is there a way to 'attach Python debugger(s) to the Zorro Python process for Python code debugging?
Thanks.
Re: continue on interfacing with Python
[Re: nandv]
#476737 03/27/1907:1303/27/1907:13
Normally the timestamp should be exactly 09:58:00, but historical timestamps are just read from the broker's price server, mostly from FXCM, and are not checked or corrected. Python debuggers cannot be attached, so better debug Python functions externally before calling them from Zorro. Same for R.
Re: continue on interfacing with Python
[Re: jcl]
#476745 03/27/1923:5603/27/1923:56
I've tested loading 1000 1-min real time bars on IB and FXCM. IB is roughly 40% with either 1 or 2 secs after the minute edge, but max is 9sec! FXCM is all exactly on the minute! Enclosed are two csv file of Python dump of each bar's OHCLV and Timestamp(unix epoch/second) from IB and FXCM.
This may reflects the poor IB data quality, but still the bar end time shouldn't be the timestamp of the tick *after* the bar edge.
Last edited by nandv; 03/29/1900:55.
Re: continue on interfacing with Python
[Re: nandv]
#476751 03/29/1907:5403/29/1907:54
wdate(0) is not a timestamp. It is the current time.
I think a bar won't end on the precise second on a normal PC and internet connection, due to background tasks. In your case, the connection to IB is obviously slower than to FXCM. If a request to IB takes 2 seconds, then the bar end is inaccurate by 2 seconds. Other processes on your PC might add to that time.
Has nothing to do with timestamps or poor data quality.
Re: continue on interfacing with Python
[Re: jcl]
#476754 03/29/1909:4203/29/1909:42
Maybe we're talking past each other? A bar is a time period with a start and an end. A price quote is an event that happens at a certain time. Only price quotes have timestamps.
You can also assign a timestamp to a bar, but that is only a convention. With Zorro, it is the current time at the end of the bar. Other software might use the bar start time or middle time.
Re: continue on interfacing with Python
[Re: nandv]
#477211 05/31/1915:3805/31/1915:38
IB is roughly 40% with either 1 or 2 secs after the minute edge, but max is 9sec!
I'm working from an old memory so this may be totally wrong, but... doesn't the IB interface "batch" ticks and send them out in bursts? If so, then maybe the bursts are normally coming every 2-3 seconds?