Generic Class Library - bugs, description, questions, usage and suggestions - page 17
![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Great theoretical example! In practice, has anyone ever operated thousands of transactions?
p.s. I'm not trying to prove that it's crap and nobody needs it. I'm trying to understand the value for real trading. I'm not a theorist in general, but a pure practitioner.
Briefly about the current implementation ofCHashMap:
First we need to find out whatEntry<TKey,TValue> is.
Basically it's a Node like in CLinkedList, which contains:
m_entries[] - array of "cells" where added key and value, hash_code, next are placed. The size of the array corresponds to Capacity.
m_count - specifies the index of the first unused cell in m_entries. Initial value is 0, growing to Capacity, next is rebuilding all arrays with increasing Capacity and size of all arrays.
m_buckets[] - index array on m_entries[]. The default value is -1. Array size corresponds to Capacity.
Without collisions, adding a unique value in theCHashMap container:
Without collisions, get value by key inCHashMap container:
Collision resolving:
Collision, getting value by key inCHashMap container:
Deleting the value from theCHashMap container:
Rebuild hash table (process of increasing Capacity) :
Forum on trading, automated trading systems and strategy testing
Generic Class Library - bugs, description, questions, usage and suggestions
Sergey Dzyublik, 2017.12.09 01:12
Got acquainted withCHashMap implementation
Honestly, I liked it.
There are several suggestions for possible improvement:
1) In my humble opinion, the implementation contains not quite correct choice of capacity - both initial size 3 and subsequent ones when rebuilding the hash table.
Yes, it is true that you need to choose a prime number for uniformity of distribution.
However, the CPrimeGenerator implementation does not meet expectations and contains omissions of prime numbers.
The purpose of such a "generator" is clear - to provide an increment factor of the order of 1.2 with automatic generation of prime numbers.
However, isn't this too small a coefficient? In C++ for vectors, the coefficient is usually 1.5-2.0, depending on the library (because it strongly affects the average complexity of the operation).
The way out could be a constant coefficient followed by rounding the number to prime via a binary search of a list of prime numbers.
And an initial size of 3 is way too small, we don't live in the last century.
2) Hash table rebuilding (Resize) is currently performed only when 100% capacity is filled (all m_entries[] are filled).
In this regard, there may be a significant number of collisions for keys with not very evenly distributed.
As an option, consider introducing a fill factor that reduces 100% by the necessary limit to perform hash table rebuilding.
In practice, has anyone ever operated thousands of transactions?
Yes, millions of references to history on one pass is practiced by many.
On Forts every first.
It's clear.
Sending orders by hft algorithm and raising them later for analysis are different things. These hashes are not needed for sending, and they are not needed for analysis, since we analyze something else entirely.
So, no offense. You also need theory.
It's clear.
Sending orders by hft algorithm and raising them later for analysis are different things. These hashes are not needed for sending, and they are not needed for analysis either, since they are analyzed for something else entirely.
So, no offense. We also need theory.
I do not use dishwasher, I use sponge.
No offense meant. Dishwashers are lame, what are they for.
It's clear.
Sending orders by hft algorithm and raising them later for analysis are different things. You don't need these hashes to submit them and you don't need them to analyze them, since you will analyze something else entirely.
So, no offense. We also need theory.
What grudges? Keep writing your crutches.
Briefly about the current implementation ofCHashMap
Thank you, I will use when parsing the source code.
What grudges? Keep writing your crutches.
Thank you, I will use when parsing the sources.
Omitted checking for existence of key in container when adding new key-value pair, executed first.
But it is not important.
Please fix something like this throughout Generic.