我的方法。核心是引擎。 - 页 23

新评论
 
Реter Konow:

当然没有问题。如 果没有算法本身，也不会有问题。而互联网和社交媒体...

所有这些都是臆造出来的实体，创造了新的解决方案和新的问题。没有人禁止创造新的利基、发明。

人们习惯了它们，然后没有它们就无法生活。生活中就是这样的）。


阿尔戈特交易的问题，以及任何利基的问题，都是发展。没有它，神龛的存在是注定的。问题是--我们需要在哪里发展？只有在手动交易的方向。 只能用半自动机 "吸收"。而 我们将为我们的利基得到一个新的空间，从而为我们的活动的存在得到金钱和时间。以吃下另一个死角为代价。

我很迷惑。首先有一个问题，然后你写没有问题，然后你写有一个问题。

总的来说，你对贸易的发展有一个奇怪的概念。你曾写道，自动交易需要转为手动交易。反之亦然，不是吗？一开始是人工交易，连移动平均线都是用计算器计算的。然后出现了个人电脑和交易平台，其中这些指标已经被内置到平台中。然后，编码自定义指标，甚至自动交易系统成为可能。事实证明，自动交易是人工交易的发展。而半自动交易是介于 手动交易和自动交易之间，当交易策略不能自动化时。

 
Vitalii Ananev:

我很迷惑。首先有一个问题，然后你写没有问题，然后你写有一个问题。

而且总的来说，你有一个奇怪的交易发展概念。你写道，自动交易需要转为手动交易。反之亦然，不是吗？一 开始是人工交易，连移动平均线都是用计算器计算的。然后出现了个人电脑和交易平台，其中这些指标已经被内置到平台中。然后，编码自定义指标，甚至自动交易系统成为可能。事实证明，自动交易是人工交易的发展。而半自动交易是手动交易和自动交易之间的一个中间环节，当交易策略不能被算法化时。

从逻辑上讲，自动交易应该完全消除了人工交易。但是，相反，它开始平行发展。手工交易的领域没有被征服。这是在自动交易的发展中的一个错误。因此，为了进一步发展，人工交易应该被半自动交易所取代。

半自动机是目前自动机交易的一个欠发达领域。而且它的设计是为了吸收人工交易。这是一个自由发展的空间。如 果我们不征服它，其他人就会征服它。因此，我们必须走向手工交易，但只是为了"征服"它。

 
Vitalii Ananev:

...事实证明，自动交易是人工交易的进一步发展。而半自动交易是手动交易和自动交易之间的一个中间环节，当交易策略不适合算法交易时。

对。但它不仅是一个 "链接"。它是一个发展空间。这是钱。

 
Реter Konow:

从逻辑上讲，自动交易应该已经完全取代了人工交易。但是，相反，它开始平行发展。手工交易的领域没有被征服。这是在自动交易的发展中的一个错误。因此，为了进一步发展，人工交易应该被半自动交易所取代。

半自动机是目前自动机交易中尚未被征服的领域。而且它的设计是为了吸收人工交易。这是一个自由发展的空间。如 果我们不征服它，其他人就会征服它。因此，你必须向手工交易的方向发展，但只是为了"征服"它。

啊，这就是你的意思。我一开始就误解了你的意思。你建议用半自动交易取代人工交易，从而挤掉人工交易。但创建一个只开仓和设置TP和SL水平的界面是不够的。你需要将分析元素纳入这样一个界面。这就是半自动交易 的含义。机器人会分析市场情况，但开仓（或平仓）的决定是由交易者做出的。然后我们再回到创建交易系统的问题上。而如果你的界面只提供了开仓（平仓）的按钮，而没有分析市场，这就不是一个半自动交易系统，而是完全手动的，不是通过终端界面，而是通过 "专家顾问"。

 
Vitalii Ananev:

