This version will become the official release when no bugs are found in the next time. New features: realtime chart generation, interactive payoff diagrams for options, emails on errors, new indicators, 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.30
[Re: jcl]
#480853 07/19/2009:2507/19/2009:25
https://zorro-project.com/manual/en/transform.htm Spearman(vars Data, int TimePeriod): var Spearman's rank correlation coefficient; correlation between the original Data series and the same series sorted in ascending order within TimePeriod (1..256). Returns the similarity to a steadily rising series and can be used to determine trend intensity and turning points. Range = -1..+1, lag = TimePeriod/2. For usage and details, see Stocks & Commodities magazine 2/2011. Source available in indicators.c.
What are those "arbitrary functions"? Already listed above?
Re: New Zorro version 2.30
[Re: jcl]
#480855 07/19/2011:5307/19/2011:53
The arbitrary function is whatever you use to generate vars Data. Spearman is just a type of correlation (based on rank, not distances of data points)...
Re: New Zorro version 2.30
[Re: jcl]
#480856 07/19/2013:4707/19/2013:47
You should run diff-checks on all of your manual pages between the online version and the distributed helpfile version, because I am finding lots of differences!
Online but not in help file: * From what's new page: "Spearman correlation with arbritrary functions. New Ehlers indicators: CTI, CCYI, CCYIR, CCYIState." * correl() function description
In help file but not online: * assetSelect() function description * updated MarginCost description
The "What's New" page does not clarify it is referring to correl() and not to Spearman().
Quote
var correl(vars Data, int Length, function) Spearman correlation of the Data series with an arbitrary function. Used for the CTI, CCYI, and CCYIR indicators. Source in indicators.c; usage and description on Financial Hacker.
Zorro 'peeks' by one 'tick' when entering trades by returning 2 in a tmf.
This script:
Code
[size:8pt]function stp(var entStp) {
print(TO_LOG,"\n in tmf: %s, high = %.5f, close = %.5f", strdate(HMS,wdate(0) ), priceHigh(0), priceClose(0) );
if (TradeIsPending)
{
if (TradeIsLong)
if (priceHigh(0)>priceOpen(0)+entStp ) // or priceClose(0)>
{
print(TO_LOG,"\n ---- long Entry Stop is hit!----open=%.5f, high=%.5f close=%.5f entStp=%.5f", priceOpen(0), priceHigh(0), priceClose(0), priceOpen(0)+entStp);
return 2;
}
}
return 4;
}
function run()
{
set(LOGFILE, TICKS);
Verbose = 3;
Spread=Slippage = 0;
BarPeriod = 60;
StartDate = 2019; //2015
EndDate = 2020;//0424;
asset("EUR/USD");
var atr = ATR(24);
LifeTime=1;
Entry = 1.5*atr;
enterLong(stp,0.5*atr);
} [/size]
generates this output:
Quote
[80: Mon 19-01-07 13:00] 1.14407/1.14474\1.14368/1.14394 -0.0 Enter Long EUR/USD Entry 0.0023498 at 13:00:00 (EUR/USD::L) Long 1@1.14629 Entry stop in tmf: 13:01:00, high = 1.14429, close = 1.14418 in tmf: 13:02:00, high = 1.14450, close = 1.14448 in tmf: 13:03:00, high = 1.14451, close = 1.14444 in tmf: 13:04:00, high = 1.14451, close = 1.14418 in tmf: 13:05:00, high = 1.14451, close = 1.14438 in tmf: 13:06:00, high = 1.14451, close = 1.14444 in tmf: 13:07:00, high = 1.14453, close = 1.14452 in tmf: 13:08:00, high = 1.14453, close = 1.14443 in tmf: 13:09:00, high = 1.14453, close = 1.14440 in tmf: 13:10:00, high = 1.14453, close = 1.14436 in tmf: 13:11:00, high = 1.14453, close = 1.14439 in tmf: 13:12:00, high = 1.14453, close = 1.14424 in tmf: 13:13:00, high = 1.14453, close = 1.14409 in tmf: 13:14:00, high = 1.14453, close = 1.14423 in tmf: 13:15:00, high = 1.14453, close = 1.14449 in tmf: 13:16:00, high = 1.14453, close = 1.14448 in tmf: 13:17:00, high = 1.14462, close = 1.14453 in tmf: 13:18:00, high = 1.14464, close = 1.14462 in tmf: 13:19:00, high = 1.14464, close = 1.14441 in tmf: 13:20:00, high = 1.14483, close = 1.14480 ---- long Entry Stop is hit!----open=1.14394, high=1.14483 close=1.14480 entStp=1.14473 [EUR/USD::L08101] Long 1@1.14441 x at 13:20:00 Com 0.0300 Mrg 37.74 Net 0
The correct entry price should be 1.14480.
Re: New Zorro version 2.30
[Re: jcl]
#480871 07/21/2005:5407/21/2005:54
[117: Wed 19-01-09 07:00] -0.89 0 0/3 (1.14588) (EUR/USD::L) Long 1@1.14721 Entry stop (EUR/USD::L) Missed entry 1.1474 after 1 bar (EUR/USD::L) Entry stop 1.14721 hit by 1.14785 at 07:00:00 [EUR/USD::L11802] Long 1@1.14717 x at 07:00:00
This is the correct code to enumerate pending trades:
for(last_trades) if (TradeIsPending) ...
A trade can be either pending, open, or closed. So always use an if(...) condition to get the trades that you want. If a trade is neither, it's no valid trade.
And can you please post these questions to another thread? This one is about the new release.
Re: New Zorro version 2.30
[Re: jcl]
#480891 07/22/2010:0307/22/2010:03
A for loop that cycles backwards through open, pending, and closed trades with the current asset and algo, starting with the last trade
The provided log shows that it delivers not only "open, pending and closed" trades but also some missed, 'invalid' trades (that are neither) - which - as YOU WROTE - Zorro is not even supposed to store!
Right now, to achieve their stated objective, does one have to write
for(last_trades) if (TradeIsPending or TradeIsOpen or TradeIsClosed) ..... ???
The same issue is with for(all_trades) and for(past_trades).
I do not believe you meant (and there is any valid purpose) delivering such 'invalid' trades with these macros.
So, let's just make them actually do what they are supposed to.
This is a bug and it is in v 2.30.
Re: New Zorro version 2.30
[Re: jcl]
#480893 07/22/2012:2107/22/2012:21
The macros should deliver only 'real' trades - either pending, open or closed. Without **trades** 'attempted' with Entry but missed. Bug#2.5 With this bug all functions currently using these macros (like plotTradeProfile(), plotMAEGraph(), etc, possibly results() ) return results with artifacts, processing 'trades' with zero profit/mae/mfe, but counting such as 'trades' .
Code
for(all_trades)
{
var vResult = toPIP(TradeResult);
var vMAE = TradeMAE/PIP/vStep;
int n = floor(vMAE);
plotBar("Profit",n,n*vStep,0,AVG|BARS|LBL2,COLOR_PROFIT);
if(vResult > 0)
plotGraph("Win",vMAE,vResult,DOT,GREEN);
else
plotGraph("Loss",vMAE,vResult,DOT,RED);
}
So, either really do not preserve such **trades" (as you confirmed), or make for(..._trades) macros skip those.
Re: New Zorro version 2.30
[Re: jcl]
#480907 07/22/2017:0807/22/2017:08
Indeed. It made probably not much difference, but an if(TradeIsClosed) should be in the plotMAE functions - this will be corrected. It is really a bug.
Re: New Zorro version 2.30
[Re: jcl]
#480918 07/24/2010:1907/24/2010:19
function run()
{
BarPeriod = 60;
StartDate = 2019;
EndDate = 2020;
asset("EUR/USD");
var atr = ATR(24);
LifeTime=4;
Entry = -0.5*atr;
if (lhour(ET,0)==15)
enterLong();
if ( (NumWinTotal+NumLossTotal)==30 )
{
var NumWins = results(1+24,30); // Number of winning and won trades
var NumLosses = results(1+4+24,30); // Number of losing and lost trades
var pipWins = results(2+24,30)/PIP; // Total win in pips
var pipLosses = results(2+4+24,30)/PIP; // /PIPTotal loss in pips
print(TO_LOG,"\n NumWins=%i, NumLosses=%i, resNumWins=%.0f, resNumLosses=%.0f, pipWins=%.2f, pipLosses=%.2f", NumWinTotal,NumLossTotal,NumWins,NumLosses,pipWins,pipLosses);
}
}
At the moment when there are no open or pending trades, 1) results(1+24,30) is 6, while NumWinTotal is 15; same for losing trades 2) results(2+4+24,30)/PIP cannot conceivably be 213003
Re: New Zorro version 2.30
[Re: jcl]
#480956 07/27/2013:1307/27/2013:13
If it is too difficult to read 2 messages above, here is the piece of code again:
Code
if ( (NumWinTotal+NumLossTotal)==30 )
{
var NumWins = results(1+24,30); // Number of winning and won trades
var NumLosses = results(1+4+24,30); // Number of losing and lost trades
var pipWins = results(2+24,30)/PIP; // Total win in pips
var pipLosses = results(2+4+24,30)/PIP; // /PIPTotal loss in pips
print(TO_LOG,"\n NumWins=%i, NumLosses=%i, resNumWins=%.0f, resNumLosses=%.0f, pipWins=%.2f, pipLosses=%.2f", NumWinTotal,NumLossTotal,NumWins,NumLosses,pipWins,pipLosses);
}
BUT in this specific moment, there are no open trades (have a look at my original message: the log showed that the open trade has just been closed at 19-06-20 00:00.)
So, using +16 or +24 (or not using any) should return a number equal to NumWinTotal over 30 trades.
Addition: just tried this example with +8 (only open trades ) -> It returns exactly the same numbers for # of trades and pips as with +24, - at the moment when there are NO OPEN TRADES (and it should return zeros).
Pls confirm you can replicate this.
Last edited by Zheka; 07/27/2017:33.
Re: New Zorro version 2.30
[Re: jcl]
#480962 07/27/2017:3507/27/2017:35
- Calling results() with +8: The bug was confirmed. It will be fixed in the next update. - No first and last bin in the plot.csv: Not confirmed. But it could depend on the script, can you post it? - Process.c does not work: Not confirmed. Can you contact Support? It can be some PC specific issue, so we'll need more details.
Re: New Zorro version 2.30
[Re: jcl]
#480989 07/29/2016:4607/29/2016:46
- No first and last bin in the plot.csv: Not confirmed. But it could depend on the script, can you post it?
Indeed, it only shows in some very special cases.
Code
#include <profile.c>
function run()
{
set(LOGFILE);
set(PEEK);
BarPeriod = 60;
StartDate = 2019;
EndDate = 2020;
if (true) {
var ibs=IBS();
var st = 0.05;
var Ret = (priceClose(-1)-priceClose(0));
var Bin = floor(ibs /st) ;
plotBar(Asset, Bin , st*(Bin),Ret,AVG+LINE+NEW,GREEN);//
}
else
plotDay(priceClose(0),0);
}
plotSeason and plotDay/Week/etc functions also have several bugs: one is that 'period one' at the start of a "season" is not counted/always zero.
Re: New Zorro version 2.30
[Re: jcl]
#480997 07/30/2016:2107/30/2016:21
80: Mon 19-01-07 13:00] 1.14407/1.14474\1.14368/1.14394 -0.0 Enter Long EUR/USD Entry 0.0023498 at 13:00:00 (EUR/USD::L) Long 1@1.14629 Entry stop <- initial entry stop from Entry=1.5*atr in tmf: 13:01:00, high = 1.14429, close = 1.14418 in tmf: 13:02:00, high = 1.14450, close = 1.14448 in tmf: 13:03:00, high = 1.14451, close = 1.14444 in tmf: 13:04:00, high = 1.14451, close = 1.14418 in tmf: 13:05:00, high = 1.14451, close = 1.14438 in tmf: 13:06:00, high = 1.14451, close = 1.14444 in tmf: 13:07:00, high = 1.14453, close = 1.14452 in tmf: 13:08:00, high = 1.14453, close = 1.14443 in tmf: 13:09:00, high = 1.14453, close = 1.14440 in tmf: 13:10:00, high = 1.14453, close = 1.14436 in tmf: 13:11:00, high = 1.14453, close = 1.14439 in tmf: 13:12:00, high = 1.14453, close = 1.14424 in tmf: 13:13:00, high = 1.14453, close = 1.14409 in tmf: 13:14:00, high = 1.14453, close = 1.14423 in tmf: 13:15:00, high = 1.14453, close = 1.14449 in tmf: 13:16:00, high = 1.14453, close = 1.14448 in tmf: 13:17:00, high = 1.14462, close = 1.14453 in tmf: 13:18:00, high = 1.14464, close = 1.14462 in tmf: 13:19:00, high = 1.14464, close = 1.14441 in tmf: 13:20:00, high = 1.14483, close = 1.14480 <--this is when a trade is entered by a tmf returning 2 ---- long Entry Stop is hit!----open=1.14394, high=1.14483 close=1.14480 entStp=1.14473 [EUR/USD::L08101] Long 1@1.14441 x at 13:20:00
The price of entry should be 1.14480 while Zorro's recorded price of entry is 1.14441 - a 4 PIP difference!
And no, it is NOT random. It is 1 tick earlier EACH TIME.
I discovered this when live trading results significantly deviated from a subsequent re-test (and backtesting expectations).
"Hopes" cost dearly. Just run the provided script and - 1.5 weeks since the report - you may as well provide a normal and constructive feedback...
Last edited by Zheka; 08/03/2012:58.
Re: New Zorro version 2.30
[Re: jcl]
#481046 08/03/2013:2808/03/2013:28
The first equity curve is from the provided script (entry from a tmf returning 2 as soon as price crosses 0.5*atr), second is the same script without using a tmf, just with Entry = 0.5*atr. Slippage=0 in both cases.
See the "inflation"?
The first approach should actually give worse results since price definitely has to cross the stop entry level (maybe by a lot) for an entry to trigger.
Re: New Zorro version 2.30
[Re: jcl]
#481048 08/03/2013:5908/03/2013:59
- Sometimes no first and last bin in the plot.csv of a histogram - Wrong plotHeatmap example in the manual - Wrong PriceDist script - Missing CuirrencyStrength script - enterTrade() did not update the LotsPool variable - Brute Force sometimes printed a wrong result to the window
Re: New Zorro version 2.30
[Re: jcl]
#481051 08/03/2014:2408/03/2014:24
This is the script used (same as in the very first message).
It's "inflated" equity curve is just an 'automated' way to show that 'peeking' is consistent; and the magnitude is clear by comparing to a benchmark (Entry=0.5*atr; enterLong(); ) where Entry prices are correct.
Re: New Zorro version 2.30
[Re: jcl]
#481057 08/04/2005:4408/04/2005:44
Ok, do I understand it right: The problem was not that the entry stop happened 1 tick early, the problem was that your TMF opened the trade 1 tick early?
Re: New Zorro version 2.30
[Re: jcl]
#481058 08/04/2010:0208/04/2010:02
When a price exceeds a certain level (0.5*atr), a trade is entered by the tmf returning 2.
However, Zorro internally records the entry price from 1 tick before the entry time.
Quote
in tmf: 13:18:00, high = 1.14464, close = 1.14462 in tmf: 13:19:00, high = 1.14464, close = 1.14441 in tmf: 13:20:00, high = 1.14483, close = 1.14480 <--this is when a price exceed 1.14473 and the trade is entered by tmf returning 2 ---- long Entry Stop is hit!----open=1.14394, high=1.14483 close=1.14480 entStp=1.14473 [EUR/USD::L08101] Long 1@1.14441 x at 13:20:00
Trade :L080101 is entered at 13:20 with the price at 13:19.
Re: New Zorro version 2.30
[Re: jcl]
#481059 08/04/2010:1408/04/2010:14
Ok. I assumed it was an entry stop issue. We cannot confirm a TMF fill price from 1 tick earlier either, so possibly something else is wrong. But I think at least I understand now the problem and we can check it. Sorry for being dull.
Re: New Zorro version 2.30
[Re: jcl]
#481060 08/04/2010:4208/04/2010:42
The script cannot be simpler, and the logs are what they are.
Quote
We cannot confirm a TMF entry price from 1 tick earlier either
I see 0 downloads of my script; so not sure what exactly has been used to confirm the problem. May I pls ask you to actually run the provided script and post the same part of the log that I posted, for 19-01-07 13:00?
Last edited by Zheka; 08/04/2010:47.
Re: New Zorro version 2.30
[Re: jcl]
#481061 08/04/2011:0508/04/2011:05
If the TMF is passed to an enter command, it can receive up to 8 additional var parameters following the function name: enterLong(MyTMF, parameter1, parameter2...). They must also appear in the function's parameter list and keep their values during the lifetime of the trade. The global manage function has no parameters.
Also, 2-minute difference is 0.00138888. If there is any rounding involved internally, downcasting a var to a float, this shouldn't cause difference up in the 3-rd significant digit.
Re: New Zorro version 2.30
[Re: jcl]
#481077 08/05/2015:4408/05/2015:44
It is about 44046 days since January 1, 1900, so your date value of 44046.00138888 vs 44046.00000000 requires more significant digits than you suggest.
Maybe your recast is incomplete in C++? Declare and initialize a float to the value, and use that instead. Then your floating precision should actually decay.
float is a 32 bit IEEE 754 single precision Floating Point Number (1 bit for the sign, 8 bits for the exponent, and 23* for the value), i.e. float has 7 decimal digits of precision.
double is a 64 bit IEEE 754 double precision Floating Point Number (1 bit for the sign, 11 bits for the exponent, and 52* bits for the value), i.e. double has 15 decimal digits of precision.
If I declare and initialize a var to a value, and then recast to float and back, I indeed see the difference. Why doesn't it happen if recasting the result of wdate()?
Re: New Zorro version 2.30
[Re: jcl]
#481085 08/05/2021:2808/05/2021:28
is the 2.30.3 release considered to update the running Z Strategies and their parameters?
If yes, the Z7 strategy has some new PDD algorithm, which behaves strange.
This algorithm has opened and saved into „trades.csv“ long and short trades at the same minute bar with the same asset. It happened several times during the back test.
Re: New Zorro version 2.30
[Re: jcl]
#481086 08/06/2008:0308/06/2008:03
-Z7 behaves strange: it now trades 2 PDD variants with different patterns. But they should normally not trade against each other. We'll look into that.
-Zheka's TMF entered at wrong price: Caused by setting an entry stop, but entering via TMF. Set TradeEntryLimit to 0 before returning 2. This will be fixed in the next update.
Re: New Zorro version 2.30
[Re: jcl]
#481096 08/06/2014:0908/06/2014:09
Caused by setting an entry stop, but entering via TMF
Its pretty normal to have some initial Entry, but modified later in a tmf. I actually needed a 'bracket' order, setting a limit via Entry and then adding a stop in a tmf. Which led to some 'great results' in backtesting, but failed in live. Would be great if Zorro had a bracket order functionality out of the box.
Quote
This will be fixed in the next update
You mean the entry price will be correct and not 1-tick earlier (without having to set TradeEntryLimit=0 before that)?
Last edited by Zheka; 08/06/2014:20.
Re: New Zorro version 2.30
[Re: jcl]
#481100 08/06/2016:1108/06/2016:11
Entering with initial Entry and modifying TradeEntryLimit in a tmf works exactly as suggested in the manual.
Quote
TradeEntryLimit Entry limit; initially calculated from Entry. The trade will be opened when the price reaches this value. Can be modified by the TMF by setting it to the desired price (not to a distance!).
So, you mean that this tmf functionality:
Quote
return 4: Don't use Entry, Stop, or TakeProfit for automatically entering or exiting. Exit or enter only when the TMF returns 1 or 2.
will work as expected i.e. entering a trade with "return 2" in a tmf will not conflict with a TradeEntryLimit set and will occur at the correct price?
Re: New Zorro version 2.30
[Re: jcl]
#481105 08/06/2017:4008/06/2017:40
-Z7 behaved strange on Sep 22 2011: No, that 's intentional. Look for the details in the log. "PD" opened a short position, and "PDD" immediately closed it and opened a long position. This happens very rarely, but it can happen. You can prevent shortlived positions when you set Hedge to 5.
Re: New Zorro version 2.30
[Re: jcl]
#481145 08/07/2013:2608/07/2013:26
Thank you JCL, I can not set Hedge 5, because the MT4 (or borker) does not support partial position closing. I have Hedge 4 though. Nevertheless, good that you checked, the short live positions do not bother me. I was afraid, there is some serious issue/mistake in the new release of Z7. Cheers, Jaroslav
Re: New Zorro version 2.30
[Re: jcl]
#481170 08/09/2018:5108/09/2018:51
That's true. The installation software knows the version number, but there's apparently no place where it is displayed.
The latest version, 2.30.5, contains a new MQL5 library that supports 64-bit order tickets. This supposedly fixes the longstanding problem of a certain broker whose MT5 order tickets exceed the int size.
Re: New Zorro version 2.30
[Re: jcl]
#481185 08/11/2015:4908/11/2015:49
Other appoitment for setup file. Is a possible update without data in history? I have verificate history data, but after update I must run verificate again.
Re: New Zorro version 2.30
[Re: jcl]
#481207 08/13/2011:0408/13/2011:04
-sftoa (1,1) returns "1.0": This is indeed a bug, and there are also other tiny inconsistencies with that function. It will be fixed, but not anymore for the current release, because the function is from a library and replacing it had side effects.
- plot(Name..) is unhappy when Name is not a string: lite-C functions indeed normally accept any 32-bit address for a string pointer. Same as above - it will be eventually fixed, but not anymore for the current release because this had to be done with most functions that use strings.
- update without data in history: EUR/USD data is included because the update is a normal installation. For avoiding that your history is overwritten, install it in a temporary folder, then copy over all folders except History.
Re: New Zorro version 2.30
[Re: jcl]
#481210 08/13/2011:2708/13/2011:27
That's right, but what you see in the performance report is just an approximation by subtracting 10,000 * years from the gross profit. For the decision whether to pay tax or not, you had to really calcculate it separately for any year. This is best done by script.
Re: New Zorro version 2.30
[Re: jcl]
#481232 08/14/2020:1108/14/2020:11
Unhappy plots -->> maybe should not change that, maybe just point it out in the manual, more efficient and may not break things people already developed.
Re: New Zorro version 2.30
[Re: jcl]
#481260 08/19/2011:4308/19/2011:43
I still have an older version of Zorro 2.20 which I have no problem testing the system on.
I have check several times that the data is available (downloaded the resent data from Zorro), that the asset list is correct and cant find any issues. Anyone else experiancing this?
Zorro S 2.30.7 (c) oP group Germany 2020 Zorro S Subscription
Z13 .x ..PH H 4 B 0 V 1 Error 055: No bars generated Error 047: No bars to plot
Re: New Zorro version 2.30
[Re: jcl]
#481262 08/19/2015:4208/19/2015:42
There is a bug in plot() when StartDate is set in the format YYYYMMDD.
This script:
Code
function run(){
set(PLOTNOW);
StartDate = 20190201;
EndDate = 2020;
BarPeriod = 60;
var K=ifelse(!(Bar%120),1,0);
plot("WHL",K,BARS+NEW,RED);
}
with StartDate=2019 plots as expected (screen 1) . But when StartDate is set as StartDate=20190201, plot() drops most items to be plotted (pic 2), even after enlargement of the plot area.
The problem can be reliably replicated for Bar%120 ( nothing is plotted), but is intermittent for lower values of the divisor (e.g. 24) (and can work for GBPUSD but not for EURUSD)
Last edited by Zheka; 08/19/2015:45.
Re: New Zorro version 2.30
[Re: jcl]
#481274 08/21/2009:5008/21/2009:50
- Backtesting Z13: Yes, a wrong history was loaded. You can either rename "SPYa.t8" to "SPYb.t8", or download 2.30 again. It now contains a Z13 with the correct history name. - Bug in plot when the StartDate is set in the format YYYYMMDD: If you cannot fix it, contact support. They'll help.
Re: New Zorro version 2.30
[Re: jcl]
#481277 08/21/2010:0508/21/2010:05
No, the issue is not obvious. I see nothing wrong at quick glance when I run your script. But if a plot does not look right, follow first the bug fixing instructions in the manual. In your case, that would be printing the plot values in the log and checking them against the plot, by zooming at a certain date if needed. If you cannot fix it this way, the final solution is getting a support ticket and asking my colleagues for help. That will always work.
If you contact support and it turns out that the issue is caused by something amiss in the manual or by a Zorro bug, we refund the support ticket of course. But I must tell that this does not happen often.
Re: New Zorro version 2.30
[Re: jcl]
#481280 08/21/2011:1208/21/2011:12
The script is 3 lines, and it does not plot as expected (at least on my end). Before posting here, I do the homework: the _plot.csv file contains all the correct values and zooming into an area reveals the correctly plotted values as well.
BUT the Total view doesn't show anything, as in the pic I attached.
Can you just spend 1 min and either confirm it or not?
Re: New Zorro version 2.30
[Re: jcl]
#481281 08/21/2011:3608/21/2011:36
No, I can not confirm it. You posted a trivial script that did not show me any bug or tell anything about that problem. Why must such an issue always cause discussions? You have a problem, you report it, I suggest that you contact the support - that's it. They can do a lot more than I, like checking your logs or your historical data or whatever might cause the problem. They will find it. If you do it or not is of course completely up to you.
Re: New Zorro version 2.30
[Re: Zheka]
#481286 08/22/2021:2208/22/2021:22
There is a bug in plot() when StartDate is set in the format YYYYMMDD.
This script:
Code
function run(){
set(PLOTNOW);
StartDate = 20190201;
EndDate = 2020;
BarPeriod = 60;
var K=ifelse(!(Bar%120),1,0);
plot("WHL",K,BARS+NEW,RED);
}
with StartDate=2019 plots as expected (screen 1) . But when StartDate is set as StartDate=20190201, plot() drops most items to be plotted (pic 2), even after enlargement of the plot area.
The problem can be reliably replicated for Bar%120 ( nothing is plotted), but is intermittent for lower values of the divisor (e.g. 24) (and can work for GBPUSD but not for EURUSD)
Fyi, above code seems to be working for me.
Re: New Zorro version 2.30
[Re: jcl]
#481288 08/23/2007:4608/23/2007:46
Hi, I found this in the document: "Multicore training is now possible with scripts located in the StrategyFolder given in Zorro.ini."
My strategy is in the StrategyFolder, but it seems not using more cpu resource(30-40%), which is the same with 2.25. What is the problem? My code is like this:
@jcl, maybe you already know these bugs of "Zorro 2.31.1": 1. "System State: 2020-06-24 12:23 - 22.56" never change or update; 2. It stoped trading once. (around 3 days in total);
Re: New Zorro version 2.30
[Re: Petra]
#481334 08/28/2009:5308/28/2009:53
Hi all, Modified the following lines in the ZorroFix file: HistoryFolder = "C:\Users\matteo.pedroni\OneDrive\Trading\Zorro\HistoryNew" // folder with the price history files StrategyFolder = "C:\Users\matteo.pedroni\OneDrive\Trading\Zorro\Strategy"
History and Strategy folders are correctly recognized, No mult-icore training with worshop 5 or 6.
Zorro S 2.30.7
Last edited by MatPed; 08/28/2010:38.
Re: New Zorro version 2.30
[Re: jcl]
#481365 09/02/2009:5809/02/2009:58
I have checked the Beta and multi-core training works, thank you. Unfortunately you can only include file with an absolute address i.e "c:\..." you can not include file even in the same strategy directory.
Thank You
Re: New Zorro version 2.30
[Re: jcl]
#481478 09/19/2008:2509/19/2008:25
I have checked the Beta and multi-core training works, thank you. Unfortunately you can only include file with an absolute address i.e "c:\..." you can not include file even in the same strategy directory.
Thank You
In v2.32.9b including file with relative file address (i.e. #include "ReR\test.c" where ReR is a subdirectoty of the StrategyFolder defined in the ZorroFix file) still does not works
Are you planning to fix it or the function is intended to work as it is?
Thank You
Re: New Zorro version 2.30
[Re: jcl]
#481684 10/19/2012:5110/19/2012:51