Gamestudio Links
Zorro Links
Newest Posts
Blobsculptor tools and objects download here
by NeoDumont. 03/28/24 03:01
Issue with Multi-Core WFO Training
by aliswee. 03/24/24 20:20
Why Zorro supports up to 72 cores?
by Edgar_Herrera. 03/23/24 21:41
Zorro Trader GPT
by TipmyPip. 03/06/24 09:27
VSCode instead of SED
by 3run. 03/01/24 19:06
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
5 registered members (Quad, TipmyPip, degenerate_762, AndrewAMD, Nymphodora), 997 guests, and 5 spiders.
Key: Admin, Global Mod, Mod
Newest Members
sakolin, rajesh7827, juergen_wue, NITRO_FOREVER, jack0roses
19043 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 6 of 7 1 2 3 4 5 6 7
Re: New Zorro version 2.40.5 [Re: jcl] #483966
08/19/21 15:46
08/19/21 15:46
Joined: May 2018
Posts: 134
S
SBGuy Offline
Member
SBGuy  Offline
Member
S

Joined: May 2018
Posts: 134
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/21 15:47.
Re: New Zorro version 2.40.5 [Re: jcl] #483968
08/20/21 08:32
08/20/21 08:32
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline OP

Chief Engineer
jcl  Offline OP

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
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/21 15:23
08/20/21 15:23
Joined: May 2018
Posts: 134
S
SBGuy Offline
Member
SBGuy  Offline
Member
S

Joined: May 2018
Posts: 134
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/21 15:28.
Re: New Zorro version 2.40.5 [Re: jcl] #483978
08/22/21 10:09
08/22/21 10:09
Joined: Apr 2008
Posts: 585
Austria
Petra Offline
Support
Petra  Offline
Support

Joined: Apr 2008
Posts: 585
Austria
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/21 14:30
08/22/21 14:30
Joined: May 2018
Posts: 134
S
SBGuy Offline
Member
SBGuy  Offline
Member
S

Joined: May 2018
Posts: 134
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/21 07:29
08/23/21 07:29
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline OP

Chief Engineer
jcl  Offline OP

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
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/21 08:18
08/30/21 08:18
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline OP

Chief Engineer
jcl  Offline OP

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
New version: 2.40.7

A bug with cancelTrade was fixed.

Re: New Zorro version 2.40.7 [Re: jcl] #484026
08/30/21 11:51
08/30/21 11:51
Joined: Oct 2018
Posts: 82
7
7th_zorro Offline
Junior Member
7th_zorro  Offline
Junior Member
7

Joined: Oct 2018
Posts: 82
I know you are busy, but can you give me a rough schedule regarding 64bits support? Thank you.

Re: New Zorro version 2.40.7 [Re: jcl] #484037
08/31/21 18:51
08/31/21 18:51
Joined: Feb 2021
Posts: 19
C
CpOo Offline
Newbie
CpOo  Offline
Newbie
C

Joined: Feb 2021
Posts: 19
Hi,

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.

Steps to reproduce the problem:

Script: Download.c with following config:

Code
#define VERBOSE	7+DIAG

