This version will become the official release when no bugs are found in the next time. It contains a generator for artificially shaped price curves, an improved debugger, new indicators, a new capital distribution algorithm, a workaround for the upcoming German trader tax, and many more new features. The full list can be found on http://manual.zorro-project.com/new.htm.
Please test everything and report any issues here! If you're the first one to find a serious bug of this release candidate, you can get a free Zorro S subscription. Details on https://manual.zorro-project.com/restrictions.htm.
Re: New Zorro version 2.25
[Re: jcl]
#479280 03/14/2011:0403/14/2011:04
- The Holidays list had a undocumented limit of 20 holidays. Not a 2.25 bug, but already present in 2.20 - The TradeTest script had leftovers from a previous test, please don't use it.
A new version with no holiday limit and the right TradeTest script was uploaded.
Re: New Zorro version 2.25
[Re: jcl]
#479290 03/16/2001:4803/16/2001:48
There is yet again a 1-min shift in the bars Zorro builds. This nasty 'rounding' bug resurfaces from time to time, and it would be great to get it fixed once and for all.
There must be a way. All other trading sw I've worked with doesn't have such a problem.
This is not a 2.25 bug, it existed also in (at least) b2.23.5
Re: New Zorro version 2.25
[Re: jcl]
#479291 03/16/2008:2203/16/2008:22
I don't know of a 1-min shift, but your screenshot is not from Zorro. For comparing .t6 timestamps with the log, please use the historical data from the download page and the History script that comes with Zorro. If you see a discrepancy, please post here with which file and at which timestamp. We'll look into that.
Re: New Zorro version 2.25
[Re: jcl]
#479294 03/16/2012:4003/16/2012:40
My screenshot IS all from Zorro. You can see the simple script on the left, EUR/JPY prices downloaded from IB open in the Zorro History editor and Zorro log just beneath it.
The discrepancy is in the very first bar on Sun, timestamped 21:21 ( I provided a description when attaching a screenshot - but it is not publicly visible).
I highlighted yellow the 1-min bars/prices which should constitute this 5-min bar.
Its close price should be 119.251, not 119.1365 (in log).
The last 5-min candle on Fri is correct, but the first bar on Sun 03/08 has the same problem.
Re: New Zorro version 2.25
[Re: jcl]
#479295 03/16/2012:4303/16/2012:43
I was referring to the History Script, not the History Editor. Timestamps in the History Editor are not from Zorro and I cannot comment on their precision. But thank you for checking!
Re: New Zorro version 2.25
[Re: jcl]
#479296 03/16/2013:2603/16/2013:26
The script is basic and does the job. Timestamps precision per se is irrelevant since the comparison is between the t6 file (whatever is in it) and Zorro's use of it.
So, will you investigate please?
Re: New Zorro version 2.25
[Re: jcl]
#479297 03/16/2013:4103/16/2013:41
Timestamp precision is necessarily relevant because the t6 timestamps are in floating point and affect the way t6 memory is mapped into Zorro's price() memory.
That's exactly the core problem: what's the way to ensure that the difference in the 5-7+th digit does not lead to a 1 min shift in Zorro? What 'smart' algos/heuristics are employed by Multicharts, SC, pandas, NinjaTrader, Metatrader, Excel, etc that such a problem just does not exist?
I regularly have to double-check that the prices loaded from a csv file (exported from Multicharts/IB) are correctly timestamped in a t6 file and then 'candles' are built correctly by Zorro.
But in this particular case: - History Editor shows all 1-min prices with correct timestamps (as they are received from IB and are displayed in MC and in excel) - the last/previous bars on Fri/earlier are built by Zorro correctly
- from the first bar on Sun 1-min bars are aggregated into 5-min bars incorrectly.
Re: New Zorro version 2.25
[Re: jcl]
#479303 03/16/2016:0203/16/2016:02
I can obviously not help with History Editor timestamps. That software is not from us. But if you believe that a time stamp from your CSV file was also wrong, simply post here that CSV file, script, and log with the wrong time stamp, and we'll immediately look into that. Surely this cannot be so hard?
BTW, Zorro timestamps can indeed be wrong, by 0.5 ms. That's the rounding precision of the used time function library. Afraid that's not a bug.