任何想看没有缺失条形图的人--在这里=) - 页 9

新评论
 
我已经弄清楚了开发者禁止EA在离线图表上工作的原因。
我认为这与离线图表的买入价和卖出价返回0的事实有关，也就是说，对于想要在市场上开盘的专家顾问来说，这是不可能的。但我为我的EA想出了以下解决方案，该方案只适用于挂单：使用自动替换，改变_Bid()和_Ask()的Bid和Ask。_MarketInfo() 返回正在交易的工具的点差。

int _MarketInfo(string symb_for_work)
{
   if(symb_for_work=="USDCHFm") return(4);
   if(symb_for_work=="CHFJPYm") return(5);
   if(symb_for_work=="GBPUSDm") return(3);
   if(symb_for_work=="USDCADm") return(5);
   if(symb_for_work=="USDJPYm") return(3);
   if(symb_for_work=="EURGBPm") return(4);
   if(symb_for_work=="AUDUSDm") return(4);
   if(symb_for_work=="EURCHFm") return(4);
   if(symb_for_work=="EURJPYm") return(5);
   if(symb_for_work=="EURUSDm") return(2);
   if(symb_for_work=="NZDUSDm") return(6);
   if(symb_for_work=="AUDJPYm") return(6);   
 
return(0);
}
 
double _Bid()
{
   return(Close[0]);
}
 
double _Ask()
{
   return(Close[0]+_MarketInfo(symbol_for_trade)*Point);
}
我认为这个想法很清楚。从修订后的EA的第一个结果来看，订单正常打开。现在是周末，所以我将在下周开始交易时对其进行详细测试。我想我将能够实现我最初的愿望。
 
IMHO，胡说八道...
如果开发者看到 "对于离线图表，Bid和Ask返回0"。
是什么阻碍了他们的修复工作？
 

好吧，比如说，离线图表可以相当不频繁地更新。而在刷新间隔期间，例如1-2分钟，真实的卖出价和买入价可能与离线图表中显示的内容相差甚远。而RefreshRates()在这里完全没有帮助。那么，除了已经发现的原因之外，肯定还有其他一些原因。但只有开发者才能回答这个问题。

 
solandr:

好吧，比如说，离线图表可以相当不频繁地更新。而在刷新间隔期间，例如1-2分钟，真实的卖出价和买入价可能与离线图表中显示的内容相差甚远。而RefreshRates()在这里完全没有帮助。那么，除了已经发现的原因之外，肯定还有其他一些原因。但只有开发者才能回答这个问题。

对，如果图表不更新，投标就会变得过时。
但是，Close[0]也会这样!

你不能在交易专家顾问中使用明知错误的价格。
使用MarketInfo( MODE_BID )和MarketInfo( MODE_ASK )来获得一个新的价格 )
 

基本上，我对Close[0]相当满意;o)
我并不着急。我甚至故意放慢专家顾问的速度;o)根据以下原则：

1.如果当前价格 离提供者至少有50点的距离，只有在需要移动至少10点的情况下，提供者才能修改提供者的订单。
2.如果当前价格在距离 "Oder "25...50点的范围内，专家顾问只允许修改 "Oder"，如果有必要将订单修改5点或以上。
3.如果当前价格接近订单的25个点，专家顾问将把挂单移动2个点或更多。

这个方案让我们至少减少了5倍，甚至更多的挂单动作！"。:o) 结果是平均每小时从0（夜间）到20（新闻事件期间）的移动，总金额约为60个挂单（12种货币）!也就是说，每天可能不超过200个动作，而且不是每天都有。总的来说，我认为在手工交易中，如果人们完全遵循某种策略并使用相同数量的货币对进行交易，那么他们可以移动更多的订单!;o)

 

komposter，再次感谢你开发了一个专家顾问，将周日的蜡烛和周一的蜡烛合并在一起！！。
我已经用你的脚本做了一个月的真实工作。我启动脚本来处理19个货币对（都是InterbankFX提供的），每个货币对有600个盘面。 我将图表的刷新时间设置为1分钟。 在CPU VIA C3 800 MHz上，所有工作都很顺利

我注意到一个小特点，我想这是终端的特点，而不是专家顾问的特点，我个人对这个特点没有什么不满的地方在Metaeditor中工作时，我试图编译任何甚至没有连接到图表的EA，终端在其日志中产生错误。同时，这一事实在800MHz处理器以及P4 3GHz和Celeron 2GHz处理器上都显示得很稳定。建198。我没有在200上试过，因为InterbankFX的更新有一些问题（出现了更新请求，但构建没有下载 - 但这并不重要）。
******************************
2006.12.09 03:26:29 WithoutSunday_4:FileFlush 中无效的句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileWriteInteger中无效处理-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileSeek中无效的句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileFlush中无效手柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileWriteInteger中无效处理-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileSeek中无效的句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileFlush中无效手柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileWriteInteger中无效处理-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileSeek中无效的句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileFlush中无效手柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileWriteInteger中无效处理-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileSeek中无效的句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileFlush中无效手柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileWriteInteger中无效处理-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileSeek中无效的句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileFlush中无效手柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileWriteDouble中的无效句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4: 在FileWriteInteger中无效处理-1
2006.12.09 03:26:29 29 WithoutSunday_4: FileSeek中无效的句柄-1
2006.12.09 03:26:29 29 WithoutSunday_4 EURUSDm,Daily: Alert: FileOpenHistory("WS_AUDNZDm1440. hst", FILE_BIN | FILE_WRITE ) - Error #4102
2006.12.09 03:26:29: FileOpen - 已打开的文件太多
2006.12.09 03:26:29 29 WithoutSunday_4 EURUSDm,Daily: Alert: FileOpenHistory("WS_NZDJPYm1440. hst", FILE_BIN | FILE_WRITE ) - Error #4102
2006.12.09 03:26:29: FileOpen - 已打开的文件太多
2006.12.09 03:26:29 29 WithoutSunday_4 EURUSDm,Daily: Alert: FileOpenHistory("WS_AUDCADm1440. hst", FILE_BIN | FILE_WRITE ) - Error #4102
2006.12.09 03:26:29: FileOpen - 已打开的文件太多
2006.12.09 03:26:29:29 WithoutSunday_4 EURUSDm,Daily: Alert: FileOpenHistory("WS_EURCADm1440. hst", FILE_BIN | FILE_WRITE ) - Error #4102
2006.12.09 03:26:29: FileOpen - 已打开的文件太多
2006.12.09 03:26:29 29 WithoutSunday_4 EURUSDm,Daily: Alert: FileOpenHistory("WS_EURAUDm1440. hst", FILE_BIN | FILE_WRITE ) - Error #4102
2006.12.09 03:26:29: FileOpen - 已打开的文件太多
2006.12.09 03:26:29 29 WithoutSunday_4 EURUSDm,Daily: Alert: FileOpenHistory("WS_GBPCHFm1440. hst", FILE_BIN | FILE_WRITE ) - Error #4102
2006.12.09 03:26:29: FileOpen - 已打开的文件太多
*****************************

