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
This way you don't need to save (to hash) two numbers for x and y but only one. So one(!) number identifies a single point in an two dimensional space. Kind of 'Gödelisierung' of the coordinates.
This way you don't need to save (to hash) two numbers for x and y but only one. So one(!) number identifies a single point in an two dimensional space. Kind of 'Gödelisierung' of the coordinates.
For triangles for instance, does it need to return only from the borders or also from within?
That is a smart simplification. Now I understand what you are thinking about...
But you have to check it. If the divisions of a ulong are performed by a cast to an double value you might get a wrong number.
I once tried to assign Chart-IDs (type long) to the global values (type double) of the terminal (only double) I didn't get back the correct ID number - this works only for smaller numbers :(
if the coordinates are limited like 0-1000 for both for a hash you can squeeze them together into one new number = x + 1000*y. Then x= number%1000 and y= number/1000 (one need to check the rounding of big numbers)? max of ulong (18 446 744 073 709 551 615) has 20 digits so this would work up to 8 digits (99 999 999) for each coordinate?
I think this code improves your idea by avoiding the numeric type limits of the coordinates:
This equivalent to: number = x + 4294967296*y
One problem is that it hashes the "exact" coordinates. To hash the "nearest bounding rectangle", we can approximate the price and time inputs (as before) before combining the two 32-bit hash values.
Compared to using concatenated string keys directly as before #16, the above code does not provide any extra advantage (except that it might be a bit faster), because the CHashMap class eventually hashes the "composite" string key "price"+"time" to a single number.
Edit:
Hash collisions is not a problem here, because CHashMap class has a built in mechanism for resolving hash collisions (Separate chaining technique). Many hash collisions will just slow down the search, but the accuracy is not affected.
What about converting the double prices into integer by:
and as this range is for sure less than 0 - 99 999 999 one can reduce this range to enlarge the 'other side' = dateteime.
There you for sure don't nee the seconds from 1970 subtract
sTme[i] = time[i] - D'2000.01.01. 00:00:00';
As I think the %-operation is less critical concerning an internal cast when divided I would put the 'longer' number (time) at the right end of the combined number and the smaller range on the left end of the number - there is no need that both numbers have to have the same size on both sides.
I think this code improves your idea by avoiding the numeric type limits of the coordinates:
This equivalent to: number = x + 4294967296*y
One problem is that it hashes the "exact" coordinates. To hash the "nearest bounding rectangle", we can approximate the price and time inputs (as before) before combining the two 32-bit hash values.
Compared to using concatenated string keys directly as before #16, the above code does not provide any extra advantage (except that it might be a bit faster), because the CHashMap class eventually hashes the "composite" string key "price"+"time" to a single number.
Edit:
Hash collisions is not a problem here, because CHashMap class has a built in mechanism for resolving hash collisions (Separate chaining technique). Many hash collisions will just slow down the search, but the accuracy is not affected.