Zorro 2.25 is now available:

http://opserver.de/down/Zorro_225.exe

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.

Two bugs have been already reported:

- 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.

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

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.

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.

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!

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?

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.

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.

For the 3rd time:

- History Editor shows all 1-min prices with CORRECT timestamps (as they are received from IB and are displayed in MC AND IN EXCEL in a csv file)

- 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. -> the bar ending Sun 21:21 has a close corresponding to 21:20 in a t6 file.


All this is clear from the screenshot I attached earlier. -> which has both the log and t6 file opened in History editor.

If the picture is not enough I can send the t6 file and the script to support.

If you don't want to share it here, you can of course also send it to support. I've already written how you can check the timestamps, and what files we'll need if you find a wrong one. Thank you!

Just sent the t6 file,the script and the screenshot to support for replication.

What's the way to ensure that <0.5ms difference does not lead to a price being incorrectly treated by Zorro as ending 1 min later/earlier?

Can a simple algo be implemented FOR RESOLUTIONS of 1MIN+ that if the difference is <1 sec, then the timestamp is corrected up/down to the closest round minute?

No, because HFT tests can have 1 ms resolution. But if the difference is less than 0.5 ms, then it is rounded to the next minute or hour.

I understand HFT tests require TICKS and of course need almost no rounding.

But how about regular bar-based testing at resolutions above 1 min (which - i guess - is the main use case)?

No. Maybe your problem is simply a misconception of bars and ticks? What you see in the log are the bars. What you see in a history file are the ticks. Bars start and end at time boundaries, like any full minute. Ticks do not. They are unrelated to time boundaries. They get their timestamps from the price source or out of the history file. Your script can set up the time of bars, but not of ticks. Any bar contains exactly the ticks whose timestamps fall into the bar period. Maybe that has confused you.

In the manual you can find a more detailed intro to bars and ticks and their role in a trading system.

Another bug reported: The TradeOptions script had a missing semicolon on line 21. This has been fixed.

The remarks section of the Markowitz manual page is a bit jumbled, formatting error?
https://zorro-project.com/manual/en/markowitz.htm

Indeed. This will be fixed.

There is some missing code int the ZorroFolder/include/r.h file.
Below line of codes need to be added.


int Rstart(const char* source,int debug)
{
if(hR) return hR; // R session already running
#ifdef WIN32
g->RLib = LoadLibrary("mt4R.dll");
PROC(RInit_);
PROC(RIsRunning);
PROC(RIsBusy);
PROC(RExecute);
PROC(RExecuteAsync);
PROC(RAssignString);
PROC(RAssignInteger);
PROC(RAssignDouble);
PROC(RAssignVector);
PROC(RAssignMatrix);
PROC(RGetInteger);
PROC(RGetDouble);
PROC(RGetVector);
PROC(RPrint);
PROC(RLastOutput);
PROC(RDeinit); <========================================= THIS!!
#endif
hR = RInit_(strf("%s --no-save",g->sRTermPath), debug);
if(!hR) {
print(TO_WINDOW,"\nCan't open %s\n ",g->sRTermPath);
return 0;
}
if(!RIsRunning(hR)) {
print(TO_WINDOW,"\nCan't run R!\n ");
return 0;
}
Rx("rm(list = ls());",0); // clear the workspace
if(source) if(*source)
Rx(strf("source('%sStrategy/%s')",slash(ZorroFolder),source),2);
return hR;
}

Thanks, we'll add it in a future version. But RDeinit is normally not used in the script, because R is anyway deinitialized after the script run.

Thank you jcl. I use visual c++ 2017. When I try to test the sample "RTest.c", There is some exception error when closing. Please check that (running code in visual c++).

Check if you converted it correctly. Compare your code with the VC++ version of RTest in the MyStrategy.cpp example.

I tried but the exception position is somewhere inside of zorro systems. So I can't proceed further.

It is unlikely that you get an exception and all other people with the same code get none. Compare your code with the included cpp and check also your VC++ setup. Follow the instructions in the manual. Maybe the struct alignment is wrong or something like that.

When will this version become the official one?

It is already.

https://zorro-project.com/news.php

Hi,

I have a ZORRO S 2.25.7


One instance running normal - in the arbitrage. MT4 and Bitfinex

But If I trying run other instance, is a very slow. I trying in the second IndicatorTest.c

May be is problem with DLL?

Thanks Milan

To be honest, with 2.25 I encounter a lot of situations that haven't been there before.

Instance just closing, partly reproducable, e.g. run simulation 1, open result chart, run simulation 2 and move zoom in and out the result while simulation 2 is drawing / updating the previous result.

Memory fragmented or similar message soemtimes shows up, it can be due to my s**** computer, so I can't really tell.

I trying 2 stragies from Zorro



First running without problems, after RUN the second, this is a frozen



Is a older version for download ready? May be is problem with my PC ( WIN7 ).

I found where is a problem. One my instance is running with broker arbitrage. If I start any second instance, whitch trying use the same DLL, is a verry slow.
In the manual:
Brokers A and B must not use the same broker plugin Dll.

But if use other instance, must be also other Dll.

Instance 1 (ARB).... Broker A ... plugin1.dll, Broker B ... plugin2.dll
Instance 2 - only one plugin - Broker C ... plugin3.dll <-- don't use the same dll like Instance 1
Instance 3 - only one plugin - Broker C ... plugin3.dll

Sorry for my english.