Errores, fallos, preguntas - página 1861

Nuevo comentario
 

otra pregunta - ¿es normal que no haya banderas? build 1585

Alpari


fxopen



FxOpenAlpariMQ
COPY_TICKS_INFO
Oferta y/o demanda		930168391679292
COPY_TICKS_TRADE
Última y volumen		2710610102924
COPY_TICKS_ALL
todos los ticks		364077426568182216

si en todas partesCOPY_TICKS_ALL =COPY_TICKS_INFO +COPY_TICKS_TRADE

entonces, ¿a qué equivale en Alpari?

 
kaus_bonus:

Alpari

fxopen

No tienen aletas.
 
fxsaber:
No tienen banderas.


está claro, pero entonces ¿qué se añade para obtenerCOPY_TICKS_ALL?

porque tienenCOPY_TICKS_TRADE=0

y los ticks de la historia con las banderas que faltan son los desconocidosCOPY_TICKS_TRADE ?

 
kaus_bonus:


está claro, pero entonces ¿qué se añade para obtenerCOPY_TICKS_ALL?

porque tienenCOPY_TICKS_TRADE=0

y los ticks en el historial con banderas que faltan es desconocidoCOPY_TICKS_TRADE ?

Creo que son las manos torcidas de los corredores.
 

Las funciones HistoryDealGet* e HistoryOrderGet* están escritas de forma muy extraña, en términos de rendimiento.

Cuando hago HistorySelect, por ejemplo, para 100K registros individuales. La función HistoryDealGet requerirá como primer argumento no el número de registros de la tabla de historial, y un ticket. Y la tabla está ordenada por tiempo, y no por billete. Por lo tanto, lo primero que hace la función HistoryDealGet, cada vez que se ejecuta, es recorrer la tabla y buscar un ticket que coincida.


¡Por qué tal desperdicio de recursos! Resulta que el primer billete y el más reciente se ejecutarán a diferentes velocidades. Y para obtener todas las características del último trato, HistoryDealGet-functions recorrerá toda la tabla cada vez.


¿Por qué no hacerlo normal?

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


¿Y cómo podemos probar el HFT-robot, si para obtener el importe de la comisión de la posición actual, tenemos que subir al historial lento cada vez a través de HistorySelect, y en ningún caso a través de HistorySelectByPosition? El deslizamiento de la orden pendiente se convierte en una basura de rendimiento!

 

ACCOUNT_PROFIT en el probador muestra una tontería.

Ejecuta el Asesor Experto que abre y cierra la posición inmediatamente

#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;          
  }
}

El resultado es

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 muestra cero, pero en realidad es -56,44. Como consecuencia, la equidad, la reducción, etc. se estiman incorrectamente.

PositionGetDouble(POSITION_PROFIT) - lo mismo.

 
fxsaber:

¿Y cómo se puede probar un robot HFT, si para saber el tamaño de la comisión de la posición actual, se necesita entrar en el historial a través de HistorySelect y no a través de HistorySelectByPosition cada vez? Ver el deslizamiento de una orden pendiente se convierte en una basura de rendimiento!

¿Funciona HistorySelect mediante una búsqueda binaria del intervalo de tiempo solicitado o no? ¿Es decir, O(N) u O(log(N))?
 
fxsaber:
¿Funciona HistorySelect mediante una búsqueda binaria del intervalo de tiempo solicitado o no? ¿Es decir, O(N) u O(log(N))?
No. La búsqueda binaria no es aplicable en este caso
 
Slawa:
No. La búsqueda binaria no es aplicable en este caso
Así que internamente ambas historias (Pedidos y Tratos) están ordenadas por tiempo. Estamos hablando de HistorySelect, y no de HistorySelectByPosition, que no está optimizado en absoluto.
 
fxsaber:
Así que internamente ambas historias (Pedidos y Tratos) están ordenadas por tiempo.

Lo siento, me emocioné un poco.

Sí, están ordenados por tiempo. El registro inicial se busca con una búsqueda binaria.

1...185418551856185718581859186018611862186318641865186618671868...3187
Nuevo comentario