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
Same as "int intCheck" but assigned value before the function, like other vars.
So this will work ?
So this will work ?
Of course NO, it is only for simple calculations for market parices or similar with less digits. Nothing will work if more than 10 digits counted on both sides of decimal dot together, limits. Just toy.
Don't over complicate things
Whether something (or some idea) is complicated or complex is, I believe, a matter of individual interpretation.
A floating divide, floating addition, conversion to int, function call (copy, jump, return = 3,) * 2 all times two. (18) And that's assuming divide and convert are on par with the other operations - they are not.
I never meant to suggest that the solution that I created and use is the most efficient--I realize it may not be. But, the important thing is (1) I understand (and, at this time, can tolerate) its additional overhead and computational cost and (2) it solves the problem (at least for me) of comparing two prices that are in double precision floating-point format.
Ultimately, I understand the problem inherent in comparing for equality two real numbers that are in a double precision floating-point format, but I think you and I have approached the problem in a slightly different way in this context. You use what I might call an "epsilon comparison" to determine if two doubles are close enough to be understood as being equal--that is, if the difference between two doubles is within your max deviation (Point / 2.), then the two doubles are equal. On the other hand, I choose to turn the prices into ints for comparison by dividing by Point, round to the nearest whole number, save the result as an int, and then compare the two ints. I used a function call, rather than inline code, because it is more natural for me--I tend to group code into subroutines/functions--and because it is potentially reusable (maybe from that small part of me that thinks in OOP terms). I took much from what you said on Feb. 16, 2012:
The double value from the broker could be anywhere from 1.234575000000000000 through 1.23458499999999999 and still be considered the same 1.23458 price.
That is why I decided to round to the nearest whole number instead of truncate the decimal portion after dividing by Point but before converting the double to an int.
All of this is not to say that I disagree with what you have posted. Rather, it is an acknowledgment that I have reviewed what you have posted and will save it for future reference (and for potential use later on, if needed). :)
As always, instructive/constructive comments are welcome. :)
Whether something (or some idea) is complicated or complex is, I believe, a matter of individual interpretation.
I never meant to suggest that the solution that I created and use is the most efficient--I realize it may not be. But, the important thing is (1) I understand (and, at this time, can tolerate) its additional overhead and computational cost and (2) it solves the problem (at least for me) of comparing two prices that are in double precision floating-point format.
I agree with you . . . and I also agree with WHRoeder
My code was written with a need for something to plug into existing code without breaking it or having to spend many hours bug finding, so it achieved it's aim. I would also like to take on board what WHRoeder has posted at least partly and come up with better version of what I am doing whilst keeping it still readable for my use. If I manage any of this I'l post it in this thread.
If I manage any of this I'l post it in this thread.
My Flat() function was 17 times slower than WHRoeder's solution, I have a proposal which I think is more readable and only 3 or 4 times slower, depending on the comparison type. 3 or 4 times slower is not a great thing to achieve but compared to 17 times slower is a big improvement. I've tested it a little, not extensively yet.
Usage:
The comparison types are , EQ for equal, NEQ for not equal, GT for greater than and LT for less than.
Simply your bools
Good point.
The performance hasn't significantly changed.
Precedence rules Not (!) is almost the highest: when first != second exactly, (!ABS(non-zero) > nz) == (0 > nz) == false. If f==s then (!0 > nz) == (1 > p/2) == true if point < 1
Yes, good catch . . .