New features: contour charts, a reality check template, more cryptocurrency exchange plugins. and a lot other new features. The full list can be found on https://manual.zorro-project.com/new.htm.
This release candidate will become the official release when no bugs are found in the next time. Please test everything and report any issues here! As usual, if you're the first one to find a serious bug of this release candidate, you can get a free Zorro S subscription or support extension.
Re: New Zorro version 2.40
[Re: jcl]
#483740 07/19/2117:2907/19/2117:29
Hello JCL, I have downloaded the latest version 2.40.1 Installed it on a brand new directory I've set verbose=7 in Z.ini Started the software as free Zorro Same results Tested with two brokers: Roboforex demo account leverage 500 and XM demo account with leverage 888 Orders open/closed by means of MT5 are accepted Orders requested by tradetest.c are rejected, no more explanation on the MT5 expert tab ref. to the annexed screenshots
Last edited by dpn; 07/20/2118:44.
Re: New Zorro version 2.40
[Re: jcl]
#483755 07/21/2107:4607/21/2107:46
Honestly, I have not updated the bridge, thinking it did not change since version 2.40.0. I will try to update it as soon as possible and will keep you informed. Thank you JCL
Re: New Zorro version 2.40
[Re: dpn]
#483765 07/21/2119:3907/21/2119:39
Honestly, I have not updated the bridge, thinking it did not change since version 2.40.0. I will try to update it as soon as possible and will keep you informed. Thank you JCL
Hi JCL, MT5 bridge updated: All is OK, now. Thanks.
Re: New Zorro version 2.40.1
[Re: jcl]
#483793 07/26/2118:3207/26/2118:32
If you get different trades from different versions, first check the log. Determine which trades are different and how. You will then normally quickly see the reason. If something is unclear, post the details here.
Re: New Zorro version 2.40.1
[Re: jcl]
#483805 07/28/2116:1707/28/2116:17
I think Dataset functions are behaving differently compared to version 2.35. Is this expected?
Code:
Code
void run()
{
if (is(INITRUN))
{
int handleID = 1;
int len = dataParse(handleID, "ssss,i,f,f,f,f,f,f,f,f,f,f,f,f,f,f,f,f,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i,i", "History\\Test.csv"); // Asset name 15 (4 * s - 1) character max
int i, j;
for(i = 0; i < len; i++) {
printf("Row %i: %s %i %i \n", i, dataStr(handleID, i, 1), dataInt(handleID, i, 5), dataInt(handleID, i, 38));
for(j = 0; j < 8; j++) {
printf("%f %f %i %i \n", dataVar(handleID, i, 6 + j), dataVar(handleID, i, 14 + j), dataInt(handleID, i, 22 + j), dataInt(handleID, i, 30 + j));
}
}
// free data memory
dataNew(handleID, 0, 0);
printf("\n\n");
}
}
If you get different trades from different versions, first check the log. Determine which trades are different and how. You will then normally quickly see the reason. If something is unclear, post the details here.
No, I get exactly the same trades, same profit, annual growth rate, percent winning, MAE and so on... same report but the only difference between versions are those values and the (null) value in Simulation mode.
Re: New Zorro version 2.40.1
[Re: jcl]
#483807 07/28/2118:1107/28/2118:11
Hmm, that sounds indeed strange. Can you contact support@opgroup.de and send them that script? They'll look into it.
Ozgur: I believe the first field is 0, not 1. Indices start with 0. The other column numbers are probably also wrong. Can you check if it works when you fix the numbers? Datasets expect a date in field 0, so I don't know what happens when it is missing, but possibly the old version got then some phantom field and thus worked with the wrong numbers.
Re: New Zorro version 2.40.1
[Re: jcl]
#483809 07/28/2118:4207/28/2118:42
Hmm, that sounds indeed strange. Can you contact support@opgroup.de and send them that script? They'll look into it.
I am using your Alice3b.c script for testing, but I am seeing the problem with any script. I tested in 2 different computers before writing here. It only happens on Test mode. Trade mode reports are Ok.
Last edited by CpOo; 07/28/2122:14.
Re: New Zorro version 2.40.1
[Re: jcl]
#483811 07/29/2108:3307/29/2108:33
Ah, ok. We'll check that and when it happens here too, it will be fixed. Since you found a bug in a release candidate, you're entitled for a 3 months free Zorro S subscription or support period - please contact Support for claiming the reward.
Ozgur: You can also claim a free subscription. The problem was indeed the missing date field, but both versions did not react consistently when it's missing. This will be fixed so that datasets with no date are now officially supported. But you must then still change your field numbers. The first field is 0 and the next integer field is 3, since the first 3 fields are needed for the string.
Re: New Zorro version 2.40.1
[Re: jcl]
#483813 07/29/2112:0907/29/2112:09
My 2-minute bar options strategy surfaced a problem on 2.40.2
This is the code I use to load the options chain for the upcoming bar inside tock, when in Test mode.
The month() call is used to specify the T8 file name.
As you can see from the attached screenshot, month() stays at 1 when the actual month changed to February. This continues for the entire simulation period, LOOKBACK or not, resulting in no trades.
This code works fine in 2.35.6 and previous version going back at least couple of years.
Looks like month() is acting weird inside of tock(), or maybe elsewhere too.
Afraid not, but I now see the reason of the problem.
Inside a tick or tock function, month(0) is the current time. month(1) is the end of the previous bar. Depending on when the function runs, both can be identical. So your comparison is not good, even if it may have worked sometimes. For correctly finding a month change, either compare month(0) != month(1) in the run function, or compare month(0) in the tock function with month(0) of the previous tock.
Re: New Zorro version 2.40.2
[Re: jcl]
#483846 08/03/2109:3708/03/2109:37
I hear what you're saying. But I still believe there is a problem in 2.40 when tock was moved to execute after tick, which makes sense conceptually.
Take a look at these log clippings and you'll see the problem.
In v2.35, tock is executed before run(), and tock() has the same time stamp and BarNum as the upcoming run() , which make sense.
In v2.40, tock is executed before run(), and tock() has the new BarNum, BUT..... old timestamp of the previous bar.
This probably causes month(1) to equal month(0). I also did do as you suggested and check for month change in run(). But because of this problem, I am only able to detect a month change in bar 2 of the new month.
FYI, this the formula I used for the timestamp printed in the log.
int utcHHMM = hour()*100+minute();
Code
..................... v 2.35 and before .........................
[1430] Bar[975] TOCK -- [SPX]
[975: Mon 21-02-01 14:30] 3727.72/3727.72\3703.61/3707.86 -0.01
[1430] Bar[975] run() -- price=3707.86
[1432] Bar[976] TOCK -- [SPX]
[976: Mon 21-02-01 14:32] 3751.48/3753.72\3751.48/3753.72 -0.01
[1432] Bar[976] run() -- price=3753.72
................... v2.40 ............................................
[974: Fri 21-01-29 20:58] 3730.72/3734.22\3727.72/3727.72 -0.01
[2058] Bar[974] run() -- price=3727.72
[2058] Bar[975] TOCK -- [SPX] <------------------------ bad time stamp for Bar 975. it should be 1430
[975: Mon 21-02-01 14:30] 3727.72/3727.72\3703.61/3707.86 -0.01
[1430] Bar[975] run() -- price=3707.86
[1430] Bar[976] TOCK -- [SPX] <--------------------------- bar time stamp for Bar 976. it should be 1432
[976: Mon 21-02-01 14:32] 3751.48/3753.72\3751.48/3753.72 -0.01
[1432] Bar[976] run() -- price=3753.72
Last edited by SBGuy; 08/03/2112:33.
Re: New Zorro version 2.40.2
[Re: jcl]
#483850 08/04/2107:0908/04/2107:09
The tock timestamp is _not_ the end of the next bar. It is simply the current time. In 2.40 tock is run by the internal state machine in the backtest, so that tock timestamps are always synchronized to the ticks. In 2.35, tock timestamps were unsynchronized.
Whether to detect month changes in run or in tock depends on what for you're using it. If your script must react immediately on a new month, even in the middle of a bar, then you must check the change of month(0) inside tock or tick. That's easy with a static variable.
Re: New Zorro version 2.40.2
[Re: jcl]
#483852 08/04/2109:0108/04/2109:01
Ah, ok. We'll check that and when it happens here too, it will be fixed. Since you found a bug in a release candidate, you're entitled for a 3 months free Zorro S subscription or support period - please contact Support for claiming the reward.
Thanks!
Re: New Zorro version 2.40.2
[Re: jcl]
#483855 08/04/2115:2608/04/2115:26
My understanding in 2.40 is that execution order is now: tick, TOCK, TMF, run.... instead of TOCK, tick, TMF, run as in 2.35.
My observation from this log snippet below is that a contractUpdate() in Bar 976 tock, will load the options chain from time 1430, which is Bar 975. The TMF that executes before run will used the options chain from 1430. This problem may not be that big using 2 minutes bars, but will be a big problem longer bars.
So... in short, my original month detection problem has evolved to a potential tick/tock/run timing problem.
See the log below.
In v2.35 all the bars have the same time stamp, i.e. tick, tock, run associated with Bar 976 have a timestamp of 1432, which makes sense. In v2.40 tick, tock in Bar 976 have a time of 1430, and run has a time of 1432... doesn't look right to me.
Hmm. If bar N ends with time t1, and bar N+1 ends with time t2, then I would normally expect for all the ticks and tocks of bar N+1 timestamps that start with t1 and end with t2. Won't you agree?
Re: New Zorro version 2.40.2
[Re: jcl]
#483861 08/05/2117:0908/05/2117:09
I'm not sure I know enough about the internals of Zorro to opine on your question.
But let me ask you this in the context of my specific application, using the details of the log entries below:
If contractUpdate() is called in Bar 976 TOCK, or tick, which has a timestamp of 1430, which contract chain do you think will be loaded? (a) the chain for time of 1430 (the tick/tock timestamp) (b) the chain for time of 1432 (the Bar 976 time)
Interesting. I was hoping for (b) because that's how it works in 2.35 where all the timestamps for tick/tock/run are the same.
Here's another log with priceClose(0) displayed.
As you can see, Bar 976 tick/TOCK has a timestamp of 1430, and yet the priceClose(0) of 3753.72 is actually from the end of Bar 976. This means regardless of timestamp tick/tock is getting prices at the end of Bar 976, which is 1432.
If you agree that this is the correct behavior, then I would submit that contactUpdate inside of tock should ALSO pull the contract chain at 1432, as options prices are mathematically linked to the UL price.
Imagine the BarPeriod=60, the UL price and corresponding options chain, inside tock, will be 1 hour apart!!! That's a big problem.
There was not a problem in 2.35 and prior versions.
Ok, I understand the problem with the close price. Since you are not using TICKS mode, the only available close price is the close of the bar. More correct would be returning the bar open price instead. But priceClose returning an open price would be somewhat inconsistent.
We'll think about a solution.
Re: New Zorro version 2.40.2
[Re: jcl]
#483869 08/06/2117:5808/06/2117:58
I update version 2.35 to 2.40.3. I used same back test data, but process differently. Plotting .t6 file is ok, but when backtesting it process differently. I attach capture image, price data looks ok but bactesting result show wrong chart. also cause wrong backtesting result.
Re: New Zorro version 2.40.3
[Re: jcl]
#483871 08/07/2106:2208/07/2106:22
When plotting is ok but the backtest has strange candles then something in your script produces wrong prices. Its either a script bug or a zorro bug. Send that script and history to support. If its a zorro bug you can get a free subscription.
Re: New Zorro version 2.40.3
[Re: Petra]
#483873 08/07/2106:4808/07/2106:48
Hi, Thank you for the solution. The problem is now fixed. I don't know why the sensitivity changed in new version, but would better be careful changing something. I was very confused why new version proceed differently when I just update to new version.
I hope you to kindly provide new subscription for me. Would you?
Last edited by 7th_zorro; 08/11/2101:16.
Re: New Zorro version 2.40.3
[Re: jcl]
#483893 08/11/2111:4208/11/2111:42
Can confirm that in the 2.40.3 version installation the Binance Futures Plugin is missing. I understand that it's possible to copy the dll from the 2.41.1 to the 2.40.3 without any problem, right?
BTW: 2.41.1b is still not fixed with the latest reported issues, 2.40.3 is.
Last edited by CpOo; 08/11/2113:01.
Re: New Zorro version 2.40.3
[Re: jcl]
#483896 08/12/2108:2108/12/2108:21
I cannot confirm any missing plugins, but I can confirm that 2.41.1 beta corresponds to the old 2.40.1 release. There will be a new beta in the next days.
Re: New Zorro version 2.40.3
[Re: jcl]
#483907 08/13/2109:1208/13/2109:12
Changes: Default outlier detection is now less sensitive. And after many discussions, we have now moved tick and tock from the start to the end of the bar when no TICKS flag is set. This makes close price and timestamp match. It TICKS is set, or in trade mode, the behavior is as before.
Re: New Zorro version 2.40.3
[Re: jcl]
#483911 08/13/2116:5008/13/2116:50
Thanks for the tick/tock time fix. I can confirm that tick/tock does in fact run at the end of the bar in v2.40.4
However, the tmf that execute before the run() is still running at the beginning of the bar. This difference between v2.35 and v2.40 causes meaningfully significant difference in backtest results.
In 2.40.4, the execution sequence looks like this: tmf [timestamp = bar begin] tick [timestamp = bar END] tock [ timestamp = bar END] run [timestamp = bar END]
I believe the TMF in this group should also execute at a timestamp=bar END, and with this sequence
tick [timestamp = bar END] tock [ timestamp = bar END] tmf [timestamp = bar END] run [timestamp = bar END]
Basically tmf should run AFTER tick/tock, like v 2.35
Hope you agree.
Thanks.
Re: New Zorro version 2.40.3
[Re: jcl]
#483915 08/14/2110:5808/14/2110:58
Binance Futures plugin is not missing this time and it seems that it's updated from 1.0.2.6 to 1.0.2.7, but couldn't find if there are any important changes.
BTW: May I claim a perpetual license due to my report?
Re: New Zorro version 2.40.3
[Re: jcl]
#483918 08/14/2112:4708/14/2112:47
There is no execution sequence for TMFs. They are triggered by ticks, entry, stop, and other events, and run when that event happens. In case of ticks they run at the same time as the tick function.
Re: New Zorro version 2.40.3
[Re: jcl]
#483945 08/16/2115:3408/16/2115:34
The TMF below executes immediately before the upcoming run(), after getting the latest tick price.
As you can see, it ran before tick and TOCK. As a result it doesn't get the options chain for time 1840 that was loaded in TOCK.
What I am suggesting is that instead of this execution sequence: TMF, tick, TOCK, run
It should be this, just like 2.35 and before. tick, TOCK, TMF, run
I don't think making this change will cause any internal Zorro issues at all. In fact, I think it'll make it better for all TMF events: tick, TOCK, TMF event....
From 2.40.5. As you can see, none of the other tmf events were triggered at 1840. Therefore it must be triggered by a normal tick.
All I am saying is that the TMF execution, regardless of event type, should run AFTER tick() tock(), like it was in v.2.35 and many version before.
The manual says "TMF runs at every tick". Therefore you must allow tick() and tock() to completely finish and provided any pre-processing that is related to that tick. In my case, that pre-processing is loading tick specific options chains, before TMF can run so that the TMF can have all the latest prices associated with that new tick.
In my example below, the UL price ($3816.59) is from time 1840 and the options price is from time 1838 (UL=$3815.3). This is wrong.
Thanks.
Code
[1840] INSIDE myTMF[489449]: priceClose(0)=3816.59
TradeIsEntry = 0
TradeIsStop = 0
TradeIsProfit = 0
TradeIsClosed = 0
2021-03-05,Call,20210308,3810.0,3815.3,32.60,32.10,0.529,773, <------ this option data is from the previous tick at time 1838
ContractBid[32.10] ContractAsk[32.60] TradeStopLimit[27.75]
[4895: 1840] tick priceClose[3816.59]
[4895: 1840] TOCK -- [SPX] Loading chain...
[4895: 1840] TOCK priceClose[3816.59] -- [C:\Zorro\History\SPX-Options\\SPX_202103_m1.t8] 600 contracts loaded...
[4895: Fri 21-03-05 18:40] 860 -1912 5/4 3815.25/3816.59\3815.09/3816.59 -0.01SliderLots = 20
Last edited by SBGuy; 08/19/2115:47.
Re: New Zorro version 2.40.5
[Re: jcl]
#483968 08/20/2108:3208/20/2108:32
Yes, when triggered by a price quote the TMF always runs before tick. It must react fast to the new price. Tick has lower priority. Tock is anyway not price triggered.
Re: New Zorro version 2.40.5
[Re: jcl]
#483971 08/20/2115:2308/20/2115:23
So, it looks like I can't convince you to revert things back to 2.35 behavior.
What do you suggest I do as a work around?
My TMF must have a synchronized options chain for the underlyprice/timestamp the TMF is executing. Otherwise the result is just plain wrong.
I moved the contractUpdate() call to inside the TMF and it DID load the correct options chain, but it also caused an infinite loop on the first TMF call.
Last edited by SBGuy; 08/20/2115:28.
Re: New Zorro version 2.40.5
[Re: jcl]
#483978 08/22/2110:0908/22/2110:09
Option chains should in live mode only be loaded once per day and only in the run function. It can take 1 hour to load an option chain. This cannot work with tock or tmf. i have also not heard of someone who had that idea.
If the tmf needs the current price, call contractprice. Infinite loops in tmfs are mostly by opening new trades and producing an infinite recursion.
Re: New Zorro version 2.40.5
[Re: jcl]
#483980 08/22/2114:3008/22/2114:30
As said previously, this problem is for backtest only. There are no problems in live trading because contractPrice gets the most current contract prices from the broker plugin.
As you know in backtest, contractPrice called in TMF only uses price data from whatever historical contract chain was loaded in the most recent contractUpdate.
As you know, contractUpdate only loads the snippet of options chain from the large historical .t8 file, ONLY for the "current time."
My work around for this limitation in the past was to call contractUpdate in tock, when TMF runs after tock. Thereby providing the latest contractPrices to TMF.
In 2.40, you guys changed the execution order from tick, tock, TMF, run to: TMF, tick, tock, run.
As a result, the current time for TMF lags the options chain time for exactly 1 Bar, or 1 tick (if TICKS flag was applicable).
Since options price and UL price are mathematically correlated, it is wrong to have priceClose() and contractPrice() be from 2 different times.
I've been trying to explain this for the past few days, and I can't seem to be get through.
I don't know what the reason was to change the execution order to TMF, tick, tock, run after many years.
I am saying this new execution sequence is fundamentally wrong in backtest. If backtest is flawed, what's the point of live trading?
jcl said this earlier "when triggered by a price quote the TMF always runs before tick. It must react fast to the new price."
v 2.40 reacts fast to the latest UL price ONLY, but not the latest contractPrice.
Change the execution order back to tick, tock, TMF, run, and everything will be fine.... at least for backtest.
Thank you.
Re: New Zorro version 2.40.6
[Re: jcl]
#483985 08/23/2107:2908/23/2107:29
I already tried to explain that the order of function calls was not changed, since previous versions had no particular order. It depended on circumstances. Only from 2.40 on there is a state machine that triggers events in a fixed order. But that does not mean that you should use that order in your script.
If a script only works with a certain order of events, I would normally consider that a bug. I would not accept such a script from a freelancer unless there is a special reason for it. If you need a certain order of function calls, have code in your script that calls these functions in that order. Update the options first and update your trades afterwards. I don't see why you would need some tick or tock for that.
If there is a problem that you cannot solve, post it. If there is really no solution with the current Zorro version, we'll implement one. But I doubt that this will be needed.
Re: New Zorro version 2.40.7
[Re: jcl]
#484021 08/30/2108:1808/30/2108:18
I found an important problem (IMHO) with the latest release candidate related to data download from the Broker. Not sure if the problem is with assetHistory or with the broker Plugin (or maybe it's not a problem at all but my problem or my miss understanding) but I am seeing 1 minute gap each time I download new prices. Also in trade mode. I only test this with the Binance Futures plugin.
The result is a 1 bar gap between each Download call.
I attach a ZHistoryEditor capture (gaps1.jpg). Please note the gap at 16:42, between both Downloads described above. Bar at 16:42 is missing (from the first download call) and also last 16:44 bar is missing.
If I try to Download again, no matter when, Download will start at 16:45 as Zorro thinks that 16:44 is loaded, but it's not. See capture2.jpg.
I also try to download fresh data with assetHistory and OVERRIDE but with same result. First 1500 bars are loaded from Binance, but only 1499 are saved and if I repeat again new ones start 1 minute after the last saved, with the gap in between.
Last example. Log from Trade mode (_real.log) from other Asset:
Price at 16:04 is missing. I downloaded prices at 16:04 and then I download again few minutes later.
Finally... I also try to download from the Binance API at the same time that I call the API, just to double-check that Binance had the prices at the download time, and the prices were there and can't figure out why Zorro is not saving the last one.
Re: New Zorro version 2.40.7
[Re: jcl]
#484045 09/01/2117:2809/01/2117:28
Version 2.40.8: History fix for the Binance Futures plugin, and a possible gap after the lookback history is now filled with a single bar, not with multiple bars.
2.40.9: Fix for finding contracts with less than 1 day expiration.
Re: New Zorro version 2.40.9
[Re: jcl]
#484130 09/13/2108:5409/13/2108:54
![[Linked Image]](https://i.imgur.com/8Jy7G61.png)