哦，这就是你的意思。我一开始就误解了你的意思。你提议用半自动交易取代人工交易，从而挤掉人工交易。但是，创建一个界面，只打开头寸，设置TP和SL水平是不够的。你 需要将分析元素纳入这样一个界面。这就是半自动交易 的含义。机器人会分析市场情况，但开仓（或平仓）的决定是由交易者做出的。然后我们再回到创建交易系统的问题上。如果你的界面只提供开仓（平仓）的按钮，而不分析市场，这就不是一个半自动交易系统，而是完全的手动交易，只是通过终端的一个界面，而是通过 "中介"。

嗯，我的界面提供的不仅仅是 "打开/关闭 "按钮 :)

没有图形用户界面，任何半自动化都无法工作。

因此，我创造了一个。然而，半自动化的进一步发展将取决于最聪明和最精明的开发者，利用所提供的工具，为 "手动 "任务制定半自动化解决方案。

我已经打开了一个新领域的大门，它将在MT平台上被我们社区的开发者们所征服。

顺便说一句，我很久以前就建议过这个问题，但没有人理解我）。

 
Реter Konow:

嗯，我的GUI提供的不仅仅是打开/关闭按钮 :)

没有图形用户界面，任何半自动化都无法工作。

因此，我创建了一个。然而，半自动装置的进一步发展将取决于最聪明和最精明的开发者，他们会采用建议的工具，为 "手动 "任务制定半自动的解决方案。

我已经打开了一个新领域的大门，它将在MT平台上被我们社区的开发者们所征服。

顺便说一句，我很久以前就建议过这个问题，但没有人理解我:))

我明白了。但是，除了你的编程风格不符合现代人的喜好外，恐怕务实的程序员更愿意使用现成的、更方便的类，包括在平台的标准交付集中。否则，他们将不得不处理你的代码的复杂性，而不是花更多的时间来实现市场分析 算法。

 
Vitalii Ananev:

我明白了。但你的编程风格并不符合现代人的喜好，恐怕务实的程序员会更喜欢使用现成的、更方便的、包含在平台标准交付集中的类来实现这些目的。否则，他们将不得不花更多的时间来实现市场分析的 算法，而不是去整理你的代码的复杂性。

你错了。

我将解释原因。

程序员将不需要翻阅我的解决方案的代码。他们将得到一个图形化的构造器，并创建他们的应用程序的界面。这个接口将由一个名为 "引擎 "的特殊程序承载。这个 "引擎 "将连接到开发者的应用程序，并作为一个单元 与之互动。也就是说，应用程序的GUI是由一个与应用程序本身相连的特殊程序承载的。

这已经被测试过了，而且是有效的。(奥列格-帕普科夫是这项技术的先驱）。

 
Реter Konow:

你错了。

让我解释一下原因。

程序员将不需要看我的解决方案的代码。他们将得到一个图形设计师，为他们的应用程序创建一个界面。这个接口将由一个名为 "引擎 "的特殊程序承载。这个 "引擎 "将连接到开发者的应用程序，并作为一个单元 与之互动。也就是说，应用程序的GUI是由一个与应用程序本身相连的特殊程序承载的。

这已经被测试过了，而且是有效的。(奥列格-帕普科夫是这项技术的先驱）。

那么，是否有可能在不做任何修改的情况下将市场分析 单元附加到它上面？

 
Vitalii Ananev:

那么，是否有可能在不做任何修改的情况下将市场分析 单元附加到它上面？

对。

携带应用程序GUI的引擎，只是执行控件（按钮、输入栏等）的机械功能。

按键、复选框、文本输入和其他用户行为。 直接从 被传递给开发者应用程序。

该应用程序可以将其数据转移到字段和表格。

一切都通过一个简单的连接文件完成。

 

.NET-dlls现在正在向MT发展。用C-sharp制作MT的GUI已不再困难，而且功能更多。因为在任何情况下，所有的事件都是在MT-ticks上发生的，那么按钮也是如此。好吧，分析工作，我认为，DLL比Peter更容易。

在一般情况下，发动机彼得，如果有人有用，它是唯一的市场销售商，其中DLL nizzo。

1...161718192021222324252627282930...184
新评论