Hi,
I have the following simple code:
Code is compiled as a library function and when called from a script midpoint prints 1.#INF which is probably infinity.
I tried to print close[1], open[1] and open[1]+close[1] separately and they look fine:
Test (USDJPY,M5) open[1]: 90.731
Test (USDJPY,M5) close[1]: 90.79300000000001
Test (USDJPY,M5) close[1]+open[1]: 181.524
Test (USDJPY,M5) midpoint: 1.#INF
close[1] value looks a little strange (maybe because I didn't use NormalizeDouble()) but seems that the division by 2.0 fails.
Anybody knows anything?
Your code should work as long as shift is set to a reasonable number, although there should be no need to resize the arrays before use, and you use strange names for the results of CopyOpen and CopyClose. They return the number of copied elements, not a handle, and it would be wise to test that they do in fact return 2 elements as requested.
if (CopyOpen(_Symbol,_Period,shift,2,open)!=2 || CopyClose(_Symbol,_Period,shift,2,close)!=2) { Print("Failed to read data"); }
Paul
Your code should work as long as shift is set to a reasonable number, although there should be no need to resize the arrays before use, and you use strange names for the results of CopyOpen and CopyClose. They return the number of copied elements, not a handle, and it would be wise to test that they do in fact return 2 elements as requested.
Paul
Thanks Paul, you're right about the return values. The same code works after installing the last update.
Btw, I still get results like 90.79300000000001 occasionally even when use NormalizeDouble() but so far no problems with that.
Thanks Paul, you're right about the return values. The same code works after installing the last update.
Btw, I still get results like 90.79300000000001 occasionally even when use NormalizeDouble() but so far no problems with that.
That's interesting information about NormalizeDouble - I wonder if it's a bug.
But in any case, I usually convert price comparisons to integer as follows
if (MathRound((price-stoploss)/_Point)<=0) { // ... } // this can produce inaccurate results due to internal representation of doubles if(price<=stoploss) { // ... }
Paul
That's interesting information about NormalizeDouble - I wonder if it's a bug.
But in any case, I usually convert price comparisons to integer as follows
Paul
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hi,
I have the following simple code:
Code is compiled as a library function and when called from a script midpoint prints 1.#INF which is probably infinity.
I tried to print close[1], open[1] and open[1]+close[1] separately and they look fine:
Test (USDJPY,M5) open[1]: 90.731
Test (USDJPY,M5) close[1]: 90.79300000000001
Test (USDJPY,M5) close[1]+open[1]: 181.524
Test (USDJPY,M5) midpoint: 1.#INF
close[1] value looks a little strange (maybe because I didn't use NormalizeDouble()) but seems that the division by 2.0 fails.
Anybody knows anything?