错误、漏洞、问题 - 页 1861

新评论
 

另一个问题--没有旗帜是正常的吗？ 构建1585

阿尔帕里


凤凰网



FxOpen阿尔帕里MQ
COPY_TICKS_INFO
Bid and/or Ask		930168391679292
COPY_TICKS_TRADE
Last and Volume		2710610102924
COPY_TICKS_ALL
all ticks		364077426568182216

如果各地的COPY_TICKS_ALL =COPY_TICKS_INFO +COPY_TICKS_TRADE

那么它在Alpari等于什么？

 
kaus_bonus:

阿尔帕里

凤凰网

他们没有脚蹼。
 
fxsaber:
他们没有旗帜。


这很清楚，但接下来要添加什么才能得到COPY_TICKS_ALL？

因为他们有COPY_TICKS_TRADE=0

而故事中缺少标志的刻度线是未知的COPY_TICKS_TRADE ?

 
kaus_bonus:


这很清楚，但接下来要添加什么才能得到COPY_TICKS_ALL？

因为他们有COPY_TICKS_TRADE=0

而历史上缺少标志的蜱虫是未知的COPY_TICKS_TRADE ?

我想这是经纪人的歪手。
 

就性能而言，HistoryDealGet*和HistoryOrderGet*-函数写得非常奇怪。

当我做HistorySelect时，比如说，对于100K的个人记录。HistoryDealGet-function应要求第一个参数不是历史表中的记录数，而是一张票。而且该表是按时间排序的，而不是按票据排序。因此，HistoryDealGet函数每次执行时做的第一件事是运行该表并寻找一个匹配的票据。


为什么如此浪费资源！？事实证明，最开始的票据和最近的票据将以不同的速度执行。而为了获得最后一笔交易的所有特征，HistoryDealGet-functions每次都会跑遍整个表格。


为什么不把它变成正常的呢？

long HistoryDealGetInteger( const int index, const ENUM_ORDER_PROPERTY_INTEGER  property_id ); // номер сделки, а не тикет


如果为了获得当前头寸的佣金数额，我们每次都需要通过HistorySelect进入慢速历史，而不是通过HistorySelectByPosition，我们怎么能测试HFT机器人呢？ 挂单的滑点变成了性能垃圾！这是不可能的。

 

测试器中的ACCOUNT_PROFIT显示为无稽之谈。

运行专家顾问，立即开仓和平仓

#include <MT4Orders.mqh>

#define  PRINT(A) Print(#A + " = " + (string)(A));

void OnTick()
{  
  static bool FirstRun = true;

  if (FirstRun && OrderSelect(OrderSend(_Symbol, OP_BUY, 1, 0, 0, 0, 0), SELECT_BY_TICKET))
  {
    PRINT(AccountInfoDouble(ACCOUNT_PROFIT))
    
    if (OrderClose(OrderTicket(), OrderLots(), 0, 0) && OrderSelect(OrdersHistoryTotal() - 1, SELECT_BY_POS, MODE_HISTORY))
      OrderPrint();
    
    FirstRun = false;          
  }
}

其结果是

2017.04.19 23:24:50.317 RTS-6.17,M1 (MetaQuotes-Demo): generating based on real ticks
2017.04.19 23:24:50.317 RTS-6.17,M1: testing of Experts\fxsaber\Test2.ex5 from 2017.04.06 00:00 to 2017.04.08 00:00 started
2017.04.19 23:24:50.419 RTS-6.17 : real ticks begin from 2017.04.06 00:00:00
2017.04.19 23:24:50.419 2017.04.06 09:45:01   deal #2  buy 1.00 RTS-6.17 at 114250 done (based on order #2)
2017.04.19 23:24:50.419 2017.04.06 09:45:01   deal performed [#2  buy 1.00 RTS-6.17 at 114250]
2017.04.19 23:24:50.419 2017.04.06 09:45:01   order performed buy 1.00 at 114250 [#2  buy 1.00 RTS-6.17 at 114250]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   AccountInfoDouble(ACCOUNT_PROFIT) = 0.0
2017.04.19 23:24:50.421 2017.04.06 09:45:01   exchange sell 1.00 RTS-6.17 at 114200, close #2 (114200 / 114250)
2017.04.19 23:24:50.421 2017.04.06 09:45:01   deal #3  sell 1.00 RTS-6.17 at 114200 done (based on order #3)
2017.04.19 23:24:50.421 2017.04.06 09:45:01   deal performed [#3  sell 1.00 RTS-6.17 at 114200]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   order performed sell 1.00 at 114200 [#3  sell 1.00 RTS-6.17 at 114200]
2017.04.19 23:24:50.421 2017.04.06 09:45:01   #3 2017.04.06 09:45:01 buy 1.00 RTS-6.17 114250 0 0 2017.04.06 09:45:01 114200 0.00 0.00 -56.44 0
2017.04.19 23:24:50.629 RTS-6.17,M1: 582089 ticks, 1573 bars generated. Environment synchronized in 0:00:00.063. Test passed in 0:00:00.421 (including ticks preprocessing 0:00:00.078).

ACCOUNT_PROFIT显示为零，但实际上是-56.44。因此，权益、缩减等的估计是不正确的。

PositionGetDouble(POSITION_PROFIT) - 同样的事情。

 
fxsaber:

如果为了知道当前头寸的佣金大小，你需要通过HistorySelect而不是 每次都通过HistorySelectByPosition 进入历史，那么如何测试HFT机器人呢？ 为了看到挂单的滑点，变成了一个性能垃圾！这是不可能的。

HistorySelect是否通过对请求的时间间隔进行二进制搜索来工作？即O(N)或O(log(N))？
 
fxsaber:
HistorySelect是否通过对请求的时间间隔进行二进制搜索来工作？即O(N)或O(log(N))？
不，二进制搜索在这种情况下是不适用的
 
Slawa:
不，二进制搜索在这种情况下是不适用的
所以在内部，两个故事（订单和交易）都是按时间排序的。我们谈论的是HistorySelect，而不是HistorySelectByPosition，后者根本就没有被优化。
 
fxsaber:
所以在内部，两个故事（订单和交易）都是按时间排序的。

对不起，我有点激动了。

是的，它们是按时间排序的。最初的记录是用二进制搜索的。

1...185418551856185718581859186018611862186318641865186618671868...3184
新评论