Generic Class Library - bugs, description, questions, usage and suggestions - page 4
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
You're not getting the context. If you go around in different threads and assert nonsense without evidence, then yes, this is a straight road to the ban. If you are willing to back up your claims with source code, you are welcome. That is why Vladimir warned you, because he himself loves the source code and sometimes even requires it. Look at his own branches for an example.
Quite right. If you'll have Peter's code it will be very nice to compare productivity.
I took a look. Everything is written correctly. You're told that the search of an element in the dictionary is carried out in average time O(1), ie instantaneously.
This is what sounds counterintuitive. Among thousands of orders, you need at most 10 checks. But certainly not one on average. There is always a dependence of average search time on the number of elements.
No. O(n) is obtained due to hash collisions in very rare cases. These complexity estimates are for the optimal algorithm. The number of collisions is related to the memory overhead
In the normal case there is essentially no need to search, because having calculated the hash we essentially already know the location of the desired element
As far as I remember, the optimal choice of hash dictionary size is the number of expected elements squared.
A good example of collisions is the paradox of birthdays.
https://ru.wikipedia.org/wiki/
In the usual case there is essentially no need to search, because by calculating the hash we essentially already know the location of the desired element
That doesn't sound plausible. But I'll wait for examples, then I'll see the guts of the implementation.
On the one hand it is cool, but on the other hand we remember that MQL has a lot of things, which are absent in comparison with other languages: neither multiple inheritance, foreach, yeild return, lamb, ...
Obviously IEnumerable is out of the question.
How to handle C# containers without IEnumerable?
We still have the old C++ algorithms and use interfaces instead of pointers to functions.
In the end we have a mixture of C# and C++.
Solyanka just arose because of the incorrect names that confuse everything.
If they were shod under C++, everything would be clear.
PS And why this multiple inheritance is absent? Can't I write it so in mql5?
As far as I understand, it's no problem.
That's why you end up with C/C++. If we make normal names. :)
Exactly right. If there is a code from Peter, it will be very nice to compare the performance.
I'm always ready to talk in code language. The author could simply offer me a proof and I would get right to the point.
Let the author provide the problem and we will compare our solutions by efficiency.
The topic is fixed. You can see it this way:
and you can see right away that the topic is pinned:
That doesn't sound plausible. But I'll wait for examples, then I'll see the guts of the implementation.
Hashes average O(1) if the dictionary size to the number of expected elements allows.
And then it depends on collision handling implementations, it could be through a list, it could also be a sub-hedge....
A prime example of collision is the birthday paradox.
I read it on the wiki. The case when you don't understand the logic of intuitive reasoning at all.
The topic is fixed. You can see it this way:
and you can see right away that the topic is pinned:
Thank you. We will try to make this thread interesting. I already see the demand for the topic:))