prev_calculated - page 10
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
It doesn't. There will be a connection break of several bars, several bars will be uninitialized with rubbish.
Either, as Dmitry said above, there was a connection break of several bars... By the way, will prev_calculated return 0 too in case of a connection failure?
Apparently there was indeed a break in communication at this time.
2016.10.19 04:45:37.260 Network '4092672': scanning network for access points
2016.10.19 04:45:36.630 Network '4092672': trading has been enabled - hedging mode
2016.10.19 04:45:36.630 Network '4092672': terminal synchronized with MetaQuotes Software Corp.
2016.10.19 04:45:36.000 Network '4092672': previous successful authorization performed from 31.173.80.3 on 2016.10.18 17:51:14
2016.10.19 04:45:36.000 Network '4092672': authorized on MetaQuotes-Demo through Access Point SG Singapore (ping: 583.86 ms)
2016.10.19 04:42:57.680 Network '4092672': connection to MetaQuotes-Demo lost
And it is most likely that when there is a break, prev_calculated returns 0.
OK, it was a long break, but what caused the other prev_calculated nulls?
From these lines.
2016.10.18 23:51:20.865 Network '4092672': scanning network for access points
Up to those above there are no other records other than trade records like this one.
And you can see how many zeroing of prev_calculated was in my previous post.
Potentially, the fault could be here:
{
minEquity = 0;
maxEquity = 0;
}
minEquity = NormalizeDouble(fmin((minEquity == 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
When a new bar arrives, you reset the values to 0 - fine. But then you check minEquity and 0 for equality, which is not recommended.
To prove my words, here is your image. You can see that the "rubbish" values, as you said, are about zero.
Of course, you'd better add a data window in the picture with the "trash" value.Can you elaborate on why this method is not recommended?
This (minEquity == 0? bal : minEquity) part of the code, if minEquity == 0, will return the value of bal which was obtained earlier; the value of minEquity will not change until the function fmin() terminates.
Although I agree that such writing is a bit risky... but that's not the problem.
Can you explain in more detail why this method is not recommended?
this (minEquity == 0? bal : minEquity) part of the code, if minEquity == 0, will return the value of bal obtained earlier; the value of minEquity will not change until the function fmin() terminates
Although I agree that this way of writing the code is a bit risky... but that's not the problem.
I was talking specifically about this: minEquity ==0. You're comparing on the equality of the dabble numbers. That might explain the drop in values to 0.
I see, the correct answer is minEquity ==0.0 ... I can't get used to it.
And the last sentence I don't understand at all. What values to 0?
I see, the correct answer is minEquity ==0.0 ... I can't get used to it.
And the last sentence I don't understand at all. What values to 0?
But I don't know if an implicit type conversion might cause an error. I was speaking generally about comparing real types. I.e. here, to be safe, I would write it this way:
bool CompareDoubles(double number1,double number2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
However, I do not know if implicit type conversion may cause an error, I was speaking, in principle, about comparing real types. I.e. here, for reliability, I would write it like this:
bool CompareDoubles(double number1,double number2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true);
else return(false);
}
Yes, my version counts money with two decimal places. This is not a quotation, so you can't be so precise about it.
It's not a matter of meticulousness, it's a matter of accuracy. In your case, it could result in a zero value being written to the buffer. If you don't want such precision, do it this way:
{
minEquity = -1.0;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin((minEquity < 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Then there will be no error.
It's not a matter of meticulousness, it's a matter of accuracy. In your case, it could result in a zero value being written to the buffer. If you don't want that precision, do it this way:
{
minEquity = -1.0;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin((minEquity < 0 ? bal : minEquity), equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
There will be no error in that case.
Why am I so stupid? How could I have not guessed that it's better to initialize minEquity with a non-zero value? Then everything will be easier...
{
minEquity = DBL_MAX;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin(minEquity, equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
You may also use maxEquity = DBL_MIN;
Why am I so stupid? How could I have not guessed that it's better to initialize minEquity with a non-zero value? Then everything would be easier...
{
minEquity = DBL_MAX;
maxEquity = 0.0;
}
minEquity = NormalizeDouble(fmin(minEquity, equity), 2);
maxEquity = NormalizeDouble(fmax(maxEquity, equity), 2);
Well... Or so...