在Metatrader 5中你的符号和你的数据源 - 页 11 1...456789101112131415161718...26 新评论 Vladimir Suslov 2015.04.25 08:08 #101 我将添加另一个测试函数，包含两个均匀的最高值的高原。z = abs(tanh(x) + tanh(y))如果你将X,Y从-20改为+20，步长为0.1，那么完整的迭代需要160801次。在测试中，这两个高原在1400次迭代中出现，这还不到完整搜索的百分之一。有人会在GA上运行这个吗？有意思的是要进行比较。 Andrey Dik 2015.04.25 08:21 #102 event:我将添加另一个测试函数，包含两个均匀的最高值的高原。z = abs(tanh(x) + tanh(y))如果你将X,Y从-20改为+20，步长为0.1，那么完整的迭代需要160801次。在测试中，这两个高原在1400次迭代中出现，这还不到完整搜索的百分之一。有人会在GA上运行这个吗？有意思的是要进行比较。你不是在用GA看吗？用优化后的函数的两个参数来工作，一点也不说明问题。不仅是因为搜索空间小，而且还因为搜索算法本身的 "坏 "属性会出现。将公式转换成至少有10个参数的形式，算法的所有正负属性都会显示出来。 Vladimir Suslov 2015.04.25 08:30 #103 joo:你不是在找GA吗？用一个优化的函数的两个参数来工作，一点也不说明问题。不仅是因为搜索空间小，而且还因为搜索算法本身的 "坏 "属性会出现。将公式转换为至少10个参数的形式--算法的所有正负属性将一次性出现。这不是GA，在这个主题里有一个文章的链接。上面我贴了一个有六个参数的例子。显示大量参数的整个困难。如果你建议一个有更多参数的函数--我将做一个测试。 Andrey Dik 2015.04.25 08:42 #104 event:如果你建议一个有更多参数的函数--我会做一个测试。Y=a+b。 其中。a=皮肤（x1，y1）+皮肤（x2，y2）+皮肤（x3，y3）+皮肤（x4，y4）+皮肤（x5，y5）。b=皮肤（x6，y6）+皮肤（x7，y7）+皮肤（x8，y8）+皮肤（x9，y9）+皮肤（x10，y10）。你已经知道在哪里可以找到 "皮肤 "功能。所以有20个变量，Y函数非常容易可视化。你可以利用这一原则建立一个参数数量无限的函数，但仍然能够将其可视化。而相应地，最后的结果是以Y*2/n与已知的极值进行核对，其中n是参数的总数。 [删除] 2015.04.25 09:04 #105 Laryx:你能给我一个算法的例子，在 "转向不足 "中，完全的转向过度只需十几个小时，而在MT中则需要几个月？ 完整的搜索比优化启发式更快，这也是现实的。在MT中，一个完整的蛮力攻击被表示为一组独立的运行。事实上，总是有可能将优化视为一个单一的计算问题，并对其应用算法优化。 在这种方法中，传递的顺序非常重要，因为几乎所有的计算都是缓存的。对于TC的几乎每一个（所有独立的）输入参数，在优化器中总是有全局缓冲区来存储以前的值。 例如，你使用MA MA和PriceChannel。对于这些指标中的每一个都有自己独立的输入参数。这就是为什么我们为每个指标规定（实际上只有几行，用OOP应该更漂亮）函数来填充其全局缓冲区。然后我们比较每个指标的资源强度（PriceChannel比MA更重）。较重指标的输入参数在外部循环（第一个for）中开始列举，简单指标在内部循环（嵌套for）中列举。 这就是我们获得巨大收益的地方。此外，还有C++、整数计算和我们自己的订单系统，没有不必要的检查。这就是你如何得到的结果。因此，单次运行至少比MT快一个数量级。而且优化的速度也快了好几个数量级。 在MT-优化器中缺少的是OnOptimization功能，它可以提供对所获得的优化结果 矩阵的完全访问。我在那里对获得的矩阵进行各种分析：过滤，合并交易时间不重叠的订单，等等。但是，更有用的是计算每个通道的权重系数，以适当的投资组合形式组成一个元TS。为此，OnOptimization为每一个非 "无望 "的通行证都有一个向量-平等。 但是，在寻找工作中的TS的阶段，并没有发明底层测试者，而是当它已经被发现时，不幸的是。搜索本身是一个完全不同的阶段：没有描述。 Sergey Chalyshev 2015.04.25 09:29 #106 event:有人会在GA上运行这个吗？有意思的是要进行比较。 Vladimir Suslov 2015.04.25 09:48 #107 joo:Y=a+b。 其中。a=皮肤（x1，y1）+皮肤（x2，y2）+皮肤（x3，y3）+皮肤（x4，y4）+皮肤（x5，y5）。b=皮肤（x6，y6）+皮肤（x7，y7）+皮肤（x8，y8）+皮肤（x9，y9）+皮肤（x10，y10）。你已经知道在哪里可以找到 "皮肤 "功能。所以有20个变量，Y函数非常容易可视化。你可以利用这一原则建立一个参数数量无限的函数，但仍然能够将其可视化。而相应地，最后的结果是以Y*2/n与已知的极值进行核对，其中n是参数的总数。 可怕的事情...)那你能解释一下"函数Y非常容易被视觉化"吗？ Vladimir Suslov 2015.04.25 09:49 #108 Serj_Che: 计算时要经过多少次，以什么样的可变间距？ Sergey Chalyshev 2015.04.25 10:19 #109 event: 计算时要经过多少次，用哪一步的变量？如果你不喜欢这幅画，谁会在乎呢？MT5中的64位GA非常好，它可以解决任何问题，主要是要正确表述问题。我不知道你在这个关于GA的主题中所说的书呆子是什么样的人。我不认为问题出在GA上，但测试器本身是无用的，特别是在交易所，因为错误的报价历史存储和不可能保存自己的历史。我希望这个问题能得到解决，但我恐怕要等上3-5年。 Georgiy Merts 2015.04.25 11:43 #110 zaskok: 例如，你使用MA和PriceChannel。这些指标中的每一个都有自己独立的输入参数。因此，对于每个指标都有一个写好的（实际上只有几行，用OOP肯定更漂亮）函数来填充其相应的全局缓冲区。然后我们比较每个指标的资源强度（PriceChannel比MA更重）。较重的指标的输入参数在外部循环（第一个for）中开始列举，简单的指标在内部循环（嵌套for）中列举。直觉告诉我，这种方法也可以在GA下轻松完成。工作量是差不多的。内循环 "每次都会通过... 但是，最重要的是--那会有多少需求？正如我猜想的那样，不是每个人都会使用甚至是简单的自定义OnTester()函数。但这是一个非常强大的优化工具。 例如，这里是我的一个实施方案。double CDoublePeakBottomAdvisorPartsFactory::MyOnTester(CMyExpertT* pmeExpert){ ulong ulTickedTime = pmeExpert.GetTickedTime(); uint uiTotalNumberOfSL = pmeExpert.GetNumOfLosePositions(); double dDDPercent = TesterStatistics(STAT_EQUITY_DDREL_PERCENT); double dStartBalance = TesterStatistics(STAT_INITIAL_DEPOSIT); double dProfit = TesterStatistics(STAT_PROFIT); double dNumOfTrades = TesterStatistics(STAT_TRADES); double dNumOfProfitTrades = TesterStatistics(STAT_PROFIT_TRADES); double dMaxNumOfSL = TesterStatistics(STAT_MAX_CONLOSS_TRADES); double dRecoveryFactor = TesterStatistics(STAT_RECOVERY_FACTOR); double dProfitTradesPerWeek = dNumOfProfitTrades/ulTickedTime*SECS_IN_WEEK; double dProfitPerDay = dProfit/ulTickedTime*SECS_IN_DAY; Print("Ticked time (days): ",DoubleToString(ulTickedTime/SECS_IN_DAY,2)); Print("Number Of Trades: ",DoubleToString(dNumOfTrades,1)); if(dNumOfTrades == 0) { Print("Ни одного трейда !"); return(-100000); }; if(dMaxNumOfSL > uiIMaxNumOfSeqSL) return(-10000 - dMaxNumOfSL*100 + dProfit/1000); double dBarsPerTrade = ((double)ulTickedTime/PeriodSeconds(m_didData.m_etTimeFrame))/dNumOfTrades; if((bILongAllow == false) || (bIShortAllow == false)) dBarsPerTrade /= 2; if(dBarsPerTrade < MIN_BARS_PER_TRADE) return(dBarsPerTrade-MIN_BARS_PER_TRADE + dRecoveryFactor); Print("Max number Of SL: ",DoubleToString(dMaxNumOfSL,1)); if(iIMaxNumOfSeqSLForQualify > 0 && dMaxNumOfSL > iIMaxNumOfSeqSLForQualify) { Print("Слишком много СЛ подряд !"); return(dRecoveryFactor - (dMaxNumOfSL-iIMaxNumOfSeqSLForQualify)*1000)-10000; }; Print("Bars Per Trade (half): ",DoubleToString(dBarsPerTrade,1)); if(dBarsPerTrade > MAX_BARS_PER_TRADE) { Print("Слишком редкие трейды !"); return(dRecoveryFactor - dBarsPerTrade/100); }; Print("Profit: ",DoubleToString(dProfit,3)); Print("Profit per day: ",DoubleToString(dProfitPerDay,3)); Print("Число СЛ: ",IntegerToString(uiTotalNumberOfSL)); Print("Приемлемая торговля."); return(dRecoveryFactor + (1-(uiTotalNumberOfSL/dNumOfTrades))*100);};在这里，它是基于恢复因子，但它突出了连续SL的最低数量和相当频繁的交易的运行。然而，在我看来--大多数人使用的是标准选项。 Your symbols and your SQLite: MQL5 原生 SQL 轻松快捷开发 MetaTrader 程序的函数库(第十四部分)：品种对象 1...456789101112131415161718...26 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我将添加另一个测试函数，包含两个均匀的最高值的高原。
z = abs(tanh(x) + tanh(y))
如果你将X,Y从-20改为+20，步长为0.1，那么完整的迭代需要160801次。
在测试中，这两个高原在1400次迭代中出现，这还不到完整搜索的百分之一。
有人会在GA上运行这个吗？有意思的是要进行比较。
我将添加另一个测试函数，包含两个均匀的最高值的高原。
z = abs(tanh(x) + tanh(y))
如果你将X,Y从-20改为+20，步长为0.1，那么完整的迭代需要160801次。
在测试中，这两个高原在1400次迭代中出现，这还不到完整搜索的百分之一。
有人会在GA上运行这个吗？有意思的是要进行比较。
你不是在用GA看吗？
用优化后的函数的两个参数来工作，一点也不说明问题。不仅是因为搜索空间小，而且还因为搜索算法本身的 "坏 "属性会出现。
将公式转换成至少有10个参数的形式，算法的所有正负属性都会显示出来。
你不是在找GA吗？
用一个优化的函数的两个参数来工作，一点也不说明问题。不仅是因为搜索空间小，而且还因为搜索算法本身的 "坏 "属性会出现。
将公式转换为至少10个参数的形式--算法的所有正负属性将一次性出现。
这不是GA，在这个主题里有一个文章的链接。
上面我贴了一个有六个参数的例子。显示大量参数的整个困难。
如果你建议一个有更多参数的函数--我将做一个测试。
如果你建议一个有更多参数的函数--我会做一个测试。
Y=a+b。
其中。
a=皮肤（x1，y1）+皮肤（x2，y2）+皮肤（x3，y3）+皮肤（x4，y4）+皮肤（x5，y5）。
b=皮肤（x6，y6）+皮肤（x7，y7）+皮肤（x8，y8）+皮肤（x9，y9）+皮肤（x10，y10）。
你已经知道在哪里可以找到 "皮肤 "功能。
所以有20个变量，Y函数非常容易可视化。你可以利用这一原则建立一个参数数量无限的函数，但仍然能够将其可视化。
而相应地，最后的结果是以Y*2/n与已知的极值进行核对，其中n是参数的总数。
你能给我一个算法的例子，在 "转向不足 "中，完全的转向过度只需十几个小时，而在MT中则需要几个月？
在这种方法中，传递的顺序非常重要，因为几乎所有的计算都是缓存的。对于TC的几乎每一个（所有独立的）输入参数，在优化器中总是有全局缓冲区来存储以前的值。
例如，你使用MA MA和PriceChannel。对于这些指标中的每一个都有自己独立的输入参数。这就是为什么我们为每个指标规定（实际上只有几行，用OOP应该更漂亮）函数来填充其全局缓冲区。然后我们比较每个指标的资源强度（PriceChannel比MA更重）。较重指标的输入参数在外部循环（第一个for）中开始列举，简单指标在内部循环（嵌套for）中列举。
这就是我们获得巨大收益的地方。此外，还有C++、整数计算和我们自己的订单系统，没有不必要的检查。这就是你如何得到的结果。因此，单次运行至少比MT快一个数量级。而且优化的速度也快了好几个数量级。
在MT-优化器中缺少的是OnOptimization功能，它可以提供对所获得的优化结果 矩阵的完全访问。我在那里对获得的矩阵进行各种分析：过滤，合并交易时间不重叠的订单，等等。但是，更有用的是计算每个通道的权重系数，以适当的投资组合形式组成一个元TS。为此，OnOptimization为每一个非 "无望 "的通行证都有一个向量-平等。
但是，在寻找工作中的TS的阶段，并没有发明底层测试者，而是当它已经被发现时，不幸的是。搜索本身是一个完全不同的阶段：没有描述。
有人会在GA上运行这个吗？有意思的是要进行比较。
Y=a+b。
其中。
a=皮肤（x1，y1）+皮肤（x2，y2）+皮肤（x3，y3）+皮肤（x4，y4）+皮肤（x5，y5）。
b=皮肤（x6，y6）+皮肤（x7，y7）+皮肤（x8，y8）+皮肤（x9，y9）+皮肤（x10，y10）。
你已经知道在哪里可以找到 "皮肤 "功能。
所以有20个变量，Y函数非常容易可视化。你可以利用这一原则建立一个参数数量无限的函数，但仍然能够将其可视化。
而相应地，最后的结果是以Y*2/n与已知的极值进行核对，其中n是参数的总数。
计算时要经过多少次，用哪一步的变量？
如果你不喜欢这幅画，谁会在乎呢？
MT5中的64位GA非常好，它可以解决任何问题，主要是要正确表述问题。
我不知道你在这个关于GA的主题中所说的书呆子是什么样的人。
我不认为问题出在GA上，但测试器本身是无用的，特别是在交易所，因为错误的报价历史存储和不可能保存自己的历史。
我希望这个问题能得到解决，但我恐怕要等上3-5年。
例如，你使用MA和PriceChannel。这些指标中的每一个都有自己独立的输入参数。因此，对于每个指标都有一个写好的（实际上只有几行，用OOP肯定更漂亮）函数来填充其相应的全局缓冲区。然后我们比较每个指标的资源强度（PriceChannel比MA更重）。较重的指标的输入参数在外部循环（第一个for）中开始列举，简单的指标在内部循环（嵌套for）中列举。
直觉告诉我，这种方法也可以在GA下轻松完成。工作量是差不多的。内循环 "每次都会通过...
但是，最重要的是--那会有多少需求？正如我猜想的那样，不是每个人都会使用甚至是简单的自定义OnTester()函数。但这是一个非常强大的优化工具。
例如，这里是我的一个实施方案。
double CDoublePeakBottomAdvisorPartsFactory::MyOnTester(CMyExpertT* pmeExpert)
{
ulong ulTickedTime = pmeExpert.GetTickedTime();
uint uiTotalNumberOfSL = pmeExpert.GetNumOfLosePositions();
double dDDPercent = TesterStatistics(STAT_EQUITY_DDREL_PERCENT);
double dStartBalance = TesterStatistics(STAT_INITIAL_DEPOSIT);
double dProfit = TesterStatistics(STAT_PROFIT);
double dNumOfTrades = TesterStatistics(STAT_TRADES);
double dNumOfProfitTrades = TesterStatistics(STAT_PROFIT_TRADES);
double dMaxNumOfSL = TesterStatistics(STAT_MAX_CONLOSS_TRADES);
double dRecoveryFactor = TesterStatistics(STAT_RECOVERY_FACTOR);
double dProfitTradesPerWeek = dNumOfProfitTrades/ulTickedTime*SECS_IN_WEEK;
double dProfitPerDay = dProfit/ulTickedTime*SECS_IN_DAY;
Print("Ticked time (days): ",DoubleToString(ulTickedTime/SECS_IN_DAY,2));
Print("Number Of Trades: ",DoubleToString(dNumOfTrades,1));
if(dNumOfTrades == 0)
{
Print("Ни одного трейда !");
return(-100000);
};
if(dMaxNumOfSL > uiIMaxNumOfSeqSL)
return(-10000 - dMaxNumOfSL*100 + dProfit/1000);
double dBarsPerTrade = ((double)ulTickedTime/PeriodSeconds(m_didData.m_etTimeFrame))/dNumOfTrades;
if((bILongAllow == false) || (bIShortAllow == false))
dBarsPerTrade /= 2;
if(dBarsPerTrade < MIN_BARS_PER_TRADE)
return(dBarsPerTrade-MIN_BARS_PER_TRADE + dRecoveryFactor);
Print("Max number Of SL: ",DoubleToString(dMaxNumOfSL,1));
if(iIMaxNumOfSeqSLForQualify > 0 && dMaxNumOfSL > iIMaxNumOfSeqSLForQualify)
{
Print("Слишком много СЛ подряд !");
return(dRecoveryFactor - (dMaxNumOfSL-iIMaxNumOfSeqSLForQualify)*1000)-10000;
};
Print("Bars Per Trade (half): ",DoubleToString(dBarsPerTrade,1));
if(dBarsPerTrade > MAX_BARS_PER_TRADE)
{
Print("Слишком редкие трейды !");
return(dRecoveryFactor - dBarsPerTrade/100);
};
Print("Profit: ",DoubleToString(dProfit,3));
Print("Profit per day: ",DoubleToString(dProfitPerDay,3));
Print("Число СЛ: ",IntegerToString(uiTotalNumberOfSL));
Print("Приемлемая торговля.");
return(dRecoveryFactor + (1-(uiTotalNumberOfSL/dNumOfTrades))*100);
};
在这里，它是基于恢复因子，但它突出了连续SL的最低数量和相当频繁的交易的运行。
然而，在我看来--大多数人使用的是标准选项。