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
Not sure why you are quoting me. The thread is about comparison of double precision numbers.
Why didn't you give example with
For example, the average value (Moving Average) and the Open value of the Bar.
like the OP posted ??
Your example is something different with that example
the first tick of each new bar start with High[0] == Open[0] && Close[0] == Open[0] ....
Why didn't you give example with
For example, the average value (Moving Average) and the Open value of the Bar.
like the OP posted ??
Your example is something different with that example
the first tick of each new bar start with High[0] == Open[0] && Close[0] == Open[0] ....
What example did you mean? I do not care if moving average could ever match whatever. I stated that comparing doubles worked with quotes from broker, but might fail if calculation was involved. I am not gonna provide any example nor prove.
Yes there is . . . read and understand this ? Can price != price ?
First, thanks guy. A newbie like me really appreciated your help. yes I did read it Raptor ^^. But you said it yourself: "Any price that comes from Predefined Variables or timeseries functions will never need to be Normalized, neither will the result of an integer multiplied by Point." In this case, those High[], Low[], Open[] are all predefined variables, are they not? They should be already at the correct precision. We only need to normalize a double when we do some messy calculation like " High[1] * 0.919193 - Open[1]". I think the reason is like GumRai said,
If the last tick of the old bar comes in and the next tick comes very quickly, your expert may miss the first tick of the new bar and only calculate on the second. Especially if latency is poor. That is why indicators usually recount 2 bars.
First, thanks guy. A newbie like me really appreciated your help. yes I did read it Raptor ^^. But you said it yourself: "Any price that comes from Predefined Variables or timeseries functions will never need to be Normalized, neither will the result of an integer multiplied by Point." In this case, those High[], Low[], Open[] are all predefined variables, are they not? They should be already at the correct precision. We only need to normalize a double when we do some messy calculation like " High[1] * 0.919193 - Open[1]". I think the reason is like GumRai said,
if you do it like this, it will work every time open is supposed to equal close unless a tick is missed.
if you do it like this, it will work every time open is supposed to equal close unless a tick is missed.
can we just round the price to eight decimal place by
The number after the 8th decimal place is very small anyway. They don't matter much, so can we just ignore them?
Is that guaranteed ? isn't it possible that Open[0] might be 0.000000000001 under the displayed value while Close[0] is 0.00000000001 over the displayed value, one will be rounded up the other down.
Your scenario requires Open[0] = 1.2344999999999999 while the displayed value is 1.2345 I didnt think that was even possible have you ever heard of that happening ?
I decided this is time for a scientific test :)
We know if a price is 1.2344999999999999 and we convert it to integer ( int = price/Point) the integer value would be 12344
if we NormalizeDouble() that same price it would be 1.2345 convert that Normalized double to integer ( int = price/Point) is integer value 12345
that allows for a direct if int == int comparison test, if there really are price doubles that would give an incorrect integer value by direct conversion because they are so slightly under the actual price, this indicator will find them.
Script to test all the prices on the chart.
Output:
EURUSD,M1: Alert: 263452 prices checked
EURUSD,M1: Alert: 228388 prices passed test
EURUSD,M1: Alert: 35064 prices failed test
So Raptor is right, the scenario where a price double can be slightly less than the displayed price does happen, and it happens a lot. Converting them directly to integers would round them down to the wrong value. I didn't think that would actually happen at all, I'm suprised how often that happened.
I decided to mathround the prices to round out those offending decimal places so I modified the test script:
output:
EURUSD,M1: Alert: 263452 prices checked
EURUSD,M1: Alert: 263452 prices passed test
EURUSD,M1: Alert: 0 prices failed test
so it appears it is accurate to do