And also I include Outlier = 0; just in case:
Code
void main()
{
...
Outlier = 0;
...

In the Download panel:

NKNUSDT
2021-2021
M1
Ask/Bid
Broker
-> Click Download

From the .diag file:

Code
!Connecting to  websocket...
!Websocket connected.
printf: 
!§s: 1 2901.173600 ms
BrokerTime: 2021-08-31  16:42:06: 2 7.525700 ms
printf:  at UTC §s
Open NKNUSDT  >Save
Open: Log\Assets.csv wb  >Hist  >File History\NKNUSDT_2021.t6  >Prices
Hist 01-01 00:00 .. 08-31 16:42: 388313
printf: 
§s: §i MB allocated
Ticks:
BrokerHistory NKNUSDT: 
HTTP: https://fapi.binance.com/fapi/v1/klines?symbol=NKNUSDT&interval=1m&startTime=1630427819000&endTime=1630428126000&limit=1500,(null),(null)5
printf: 
!§s §s to §s
printf: 
!=> §s to §s, §i ticks 5
printf: 
Load §s 
printf: §d..
Open: History\NKNUSDT_2021.t6 wb
printf:  §i min
Total: 5 207720 0
Raus
Neural
Login BinanceFutures 1->0
printf: 
Logout..


The script loads 5 bars from the broker and add them to the .t6 file. I can see them with History.c script and also with the ZHistoryEditor.

First problem is that the Broker API call returns 6 bars, and it seems that Zorro is not saving the last one. If you paste the above URL (https://fapi.binance.com/fapi/v1/kl...amp;endTime=1630428126000&limit=1500) where:

startTime is Tue Aug 31 2021 16:36:59
endTime is Tue Aug 31 2021 16:42:06

You can see the 6 prices from Binance:

Code
[[1630427820000,"0.44780","0.44780","0.44600","0.44665","89850",1630427879999,"40155.24761",142,"21596","9652.74538","0"],
[1630427880000,"0.44646","0.44666","0.44454","0.44474","92428",1630427939999,"41153.78206",173,"10736","4787.09330","0"],
[1630427940000,"0.44496","0.44640","0.44496","0.44601","103252",1630427999999,"45995.73933",121,"87631","39028.90056","0"],
[1630428000000,"0.44628","0.44633","0.44580","0.44587","11299",1630428059999,"5039.44539",51,"5783","2579.46923","0"],
[1630428060000,"0.44585","0.44607","0.44574","0.44607","10934",1630428119999,"4875.16577",38,"5078","2264.55739","0"],
[1630428120000,"0.44586","0.44593","0.44570","0.44584","6215",1630428179999,"2770.86145",24,"4605","2053.17810","0"]]


First bar is Tue Aug 31 2021 16:37:00
Last bar is Tue Aug 31 2021 16:42:00

But when I check the .t6 file with the ZHistoryEditor I don't see the last bar and prices finish at 16:41 with this bar from binance:

Code
[1630428060000,"0.44585","0.44607","0.44574","0.44607","10934",1630428119999,"4875.16577",38,"5078","2264.55739","0"],


I repeated the same steps 2 minutes later:

Code
!Connecting to  websocket...
!Websocket connected.
printf: 
!§s: 1 2740.935300 ms
BrokerTime: 2021-08-31  16:44:05: 2 9.992100 ms
printf:  at UTC §s
Open NKNUSDT  >Save
Open: Log\Assets.csv wb  >Hist  >File History\NKNUSDT_2021.t6  >Prices
Hist 01-01 00:00 .. 08-31 16:44: 388315
printf: 
§s: §i MB allocated
Ticks:
BrokerHistory NKNUSDT: 
HTTP: https://fapi.binance.com/fapi/v1/klines?symbol=NKNUSDT&interval=1m&startTime=1630428179000&endTime=1630428245000&limit=1500,(null),(null)1
printf: 
!§s §s to §s
printf: 
!=> §s to §s, §i ticks 1
printf: 
Load §s 
printf: §d..
Open: History\NKNUSDT_2021.t6 wb
printf:  §i min
Total: 1 207725 0
Raus
Neural
Login BinanceFutures 1->0
printf: 
Logout..


Zorro loads and save 1 bar (only the first one), but Binance returns 2 bars:

Code
[[1630428180000,"0.44586","0.44606","0.44575","0.44603","12522",1630428239999,"5583.24085",41,"7296","3253.43500","0"],
[1630428240000,"0.44608","0.44674","0.44590","0.44672","26771",1630428299999,"11943.50777",59,"8209","3663.38510","0"]]


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:

Code
...
[3304: Tue 21-08-31 16:01c] 47439.56/47450.00\47410.28/47425.61 -0.01
[3305: Tue 21-08-31 16:02c] 47425.61/47472.37\47361.71/47396.98 -0.01
[3306: Tue 21-08-31 16:03c] 47396.98/47464.10\47396.90/47464.10 -0.01
[3307: Tue 21-08-31 16:05c] 47479.74/47547.73\47479.74/47537.50 -0.01
[3308: Tue 21-08-31 16:06c] 47537.50/47550.00\47494.00/47500.55 -0.01
[3309: Tue 21-08-31 16:07c] 47500.55/47501.84\47432.32/47434.01 -0.01
[3310: Tue 21-08-31 16:08c] 47434.02/47452.39\47385.72/47411.86 -0.01
...

End of lookback period
...


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.

Attached Files gaps1.jpgcapture2.jpg
Re: New Zorro version 2.40.7 [Re: jcl] #484045
09/01/21 17:28
09/01/21 17:28
Joined: Jul 2000
Posts: 27,977
Frankfurt
jcl Offline OP

Chief Engineer
jcl  Offline OP

Chief Engineer

Joined: Jul 2000
Posts: 27,977
Frankfurt
Hmm, we'll look into that. Maybe some issue with the Binance plugin.

Page 6 of 7 1 2 3 4 5 6 7

Moderated by  Petra 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1