通用类库 - 错误、说明、问题、使用功能和建议 - 页 4

新评论
 
瓦西里-索科洛夫。

你没有弄清楚背景。如果你在不同的主题中到处宣扬没有证据的胡言乱语，那么是的，这就直接导致了禁令的产生。如果你愿意用源代码来支持你的主张，欢迎你。这就是为什么弗拉基米尔给你一个警告，因为他自己喜欢源代码，有时甚至要求它。翻开他自己的线程就可以看到一个例子。


很对。如果你得到彼得的代码，比较其性能将是非常好的。

 
瓦西里-索科洛夫。
我已经看过了。一切都写得很正确。正如已经告诉你的那样，字典中的元素搜索是在平均时间O(1)内完成的，也就是说，是即时的。

这就是听起来不合逻辑的地方。在成千上万的订单中，最多需要10次检查。但肯定不是平均的。平均搜索时间总是与项目的数量有关。

 
组合器。

不，在非常罕见的情况下，由于哈希碰撞而获得O(n)。这些是最佳算法的复杂度估计。碰撞的数量与内存开销有关

在通常情况下，基本上不需要搜索，因为通过计算哈希值，我们已经知道我们需要的项目的位置。


在我的印象中，哈希字典大小的最佳选择是预期元素数量的平方。
碰撞的一个明显例子是生日悖论。

https://ru.wikipedia.org/wiki/

 
组合器。

在正常情况下，基本上没有必要进行搜索，因为 通过计算哈希值，我们基本上已经知道了有关项目的位置。

这听起来并不靠谱。但我要等着看例子，然后再看实施的内幕。

 
谢尔盖-迪尤布利 克。

一方面，这很酷，另一方面，我们记得MQL有很多东西是其他语言所没有的：既没有多重继承，也没有foreach，yeild return，lamb，......。
很明显，IEnumerable是不可能的。

那么我们如何在没有IEnumerable的情况下处理C#容器呢？
我们仍然有旧的C++算法，并使用接口而不是函数的指针。

最后，我们得到了一个C#和C++的大杂烩。

名称的大杂烩正是因为有了不正确的名称而使事情变得混乱。

如果他们是C++，一切都会很清楚。


PS 为什么没有这种多重继承？ 我不能在mql5中这样写吗？

class A : public B
  {
  }

据我所知，这是没有问题的。


这就是为什么我们最终要用C/C++。如果我们做出正常的名字。:)

 
弗拉基米尔-卡尔普托夫。

完全正确。如果有彼得的代码，比较一下性能就会非常好。

我总是愿意用代码语言交谈。作者可以简单地给我提供一个证明，我就会直接进入主题。

让作者提供任务，我们将按效率比较我们的解决方案。

 

该主题是固定的。你可以这样看待它。

第1步：点击 "一般讨论"

你可以立即看到该主题被钉住了。

第2步：查看主题是否固定

 
fxsaber:

这听起来并不靠谱。但我要等着看例子，然后再看实施的内幕。


如果字典的大小与预期元素的数量允许，哈希值平均为O(1)。
然后它取决于碰撞处理的实现，它可以通过一个列表，也可以是一个子hedge....。


 
谢尔盖-迪尤布利 克。

碰撞的一个典型例子是生日悖论。

我是在维基上读到的。当你完全不理解直觉推理的逻辑时的情况。

 
弗拉基米尔-卡尔普托夫。

该主题是固定的。你可以这样看待它。

并且你可以立即看到该主题被钉住了。

谢谢你。我们将努力使这个主题变得有趣。我已经看到了对该主题的需求:))

1234567891011...38
新评论