我的方法。核心是引擎。 - 页 38 1...313233343536373839404142434445...184 新评论 Реter Konow 2018.12.09 12:36 #371 Georgiy Merts:嗯,嗯...去吧,彼得。 你对 "退化 "的看法是正确的,但我认为你对 "拉动用户 "的看法是自以为是的。但是,请继续。也许有人会编程,但在 "动手 "方面进行交易。我在想,美国有一个著名的手工交易平台。它有可能将平台内的行动部分自动化,但你必须知道如何去做。还有一个API。但有多少人能够做到呢? 我们可以编写方便的半自动机并提供给客户。而且不仅仅是他们。所有手动交易的交易者,我们可以提供部分自动化操作,从表格中观察市场,并使用对话窗口 与程序互动。显示市场事件的信息。好吧,也许我不知道或不理解一些东西,但在理论上呢? Andrey Barinov 2018.12.09 12:41 #372 Реter Konow:另一方面,我们可以编写方便的半自动机并提供给客户。而且不仅仅是他们。我们可以为所有手动交易的交易者提供部分自动化操作,从表格中观察市场并通过对话窗口与程序互动。显示市场事件的信息。好吧,也许我不知道或不理解一些东西,但在理论上呢?只有一个办法可以找到答案。 最后,至少要发表一些东西。 让它不太理想,没有毛绒玩具(如果有必要,以后再加),马上就能看到用户的需求+反馈,就会更清楚下一步该往哪个方向挖。 你越早做,你就越能节省时间(或者说,你失去的时间越少)。:( 在我的时代,我也会为这样的建议付出很多 :) Petros Shatakhtsyan 2018.12.09 12:45 #373 Georgiy Merts:嗯,嗯...去吧,彼得。 你对 "退化 "的看法是正确的,但我认为你对 "拉动用户 "的看法是自以为是的。 但是,请继续。可能有一个人知道如何编程,但他的交易是 "动手"。这是不可能的。那些懂得编程的人一定会在MQL5中做助手,只需花1-2周时间研究MQL5交易操作。至于半自动机器人,几个小时后,我将制作一个视频,向你展示一个可以作为专家顾问在半自动模式下工作的现代自动机器人是什么样子。而且你不需要为此发明复杂的面板,而是做一个非常简单的面板,让大家更清楚。 [删除] 2018.12.09 12:46 #374 Реter Konow:今天的用户因测试的圣杯而堕落了。他们需要被拉向一点复杂性,并对自己的行为负责。否则,就会出现完全退化的algotrading。 我不认为自动交易的利基市场有任何其他前景。老实说,我没有看到...这么多的悲怆......我看到了举起的悲伤的手;))))。 你,Petya,真的很喜欢救世主这个角色。 每个人都在堕落......这个世界会变成什么样子......。你的使命,你的命运是带领一个堕落的人类走向一个光明的自动交易的未来。这里已经有了一个诊断。从你的头顶上看... Petya,别装傻了。 Ilya Malev 2018.12.09 14:32 #375 我认为,mql的gui是重要的,也是必要的(也许还有元语言)。但是,如果它是在没有OOP的情况下完成的,那就更能说明其作者的思想状态,而不是方法。4天内完成38页,这很酷。显然,每个人都喜欢这种心境。 Nikolai Semko 2018.12.09 14:37 #376 一个悲伤的故事,真的... Ilya Malev 2018.12.09 14:44 #377 关于mql oop,有一些我个人不喜欢的东西。任何 "空 "对象都需要16个字节。再加上它的指针需要8个字节,每个项目总共24个字节,不包括数据。 如果你做一个属性矩阵,你可以用6个ints代替一个 "空 "对象,每个ints几乎可以存储任何东西,除了字符串(对于时间或价格,99%的情况下一个int就足够了)。 而dynamic_cast类型转换 操作在速度上并不便宜。因此,专题讨论会的方法(当然我没有见过,但从理论上讲)可能比用OOP进行模拟工作更快,占用的内存更少。 Yury Kulikov 2018.12.09 15:58 #378 Ilya Malev: 所以topikstarter的方法(当然我没有见过,但理论上)可能 比OOP的类似方法工作得更快,占用的内存更少。 它不能,topicstarter的 "内核 "是一个巨大的字符串阵列,谈论这种方法的效率是不现实的,即使在理论上。 Georgiy Merts 2018.12.09 16:08 #379 Ilya Malev:而且,就速度而言,dynamic_cast类型转换 操作并不便宜。因此,topicstarter的方法(当然,我没有见过,但在理论上)可能比它的OOP类似物工作得更快,占用的内存更少。因此,没有人认为直接访问一个巨大的全局数组要比所有这些接口的设计和类型转换更快。我们还可以考虑设计模式,例如,带有双重调度的Visitor - 那里有大量的开销。 然而,所有这些都被支持和修改的便利所补偿。不幸的是,将任何思考的努力最大限度地转移到计算机上,长期以来一直是编程发展的主流。它达到了一个地步,即通过循环来计算算术级数的和,而不是使用众所周知的和公式。在这个意义上,我同意彼得的观点,即人们在 "贬低"。 但是,唉,没有选择--要么你和其他人一起 "堕落",尽量不要这么快,要么你就无望地落后。而你的方案没有效果的事实并不重要。 在这里,我甚至看到了与生物学中竞争的类比,在捕食者和猎物之间的关系中。 野兔在逃离狼的时候,实际上根本不是与狼竞争,而是与其他野兔竞争。他不需要尽可能快地离开狼。对他来说,不做最后一个逃出狼群的人更为重要。因为如果他是最后一个逃跑的人--他将被吃掉,但如果他比其他人跑得快--他将花费更多的能量,而这些能量可以用在更有用的方向。 各种编程技术也是如此......用汇编语言编程的最有效方法,但它需要花费大量精力,以至于没有意义--精力最好花在更有成效的地方,即使代码在这方面的效率不高。彼得的全局访问阵列也是这种情况。访问它是有效的,但记住什么在哪里,如何访问什么,需要花费太多的精力。 Ilya Malev 2018.12.09 16:17 #380 Yury Kulikov:它不可能,在专题组的 "核心 "是一个巨大的字符串阵列,谈论这种方法的有效性是不现实的,即使在理论上。它真的是一个字符串数组,还是一个比喻?如果数据是由mql(字符串)字符串表示的,就真的没有机会... 格奥尔基-梅尔茨。访问它是有效的,但记住什么在哪里以及如何访问它需要太多的时间。 当 "内核 "准备好后,你可以花相对较少的精力给它贴上一个方便的界面,解决所有 "笨拙 "的展示和获取信息的问题。虽然这只是一个空谈,但据我所知,TC还没有公布他的代码,谁也不知道这些代码是否有性质:)或者他已经发布了这些信息?说实话,我无法看完所有38页 此外,仅局限于 "半自动机 "的方法从定义上来说是没有价值的。虽然它可以帮助在产品和自由职业者市场上占据一个局部的、有限的利基市场 1...313233343536373839404142434445...184 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
嗯,嗯...去吧,彼得。
你对 "退化 "的看法是正确的,但我认为你对 "拉动用户 "的看法是自以为是的。
但是,请继续。也许有人会编程,但在 "动手 "方面进行交易。
我在想,美国有一个著名的手工交易平台。它有可能将平台内的行动部分自动化,但你必须知道如何去做。还有一个API。但有多少人能够做到呢?
我们可以编写方便的半自动机并提供给客户。而且不仅仅是他们。所有手动交易的交易者,我们可以提供部分自动化操作,从表格中观察市场,并使用对话窗口 与程序互动。显示市场事件的信息。好吧,也许我不知道或不理解一些东西,但在理论上呢?
另一方面,我们可以编写方便的半自动机并提供给客户。而且不仅仅是他们。我们可以为所有手动交易的交易者提供部分自动化操作,从表格中观察市场并通过对话窗口与程序互动。显示市场事件的信息。好吧,也许我不知道或不理解一些东西,但在理论上呢?
只有一个办法可以找到答案。
最后,至少要发表一些东西。
让它不太理想,没有毛绒玩具(如果有必要,以后再加),马上就能看到用户的需求+反馈,就会更清楚下一步该往哪个方向挖。
你越早做,你就越能节省时间(或者说,你失去的时间越少)。:(
在我的时代,我也会为这样的建议付出很多 :)
嗯,嗯...去吧,彼得。
你对 "退化 "的看法是正确的,但我认为你对 "拉动用户 "的看法是自以为是的。
但是,请继续。可能有一个人知道如何编程,但他的交易是 "动手"。
这是不可能的。那些懂得编程的人一定会在MQL5中做助手,只需花1-2周时间研究MQL5交易操作。
至于半自动机器人,几个小时后,我将制作一个视频,向你展示一个可以作为专家顾问在半自动模式下工作的现代自动机器人是什么样子。
而且你不需要为此发明复杂的面板,而是做一个非常简单的面板,让大家更清楚。
今天的用户因测试的圣杯而堕落了。他们需要被拉向一点复杂性,并对自己的行为负责。否则,就会出现完全退化的algotrading。
我不认为自动交易的利基市场有任何其他前景。老实说,我没有看到...
这么多的悲怆......我看到了举起的悲伤的手;))))。
你,Petya,真的很喜欢救世主这个角色。
每个人都在堕落......这个世界会变成什么样子......。你的使命,你的命运是带领一个堕落的人类走向一个光明的自动交易的未来。这里已经有了一个诊断。从你的头顶上看...
Petya,别装傻了。
关于mql oop,有一些我个人不喜欢的东西。任何 "空 "对象都需要16个字节。再加上它的指针需要8个字节,每个项目总共24个字节,不包括数据。 如果你做一个属性矩阵,你可以用6个ints代替一个 "空 "对象,每个ints几乎可以存储任何东西,除了字符串(对于时间或价格,99%的情况下一个int就足够了)。
而dynamic_cast类型转换 操作在速度上并不便宜。因此,专题讨论会的方法(当然我没有见过,但从理论上讲)可能比用OOP进行模拟工作更快,占用的内存更少。
Ilya Malev:
所以topikstarter的方法(当然我没有见过,但理论上)可能 比OOP的类似方法工作得更快,占用的内存更少。
它不能,topicstarter的 "内核 "是一个巨大的字符串阵列,谈论这种方法的效率是不现实的,即使在理论上。
而且,就速度而言,dynamic_cast类型转换 操作并不便宜。因此,topicstarter的方法(当然,我没有见过,但在理论上)可能比它的OOP类似物工作得更快,占用的内存更少。
因此,没有人认为直接访问一个巨大的全局数组要比所有这些接口的设计和类型转换更快。我们还可以考虑设计模式,例如,带有双重调度的Visitor - 那里有大量的开销。
然而,所有这些都被支持和修改的便利所补偿。不幸的是,将任何思考的努力最大限度地转移到计算机上,长期以来一直是编程发展的主流。它达到了一个地步,即通过循环来计算算术级数的和,而不是使用众所周知的和公式。在这个意义上,我同意彼得的观点,即人们在 "贬低"。
但是,唉,没有选择--要么你和其他人一起 "堕落",尽量不要这么快,要么你就无望地落后。而你的方案没有效果的事实并不重要。
在这里,我甚至看到了与生物学中竞争的类比,在捕食者和猎物之间的关系中。 野兔在逃离狼的时候,实际上根本不是与狼竞争,而是与其他野兔竞争。他不需要尽可能快地离开狼。对他来说,不做最后一个逃出狼群的人更为重要。因为如果他是最后一个逃跑的人--他将被吃掉,但如果他比其他人跑得快--他将花费更多的能量,而这些能量可以用在更有用的方向。
各种编程技术也是如此......用汇编语言编程的最有效方法,但它需要花费大量精力,以至于没有意义--精力最好花在更有成效的地方,即使代码在这方面的效率不高。彼得的全局访问阵列也是这种情况。访问它是有效的,但记住什么在哪里,如何访问什么,需要花费太多的精力。
它不可能,在专题组的 "核心 "是一个巨大的字符串阵列,谈论这种方法的有效性是不现实的,即使在理论上。
它真的是一个字符串数组,还是一个比喻?如果数据是由mql(字符串)字符串表示的,就真的没有机会...
访问它是有效的,但记住什么在哪里以及如何访问它需要太多的时间。
当 "内核 "准备好后,你可以花相对较少的精力给它贴上一个方便的界面,解决所有 "笨拙 "的展示和获取信息的问题。虽然这只是一个空谈,但据我所知,TC还没有公布他的代码,谁也不知道这些代码是否有性质:)或者他已经发布了这些信息?说实话,我无法看完所有38页
此外,仅局限于 "半自动机 "的方法从定义上来说是没有价值的。虽然它可以帮助在产品和自由职业者市场上占据一个局部的、有限的利基市场