文章 "通用EA交易: CUnIndicator 和挂单的使用(第9部分)" - 页 2

新评论
 

您好！

我刚刚开始学习 UnExpert。一切都很顺利，直到今天，我突然发现在各种库文件 Message、Dictionary、Sessioninfo 和其他文件中出现了错误。会发生什么情况？一般来说，这个库受支持吗？

 
Titika:

我刚开始学习 UnExpert。一切都很顺利，直到今天，我突然发现各种库文件 Message、Dictionary、Sessioninfo 和其他文件都出现了错误。会发生什么事呢？

语言发生了变化，不再允许某些自由了。这很容易解决。

 
fxsaber:

这是语言的变化，不再允许某些自由。这很容易解决。

我看了看我的代码，大吃一惊。有些方法没有指定返回类型。奇怪的是，之前编译过。

 
Vasiliy Sokolov:

我看了看自己的代码，大吃一惊。有些方法没有指定返回类型。奇怪的是，之前编译过。

不知何故，即使在最近的一篇文章中也变成了这样。

在ZIP 库中，如果没记错的话，以前也有同样的情况，而且还起了作用。

 

今天，我在 Universal Engine 的基础上编写了我的第一个智能交易系统。在此，我想向作者说声 "你好"，并对他的工作表示感谢。

我只用了一天的时间就写完了智能交易系统，同时也基本理解了主要的类和函数。现在我申请将其放在 CodeBase 中，但我不确定它是否会被允许，因为如果没有 Universal Engine 的主库，它就无法通过最后的可编译性测试。我给 moderatotram 写了信，也许他们会让它通过。

它让我想起了 StockSharp 平台上的 S#.Shell 库，但该项目更高效、更优化。

一些小建议

1.CTrailingMoving 类也应改用 CUnIndicator，因为它已被引入。

2.2. CTrailingClassic 类的 Modify() 方法确实工作不正确，这在文章 "通用交易智能交易系统：使用自定义追踪止损（第 6 部分）（链接）"的讨论中已经注意到，但并未得到修正。

正确的方法终止应包括检查是否超出 m_step_modify 值：

   if(m_position.Direction()==POSITION_TYPE_BUY)
      {
         n_sl=extremum-m_diff_extremum;
         if(n_sl-m_position.StopLossValue()>m_step_modify) return m_position.StopLossValue(n_sl);
      }
   else
      {
         n_sl=extremum+m_diff_extremum;
         if(m_position.StopLossValue()-n_sl>m_step_modify) return m_position.StopLossValue(n_sl);
      }

3.止损应立即设置，而不是在 SupportBuy/SupportSell 中设置，例如，如果 Expert Advisor 计划在 M15 日工作，那么该仓位将在 15 分钟内不设置止损，这是不可取的。

在当前版本的通用引擎中，有两种方法可以实现这一点：

a) 将 CStrategy 类的 RebuildPositions 方法设为公共方法、

c) 将 M1 TF 设为工作 TF，所有使用指标的所有 TF 都应与智能交易系统的 TF 取消链接。

但这些都是小事。

总的来说

我希望作者能继续开发通用引擎，尤其是考虑到社区的要求。

已经一年没有更新了。阿尔乔姆-特里什金（Artyom Trishkin ）已经就替代通用库的主题撰写了文章，但即使到现在，它仍然没有达到通用引擎的水平--它只是一个可怜的模拟库，甚至没有涵盖最新版 UD 中实现的 1/3 的功能（我不认为其库与 MT4 的完全兼容是一个优点--没有人真正需要它了）。

 
Sergey Lebedev:
...

一年来没有一次更新。阿尔乔姆-特里什金（Artyom Trishkin ）已经写过关于替代通用库的文章，但即使到现在，它也没有达到通用引擎的水平--它只是一个可怜的模拟库，甚至连最新版 UD 实现的功能的 1/3 都没有涵盖（我认为它的库与 MT4 完全兼容完全不是一个优点--没有人真正需要它了）。

