需要帮助!无法解决这个问题，我遇到了硬件限制 - 页 17 1...101112131415161718192021 新评论 Sergey Dzyublik 2014.08.21 14:15 #161 有可能在一次数据读取中计算出所有的东西--主要的是欲望。komposter:是的，在这种形式下，任务是并行的--每次SeekDate改变时，你可以在序列集的不同部分同时运行最佳标准的搜索。例如，我们把它们分成20个部分，把任务交给20个专家顾问。而他们应该读取文件，找到交易，并只发回最佳序列（№№，标准和文件位置）。非常感谢你们!如果我们在多个EA上运行这种算法，我们会受到从磁盘上+分次+从不同位置读取速度的限制，速度很可能不够。 Eugeniy Lugovoy 2014.08.21 14:23 #162 ALXIMIKS: 你可以在一次数据读取中计算所有的东西--如果你想的话，主要的是从磁盘上读取是一个相当昂贵的操作--在几个Expert Advisors上运行这个算法将受到从磁盘上读取的速度的限制+分批读取+从不同位置读取，速度不太可能达到。 谁说分布式计算 必须在一个工作站上进行？ 没有这样的限制))如上所述，RAM-磁盘会有帮助。 Sergey Dzyublik 2014.08.21 14:51 #163 elugovoy: 谁说分布式计算 应该在一个工作站上完成？ 没有这样的限制）)如上所述，RAM-磁盘也是一个很大的帮助。想一想，改变一下算法如何？1.如何一次性下载几个序列，以及如何知道它们在哪里开始，哪里结束2.如何计算一个序列中所有交易的系数，以及在什么数据结构中存储答案3.如何将上一项目中的两个答案合并成一个新的稍完整的答案4.如何将第3点的最终答案划分为所需的区间（我们谈论的是SeekingDate=交易关闭时间+1）。我们可以得到一个稍有不同的算法，即选择将SeekingDate 区间分成多少个额外的部分与最初作者的算法相比，我们可以得到不同的错误。 Eugeniy Lugovoy 2014.08.21 19:26 #164 papaklass:数字的位数容量由输入代码的唯一性决定，而不是系统的位数容量。很明显，它应该是1个字节的倍数。在我看来，64位似乎太多了。:)如果有1,000,000条记录，16位将不足以获得一个独特的记录代码（最多65536条记录）。那是一个。看看英特尔（Itanium）、AMD（我没说操作系统）的32位和64位处理器架构。32/64是地址总线的分辨率，但同时在一个机器周期内从内存中读取32/64位（4/8字节），即使是访问一个字节的内存。因此，无论是从内存中读取2个字节还是8个字节，在性能上绝对没有区别。原则上，你可以为这种文件处理编写一个Windows服务。但我还是倾向于使用DBMS。 Eugeniy Lugovoy 2014.08.21 19:35 #165 ALXIMIKS:想一想，改变一下算法如何？1.如何一次性下载几个序列，以及如何知道它们在哪里开始，哪里结束2.如何计算一个序列中所有交易的系数，以及在什么数据结构中存储答案3.如何将上一项目中的两个答案合并成一个新的稍完整的答案4.如何将第3点的最终答案划分为所需的区间（我们谈论的是SeekingDate=交易关闭时间+1）。我们可以得到一个稍有不同的算法，即选择将SeekingDate 区间分成多少个额外的部分与最初作者的算法相比，我们可能得到不同的错误。对于所有4点，DBMS方面的数据处理。关于 "稍有不同 "的算法，我不太清楚你的意思。但是。为了以某种方式计算这种 "稍有不同 "的算法与 "作者 "的算法相比的误差，你需要两种算法都能实现。而这个主题的产生正是因为实现 "作者 "的算法的技术问题。鉴于这一事实，你打算用什么方法来计算你所说的误差？ Eugeniy Lugovoy 2014.08.21 19:43 #166 ALXIMIKS: 你可以在一次阅读中计算出所有的东西--主要的是欲望。从磁盘读取是一个相当昂贵的操作--在几个Expert Advisors上运行这个算法将受到从磁盘+分次+从不同位置读取速度的限制，这个想法不太可能带来任何速度。我们说HDD是最慢的设备，这是一个事实。然而，我们不是在谈论使用所有这些计算方法运行多个EA。在我看来，最可能的应用是信号生成。比如亚马逊上的云服务器，具有必要的性能+MT4+这种开发=信号提供者。 Sergey Dzyublik 2014.08.21 19:49 #167 elugovoy:对于这4点，数据处理都是在DBMS方面。关于 "略有不同 "的算法，我不清楚你的意思。但是。为了以某种方式计算这种 "稍有不同 "的算法与 "作者 "的算法相比的误差，必须实现两种算法。而这个主题的产生正是因为实现 "作者 "的算法的技术问题。鉴于这一事实，你打算用什么方法来计算你所说的误差？我从作者那里了解到，范围将被从给定范围中选择的最大系数所截断。 我建议的变体是将每个范围分为N个子范围，在收敛时只有一个系数值可能适合。因此，在N=5时，该范围可分为0.2 0.4 0.6 0.8 1的比例。而从0到1的任何数值都会在作者的一中被切断。因此，在N=5时，0.2的范围误差是最大的。而且都是围绕着如何正确地解释作者的帖子，因为现在还没有完全清楚。 Eugeniy Lugovoy 2014.08.21 20:15 #168 ALXIMIKS:根据我对作者版本的理解（万一又出错了，因为没有清楚完整地解释到底需要什么），这个范围将被从这个范围中选择的最大系数切断；在我建议的版本中，每个这样的范围应该被划分为N个子范围，其中只有一个系数值能适合合并。因此，在N=5时，该范围可分为0.2 0.4 0.6 0.8 1的比例。而从0到1的任何数值都在作者的范围内被切断。因此，在N=5时，0.2的范围误差是最大的。而且都是围绕着如何正确地解释作者的帖子，因为现在还没有完全清楚。是的，显然该项目 是由财政部下令的，没有足够的具体信息。然而，每个人都能从讨论中找到自己感兴趣的东西。我认为这是讨论的一个积极方面。关于范围的离散化，你的想法很清楚。而如果N=100，1000...(纯粹从数学上看是可能的），那么这种拆分就会在性能和系统资源的使用方面引起反作用。有物理学，也有数学 ) Andrey Khatimlianskii 2014.08.22 19:11 #169 Candid:我们在记忆中拥有一个文件的片段，通过它并形成一个必要长度的样本来计算标准，只选择属于同一序列的交易。然后我们在这个样本上计算出标准。顺便说一下，有可能在选择中使用递归法。因此，你需要通过其他序列的几百万笔交易!这正是我的意思。ALXIMIKS。插入新数据的问题--以某种方式解决它。到目前为止没有问题，数据是一个固定的数量。TheXpert。 顺便说一下，如果你知道每个序列的起点，你可以用二进制搜索来搜索正确的日期，因为交易是按时间排序的。+1，谢谢你的主意。elugovoy: 1.根据上述"让标准成为该序列最后20次交易的平均利润。"，这应该被理解为一个标准，即利润的移动预期。还有哪些人？在数据库中，生成一个带有序列标识符和相应移动平均线的表格。不符合条件的序列应立即删除。这应该由DBMS级别的并发模式程序完成，根据机器人的要求，在机器人中显示进程状态。让我们说，FilterAvgProfit（pProfitValue，pTrades，pDeviation）。 其中pProfitValue是目标利润，pTrades是移动平均利润的交易数，pDeviation是pProfitValue的允许偏差。结果是一个带有序列ID和平均利润值的填充表。1а.其他标准是什么--这并不重要。重要的是，计算是由一系列指定长度的交易进行的。1б.你怎么能仅仅因为一个序列在关闭交易N时有一个不好的标准值而放弃它？如果以后成为更好的呢？ 你只能删除那些已经完全失败的序列，其标准没有显示任何利润。而且不应该有很多这样的人。elugovoy: 4.在我看来，如果我们看的是策略选择，这个操作不应该太频繁（比如说，在每个柱子上或在订单打开前立即执行）。这种方法是合理的，如果目前的策略显示连续N次亏损的交易--那么我们可以选择另一个策略，它需要时间来 "做决定"，没有什么可避免的。或者，每周进行一次这样的选择（在周末，当市场关闭时），并且，要么确认当前选择的策略，要么切换到另一个策略。在给定的条件下，有可能为交易者制定一份最佳推荐策略清单。然后随着市场开盘，在头脑清醒的情况下（周一），交易员将确认选择（或更早，在市场开盘前......电子邮件提醒，等等）。嗯，这是一个意识形态的问题。现在不谈他了；)ALXIMIKS。你把内存分配给一个结构数组，并获得。为什么你需要一个标准值数组和一个文件指针位置数组？(一个标准和最后一笔交易，你没有想到要储存吗？)标准值阵列--能够对一些最佳序列进行分类和选择（用于未来）。文件索引位置--在每个序列中从正确的地方继续搜索（否则如何？）ALXIMIKS。我说对了吗。第一遍--在从0到SeekDate的区间内搜索然后找到最佳标准，FindDate=交易收盘时间+1现在搜索从"交易收盘时间 "到SeekingDate的时间间隔？而你需要在这个区间内适合X个交易来计算每个序列的标准？1.是的，从0到SeekingDate先。2.SeekedDate被移位，我们在 "PreviousTreatedTrade - SeekDate "的区间内处理序列（将交易加入数组）。雷纳特。这些都是奇怪的结果。下面是我们的工作服务器系统在负载下的情况。SSD：每秒200Mb，NTFS含RAM：2000-2500Mb/秒，FAT32，Softperfect RAM Disk 3.4.5没有磁盘框架，组装项目的时间要长很多倍。我开始变得复杂了。可能需要做一个测试脚本，并附上一个文件，供你在类似的任务中检查。我有一个普通的硬盘 - wdc wd1002FAEX-00Y9A0，从规格上看，最大速度是126MB/s。从评论 来看，这大约是你能挤出来的东西。也许我做错了什么？让我们来看看这个脚本...ALXIMIKS。 这就是我所说的--你必须大块地读取大文件，否则小文件可能需要10倍的时间。你如何阅读大块的东西？纸杯。在我看来，问题的解决方案在于对原始数据进行编码。我们如何在不丢失信息的情况下对全部交易信息进行编码？ Andrey Khatimlianskii 2014.08.22 19:31 #170 Renat:奇怪的结果。下面是我们的生产服务器系统在负载下的情况。带SSD：每秒200Mb，NTFS含RAM：2000-2500Mb/秒，FAT32，Softperfect RAM Disk 3.4.5如果没有RAM磁盘，建立项目的时间要长很多倍。我忘了写记忆。DDR3，1333 MHz。Softperfect RAM Disk 3.4.5，虽然我做了NTFS（有什么区别吗？）还有一个细节--RAM磁盘是12000MB，只有1-2GB的可用内存（用于工作）。 1...101112131415161718192021 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
是的，在这种形式下，任务是并行的--每次SeekDate改变时，你可以在序列集的不同部分同时运行最佳标准的搜索。例如，我们把它们分成20个部分，把任务交给20个专家顾问。而他们应该读取文件，找到交易，并只发回最佳序列（№№，标准和文件位置）。
非常感谢你们!
如果我们在多个EA上运行这种算法，我们会受到从磁盘上+分次+从不同位置读取速度的限制，速度很可能不够。
你可以在一次数据读取中计算所有的东西--如果你想的话，主要的是
从磁盘上读取是一个相当昂贵的操作--在几个Expert Advisors上运行这个算法将受到从磁盘上读取的速度的限制+分批读取+从不同位置读取，速度不太可能达到。
谁说分布式计算 应该在一个工作站上完成？ 没有这样的限制）)如上所述，RAM-磁盘也是一个很大的帮助。
想一想，改变一下算法如何？
1.如何一次性下载几个序列，以及如何知道它们在哪里开始，哪里结束
2.如何计算一个序列中所有交易的系数，以及在什么数据结构中存储答案
3.如何将上一项目中的两个答案合并成一个新的稍完整的答案
4.如何将第3点的最终答案划分为所需的区间（我们谈论的是SeekingDate=交易关闭时间+1）。
我们可以得到一个稍有不同的算法，即选择将SeekingDate 区间分成多少个额外的部分
与最初作者的算法相比，我们可以得到不同的错误。
数字的位数容量由输入代码的唯一性决定，而不是系统的位数容量。很明显，它应该是1个字节的倍数。
在我看来，64位似乎太多了。:)
如果有1,000,000条记录，16位将不足以获得一个独特的记录代码（最多65536条记录）。那是一个。
看看英特尔（Itanium）、AMD（我没说操作系统）的32位和64位处理器架构。32/64是地址总线的分辨率，但同时在一个机器周期内从内存中读取32/64位（4/8字节），即使是访问一个字节的内存。
因此，无论是从内存中读取2个字节还是8个字节，在性能上绝对没有区别。
原则上，你可以为这种文件处理编写一个Windows服务。
但我还是倾向于使用DBMS。
想一想，改变一下算法如何？
1.如何一次性下载几个序列，以及如何知道它们在哪里开始，哪里结束
2.如何计算一个序列中所有交易的系数，以及在什么数据结构中存储答案
3.如何将上一项目中的两个答案合并成一个新的稍完整的答案
4.如何将第3点的最终答案划分为所需的区间（我们谈论的是SeekingDate=交易关闭时间+1）。
我们可以得到一个稍有不同的算法，即选择将SeekingDate 区间分成多少个额外的部分
与最初作者的算法相比，我们可能得到不同的错误。
对于所有4点，DBMS方面的数据处理。
关于 "稍有不同 "的算法，我不太清楚你的意思。但是。为了以某种方式计算这种 "稍有不同 "的算法与 "作者 "的算法相比的误差，你需要两种算法都能实现。而这个主题的产生正是因为实现 "作者 "的算法的技术问题。
鉴于这一事实，你打算用什么方法来计算你所说的误差？
你可以在一次阅读中计算出所有的东西--主要的是欲望。
从磁盘读取是一个相当昂贵的操作--在几个Expert Advisors上运行这个算法将受到从磁盘+分次+从不同位置读取速度的限制，这个想法不太可能带来任何速度。
我们说HDD是最慢的设备，这是一个事实。然而，我们不是在谈论使用所有这些计算方法运行多个EA。在我看来，最可能的应用是信号生成。比如亚马逊上的云服务器，具有必要的性能+MT4+这种开发=信号提供者。
对于这4点，数据处理都是在DBMS方面。
关于 "略有不同 "的算法，我不清楚你的意思。但是。为了以某种方式计算这种 "稍有不同 "的算法与 "作者 "的算法相比的误差，必须实现两种算法。而这个主题的产生正是因为实现 "作者 "的算法的技术问题。
鉴于这一事实，你打算用什么方法来计算你所说的误差？
我从作者那里了解到，范围将被从给定范围中选择的最大系数所截断。 我建议的变体是将每个范围分为N个子范围，在收敛时只有一个系数值可能适合。因此，在N=5时，该范围可分为0.2 0.4 0.6 0.8 1的比例。而从0到1的任何数值都会在作者的一中被切断。因此，在N=5时，0.2的范围误差是最大的。
而且都是围绕着如何正确地解释作者的帖子，因为现在还没有完全清楚。
根据我对作者版本的理解（万一又出错了，因为没有清楚完整地解释到底需要什么），这个范围将被从这个范围中选择的最大系数切断；在我建议的版本中，每个这样的范围应该被划分为N个子范围，其中只有一个系数值能适合合并。因此，在N=5时，该范围可分为0.2 0.4 0.6 0.8 1的比例。而从0到1的任何数值都在作者的范围内被切断。因此，在N=5时，0.2的范围误差是最大的。
而且都是围绕着如何正确地解释作者的帖子，因为现在还没有完全清楚。
是的，显然该项目 是由财政部下令的，没有足够的具体信息。然而，每个人都能从讨论中找到自己感兴趣的东西。我认为这是讨论的一个积极方面。
关于范围的离散化，你的想法很清楚。而如果N=100，1000...(纯粹从数学上看是可能的），那么这种拆分就会在性能和系统资源的使用方面引起反作用。有物理学，也有数学 )
我们在记忆中拥有一个文件的片段，通过它并形成一个必要长度的样本来计算标准，只选择属于同一序列的交易。然后我们在这个样本上计算出标准。顺便说一下，有可能在选择中使用递归法。
因此，你需要通过其他序列的几百万笔交易!这正是我的意思。
插入新数据的问题--以某种方式解决它。
到目前为止没有问题，数据是一个固定的数量。
顺便说一下，如果你知道每个序列的起点，你可以用二进制搜索来搜索正确的日期，因为交易是按时间排序的。
+1，谢谢你的主意。
1.根据上述"让标准成为该序列最后20次交易的平均利润。"，这应该被理解为一个标准，即利润的移动预期。还有哪些人？
在数据库中，生成一个带有序列标识符和相应移动平均线的表格。不符合条件的序列应立即删除。这应该由DBMS级别的并发模式程序完成，根据机器人的要求，在机器人中显示进程状态。
让我们说，FilterAvgProfit（pProfitValue，pTrades，pDeviation）。
其中pProfitValue是目标利润，pTrades是移动平均利润的交易数，pDeviation是pProfitValue的允许偏差。
结果是一个带有序列ID和平均利润值的填充表。
1а.其他标准是什么--这并不重要。重要的是，计算是由一系列指定长度的交易进行的。
1б.你怎么能仅仅因为一个序列在关闭交易N时有一个不好的标准值而放弃它？如果以后成为更好的呢？
你只能删除那些已经完全失败的序列，其标准没有显示任何利润。而且不应该有很多这样的人。
4.在我看来，如果我们看的是策略选择，这个操作不应该太频繁（比如说，在每个柱子上或在订单打开前立即执行）。这种方法是合理的，如果目前的策略显示连续N次亏损的交易--那么我们可以选择另一个策略，它需要时间来 "做决定"，没有什么可避免的。或者，每周进行一次这样的选择（在周末，当市场关闭时），并且，要么确认当前选择的策略，要么切换到另一个策略。在给定的条件下，有可能为交易者制定一份最佳推荐策略清单。然后随着市场开盘，在头脑清醒的情况下（周一），交易员将确认选择（或更早，在市场开盘前......电子邮件提醒，等等）。
嗯，这是一个意识形态的问题。现在不谈他了；)
你把内存分配给一个结构数组，并获得。
为什么你需要一个标准值数组和一个文件指针位置数组？(一个标准和最后一笔交易，你没有想到要储存吗？)
标准值阵列--能够对一些最佳序列进行分类和选择（用于未来）。
文件索引位置--在每个序列中从正确的地方继续搜索（否则如何？）
我说对了吗。
第一遍--在从0到SeekDate的区间内搜索
然后找到最佳标准，FindDate=交易收盘时间+1
现在搜索从"交易收盘时间 "到SeekingDate的时间间隔？
而你需要在这个区间内适合X个交易来计算每个序列的标准？
1.是的，从0到SeekingDate先。
2.SeekedDate被移位，我们在 "PreviousTreatedTrade - SeekDate "的区间内处理序列（将交易加入数组）。
这些都是奇怪的结果。
下面是我们的工作服务器系统在负载下的情况。
没有磁盘框架，组装项目的时间要长很多倍。
我开始变得复杂了。
可能需要做一个测试脚本，并附上一个文件，供你在类似的任务中检查。
我有一个普通的硬盘 - wdc wd1002FAEX-00Y9A0，从规格上看，最大速度是126MB/s。
从评论 来看，这大约是你能挤出来的东西。也许我做错了什么？
让我们来看看这个脚本...
这就是我所说的--你必须大块地读取大文件，否则小文件可能需要10倍的时间。
你如何阅读大块的东西？
在我看来，问题的解决方案在于对原始数据进行编码。
我们如何在不丢失信息的情况下对全部交易信息进行编码？
奇怪的结果。
下面是我们的生产服务器系统在负载下的情况。
如果没有RAM磁盘，建立项目的时间要长很多倍。
我忘了写记忆。
DDR3，1333 MHz。
Softperfect RAM Disk 3.4.5，虽然我做了NTFS（有什么区别吗？）
还有一个细节--RAM磁盘是12000MB，只有1-2GB的可用内存（用于工作）。