通常情况下，在它出现后，我只需重新启动终端，一切都会继续24小时正常工作!
我写这个只是为了提供信息，而不是让你去尝试处理这个问题。我认为你离不开开发商的帮助。

我写信给你，提出以下请求。本分支中提到的用于计算线性和抛物线回归的专家顾问，是基于该脚本生成的报价而工作的。回归计算是基于平均的条形参数，即以（O+H+L+C）/4的值作为参考值。但从我的长期观察来看，我想这种（O+H+L+C）/4读数的模式并不十分成功。我为在95%的置信水平的边界上开出的订单设置了止损，在99.9%的边界上开出的订单。然而，在有些情况下，价格超过99.9%的置信区间的边界只有几个点。同时，根据统计数据，这类案件的数量超过了允许的数值!这就是为什么我真的想检查我的假设，如果我们以高点和收盘价的模型作为计算的基础，这个极限在统计上会更准确。专家顾问非常笨重--在一个mq4文件中为184kB。有很多地方都引用了引文。如果我为一个新的模型修正EA，那么除了劳动密集型的事实之外，还很有可能在一个相当复杂的计算算法中引入错误，而在我看来，这个算法已经经过了很好的测试，而且运行可靠。

这就是为什么我想请你改进上一版本的脚本，使它能从收到的日线蜡烛图中形成H12时期的报价。
在00:00开盘的H12条应该有初始日线的O=H=L=C=Low的值。
在12:00开盘的H12栏应该有O=H=L=C=初始日栏的高值。
另外，专家顾问应该能够交换数值，即H12栏在00:00时=初始日栏的高点，H12栏在12:00时=初始日栏的低点。
在实时图表更新期间，专家顾问应该在不处理的情况下传递当天的最后一个H12条，即每个H12条的O、H、L、C的当前值。
所述的条形图处理应该只在每日蜡烛收盘后进行，当收盘日的H12条形图没有更多的变化。
如果你能根据描述的方法帮助我改进现有的脚本，它将大大加快检查高-低模型在渠道创建方面的统计分析。我承诺将在这里介绍比较的结果。我想对于许多对统计数据处理感兴趣的人来说，阅读这些文章会很有意义。 提前感谢你们！!

 
solandr:

InterbankFX在更新方面有一些问题（出现了更新邀请，但没有下载构建 - 但这并不重要）。

从新的真实服务器来看，它确实没有更新。使用liveupdate演示服务器，它的连接没有问题。
 

就我而言，我将首先尝试单独检查仅高位和低位的通道计算。我将看到结果。如果使用不同的样本得到的通道在长度上是一致的，我们也许可以不为H12时期编写新的脚本。也就是说，我们将使用High的数据作为通道的上界，而Low的数据作为下界。如果一切都可以在我的EA中更容易地解决，也许我的要求让你白费力气了？我认为在我的专家顾问中实施它并不困难。

 
komposter 我在这里遇到一个问题，你能告诉我怎么做吗？ 所有的细节都在这里http://forum.kimiv.ru/viewtopic.php?t=177
 
solandr:

我注意到一件小事，我想这是终端的一个特点，而不是EA的特点，我个人对此没有什么不满！"。当Expert Advisor运行时，我在Metaeditor中编译任何EA，甚至没有附加到任何图表上，终端日志中出现了一个错误。

对不起，我已经很久没有回信了--刚刚度假回来......

在我看来，问题在于EA并没有关闭打开的文件。问题是为什么它不这样做=)
唯一的假设是，在编译过程中，工作中的EA的启动功能被强行停止。

而在下一次 "启动 "时，文件被重新打开，但 "没有足够的空间"（最多32个打开的文件）。

Expert Advisor本身并没有很好地处理这种情况--即使一个文件没有打开，它仍然试图向那里写数据。
修正了它--增加了一行 =)
if ( HistoryHandle[curChart] < 0 ) continue;


attached Expert Advisor.



关于H12图表。"有时间但没钱 "不是说我= =。）
虽然我也有这2个价值成反比的情况--自由时间越多，钱就越少，反之亦然。

目前，我不能做慈善工作--我有太多的工作。
而该论坛有5页（*30个主题）未读....
附加的文件：
withoutsunday.mq4  12 kb
123456789101112
新评论