这个 "某个人 "的任务与 "马上、现在 "的任务有些不同，他要为每个人提供一个轻松编写程序的工具。该项目正在发展中，而这只是其中的十分之一。因此，不要以它的雏形来评判它--现在还为时过早--它还没有诞生。

 
我相信，在 80 篇文章之后，您的项目 将大大超过通用引擎项目，但本周末当我比较这两个项目时，我选择了通用引擎，而您的项目仍处于需要很长时间才能赶上的阶段。
有竞争力的通用平台的存在是好事，因为它们是由社区同时开发的，而不是在作者对项目失去兴趣后才冻结的。毕竟，你做了 100 多篇文章也会停止支持你的项目????。兴趣不可能一直保持下去！在你之后，会有另一个通用者带着他自己对通用图书馆的独特见解和 200 多篇文章的计划?????。
因此，我建议你想一想，最终用户为什么需要这些类库，你为什么需要从头开始编写一切，而不是在开始工作时就开发通用引擎，并创建 19-20 个新的改进/类？
 
Sergey Lebedev:
我相信，在 80 篇文章之后，您的项目将大大超过通用引擎项目，但本周末当我比较这两个项目时，我选择了通用引擎，而您的项目仍处于需要很长时间才能赶上的阶段。
有竞争力的通用平台的存在是好事，因为它们是由社区同时开发的，而不是在作者对项目失去兴趣后才冻结的。毕竟，你做了 100 多篇文章也会停止支持你的项目????。兴趣不可能一直保持下去！在你之后，会有另一个对通用图书馆有自己独特见解的通用者，并有一个 200 多篇文章的计划?????。
因此，我建议你想一想最终用户为什么需要这些类库，以及你为什么需要从头开始编写一切，而不是开发你开始工作时创建的通用引擎，并创建 19-20 个新的改进/类？

你是否赞成每个人都开一个品牌的汽车，坐一个品牌的飞机，等等等等？?

是的，我并不是要 "追赶超越"，把一切都植入玉米....。我在做自己的项目。

当然，我对选择瓦西里的作品并不感到意外--它已经完成，而我的图书馆才刚刚创建。你有点误解了我文章的含义和本质--它们描述的是创建一个库的过程，而不是使用一个已经完成的库的过程。那些想深入开发并了解原理的人--他们会这样做，并提出问题、澄清和学习。有人立即理解了那里所写的内容，并跟踪了开发过程。但这里不是讨论这个问题的地方--这里是讨论瓦西里作品的地方。

你怎么会认为，我已经开始了一项巨大的工作，会在一夜之间放弃它呢？当然不会。它还有很大的发展潜力。

 
Sergey Lebedev:

...

全球

我希望作者能继续努力开发环球引擎，特别是因为社区提出了一些要求。

已经一年没有更新了。有人阿尔乔姆-特里什金（Artyom Trishkin ）已经就替代通用库的主题撰写了文章，但即使到现在，它仍然没有达到通用引擎的水平--它只是一个可怜的模拟库，甚至没有涵盖最新版 UD 中实现的功能的 1/3（我认为其库与 MT4 的完全兼容完全不是一个优点--没有人真正需要它了）。

再见。感谢您的反馈。将 UTE 代码放在公共版本控制系统（Git 或 MT）中似乎是最佳选择。在这种情况下，用户可以在我审核代码后修改错误并对代码进行额外的修改/改进。我认为这样的项目开发系统对开源来说是最佳选择，因为没有人能独自承担一切。

至于 UTE 本身，我认为其主要功能已经形成。它涵盖了大部分最常见的交易功能。因此，UTE 沿着同一方向发展不会带来根本性的新东西。但是，数据工作的功能框架可以从整体上推动 UTE 的发展。我们的想法是，以对象风格处理系统结构，以功能风格处理集合（包括系统集合）。在这种情况下，系统数据类型和用户数据类型之间的明显区别将被消除，处理数据的查询将由用户自己 "即时 "创建（类似于 C# 中的 LINQ）。遗憾的是，由于语言限制，无法在一二基础上编写这种框架，因此这还只是一个想法。

 

今天来看看更新，首先我想说声谢谢。两年前，我纠正了几个不准确的地方，但一直以来我都在使用相同的 EA 结构，没有考虑过绑定问题。有时我会忘记这是您开发的，而不是 MT 标准。

如果可以开发和放置库，我将用我所有的肢体投票支持（我已经满足了自己的需求，但往往不是最理想的，我也满足了其他作者的解决方案）。作为一个开发平台，甚至是开发中的正确信息。如果您决定这样做，请在讨论中写下网站地址。

在此先表示感谢...

1234
新评论