Errores, fallos, preguntas - página 1861
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
otra pregunta - ¿es normal que no haya banderas? build 1585
Alpari
fxopen
Oferta y/o demanda
Última y volumen
todos los ticks
si en todas partesCOPY_TICKS_ALL =COPY_TICKS_INFO +COPY_TICKS_TRADE
entonces, ¿a qué equivale en Alpari?
Alpari
fxopen
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 ?
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 ?
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?
¿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
El resultado es
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.
¿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))?
No. La búsqueda binaria no es aplicable en este caso
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.