Como se puede ver en la figura, sólo tres núcleos están trabajando, he visto más de una situación en la que durante las pruebas el número de núcleos que participan en el trabajo desciende gradualmente a cero, después de lo cual todos los núcleos comienzan a trabajar a la vez, es decir, hay un tiempo de inactividad, ¿por qué los núcleos liberados no comienzan a trabajar a la vez?
Para empezar a calcular la siguiente generación, primero debemos procesar la generación actual. Se deben completar todas las ejecuciones de la generación actual para seleccionar las mejores y realizar operaciones genéticas entre las mejores. Sólo entonces podrá iniciarse la siguiente generación.
Cuando faltan algunos resultados para completar el procesamiento de la generación actual, los agentes de prueba liberados se quedan sin trabajo.
Aquí se puede utilizar cualquier tiempo, pero en el probador el tiempo se tomará modulo 50 días. Aproximadamente 4 220 000 segundos.
La calidad de MQL5 es desmotivadora.
Puede fijar un máximo de 2 147 483 segundos (correspondientes a 35 791 minutos, 596 horas o 24 días). No es así como se maneja el temporizador en el probador.
Contrapregunta. ¿Por qué se ajusta el temporizador a 24 días?
Se puede ajustar un máximo de 2.147.483 segundos (correspondientes a 35.791 minutos, 596 horas o 24 días). No es así como se maneja el temporizador en el probador.
Contrapregunta. ¿Por qué se ha programado el temporizador para 24 días?
Quiero que la posición se cierre después de la apertura en el tiempo de 1 segundo a 10 años, dependiendo de algo.
Lo intenté de esta manera
request.type_time=ORDER_TIME_SPECIFIED; // El pedido será válido hasta la fecha de vencimiento request.expiration=1; //o TimeCurrent()+time; (int time=1;)
no funciona con los segundos.
Se ha evitado este problema con EventSetTimer( ). También está limitado a 24 días. Lo más importante es que no me esperaba semejante lío con el cronómetro. Deberías haber sido advertido. Oh, bueno.
Por cierto, ¿la hora del temporizador es la hora real del calendario o sólo la hora de la negociación? En otras palabras, inmediatamente después del fin de semana, ¿cuánto tiempo se muestra en el temporizador?
Nuevamente se ha reportado un caso de pérdida parcial de comunicación entre el terminal y el servidor. Construye 360. No se reciben cotizaciones, pero se actualiza la información sobre el tiempo y el volumen de las transacciones. Hay un círculo giratorio con sectores grises en el indicador de estado de la conexión. Hay mensajes en el registro:
2010.11.29 18:03:03 Operaciones '630031' : operación #2107036 compra 0.10 GBPUSD a 1.55387 realizada (basada en la orden #2157432) 2010.11.29 18:00:02 Operaciones '630031' : operación #2106895 compra 0.10 GBPUSD a 1.55341 realizada (basada en la orden #2157265) 2010.11.29 17:07:49 Red '630031': autorizado en MetaQuotes-Demo 2010.11.29 17:07:47 Red '630031': se ha perdido la conexión con MetaQuotes-Demo 2010.11.29 16:10:47 Red '630031': se ha desactivado la negociación - modo inversor 2010.11.29 16:10:47 Red '630031': terminal sincronizado con MetaQuotes Software Corp. 2010.11.29 16:10:47 Red '630031': autorizado en MetaQuotes-Demo 2010.11.29 16:10:45 Red '630031': se ha perdido la conexión con MetaQuotes-Demo
Observe que no hay ningún mensaje de "terminal sincronizado con MetaQuotes Software Corp." después de las 17:07:49, al mismo tiempo que se reportan nuevas operaciones.
Rosh: Сделайте прогоны с одинаковым количеством тиком и разным количеством сделок. Тогда можно сравнивать.
Aquí tienes.
Sistema de prueba (¡sea cual sea!): Windows XP SP3, Pentium 4, 3GHz, 1,25Gb de memoria
Todas las ejecuciones se realizaron con Alpari-Demo, GPBUSD M1, período 04.10.2010-05.11.2010 (1521376 ticks, 34194 barras) en modo Normal, cada tick, depósito 10000USD (por cierto, ¿de dónde sacaste 1000000USD depósito? Mi lista termina con 100000), apalancamiento 1:100. He construido un Asesor Experto que utiliza la peculiaridad de la cuenta Alpari-Demo - margen cero - para simplificar su construcción. Por cada tick, el Asesor Experto abre una orden de 0,1 lote en una dirección, hasta que alcanza la cantidad de operaciones especificada mediante el parámetro, el resto de los ticks se omiten. Así, la influencia del número de operaciones se minimiza (se obtuvo 1 operación en todas las ejecuciones de prueba). Por cierto, al final de cada prueba comprobamos el tiempo aproximado de formación del informe en el formato Open XML (no ha superado el umbral de paciencia hasta ahora). No se han tenido en cuenta las operaciones generadas por el probador al final de la prueba (una operación por ejecución).
Así:
La primera serie de pruebas de 10 a 100 operaciones con incrementos de 10 no son de interés debido al pequeño tiempo de prueba - tiempo de generación de ticks de 5359 a 6453.
La siguiente serie va de 100 a 1000 operaciones en incrementos de 100 (el resultado de 100 se toma de la serie anterior):
Transacciones
Tiempo, ms
Tiempo total, ms
Tiempo aproximado de formación del informe xlsx, seg.
Notas
100
6359
6813
5
Menos de 5 segundos
200
6172
6594
5
300
6875
7375
7
400
5734
6094
10
500
6109
6562
14
600
6281
6687
17
700
8016
8563
23
800
7281
7719
28
900
9047
9610
35
1000
8453
8812
44
Todo bien, pero el problema de la generación de informes está empezando a aparecer
Ashes: Todas las ejecuciones se realizaron con Alpari-Demo, GPBUSD M1, período 04.10.2010-05.11.2010 (1521376 ticks, 34194 barras) en modo Normal, cada tick, depósito 10000USD (por cierto, ¿de dónde sacaste el depósito de 10000USD?
No es un problema, la cantidad requerida puede ser introducida manualmente.
La serie final (más pruebas en este hardware es demasiado duro para mí;) de 1000 a 10000 en pasos de 1000:
Aquí es donde los frenos a los que Rosh se ha referido de forma cuestionada aparecen en todo su esplendor.
Los oficios
Tiempo, ms
Tiempo total, ms
Tiempo aproximado de generación del informe xlsx, en segundos.
Notas
1000
8453
8812
44
2000
26750
27266
159
3000
60782
61141
355
**
4000
125469
171391
480
Más de 480 segundos
**
5000
414609
459281
No hay datos
No hay generación de informes para ejecuciones superiores a 4000 transacciones
6000
600610
601094
No hay datos
7000
648234
675576
648234 675576 Sin datos
**
8000
1082437
1082796
1082437 1082796 Sin datos
9000
1465203
1508359
No hay datos
10000
1988031
2012500
No hay datos
Parafraseando a Rosh, como se puede ver en el diagrama, la dependencia del tiempo de prueba del número de RATEs NO es estrictamente lineal. Más bien, no es lineal en absoluto.
El resultado a 5.000 y 6.000 está probablemente un poco sobrevalorado, pero se puede ver una tendencia.
Quiero recordar que este resultado se obtuvo utilizando el Asesor Experto más simple que prácticamente no dedica tiempo a ningún análisis y no utiliza indicadores; es decir, los resultados serían aún peores en un EA que funcione.
Para comparar:
Ejecutar esta prueba con 10000 operaciones en una máquina Windows 7, Intel Pentium Dual-Core E5400 @ 2.70 GHz, 2038 MB (PR111) tomó 472866ms.
A la luz de lo anterior, existe cierta probabilidad de que algunos de los candidatos al Campeonato 2010 hayan sido injustamente eliminados debido a la barrera de los 15 minutos y a las peculiaridades del probador (si hubiera muchos tratos).
** - varias veces al final del probador, el gráfico del símbolo que muestra las operaciones no se mostró.
Como se puede ver en la figura, sólo tres núcleos están trabajando, he visto más de una situación en la que durante las pruebas el número de núcleos que participan en el trabajo desciende gradualmente a cero, después de lo cual todos los núcleos comienzan a trabajar a la vez, es decir, hay un tiempo de inactividad, ¿por qué los núcleos liberados no comienzan a trabajar a la vez?
Para empezar a calcular la siguiente generación, primero debemos procesar la generación actual. Se deben completar todas las ejecuciones de la generación actual para seleccionar las mejores y realizar operaciones genéticas entre las mejores. Sólo entonces podrá iniciarse la siguiente generación.
Cuando faltan algunos resultados para completar el procesamiento de la generación actual, los agentes de prueba liberados se quedan sin trabajo.
¿Cuál es el tiempo máximo que se puede establecer en EventSetTimer( )?
¿INT_MAX? Creo que no. No quiero investigarlo yo mismo y no está en la ayuda.
Aquí se puede establecer cualquier tiempo, pero en el probador el tiempo se tomará modulo 50 días. Aproximadamente 4 220 000 segundos.
La calidad de MQL5 me desmotiva.
Aquí se puede utilizar cualquier tiempo, pero en el probador el tiempo se tomará modulo 50 días. Aproximadamente 4 220 000 segundos.
La calidad de MQL5 es desmotivadora.
Puede fijar un máximo de 2 147 483 segundos (correspondientes a 35 791 minutos, 596 horas o 24 días). No es así como se maneja el temporizador en el probador.
Contrapregunta. ¿Por qué se ajusta el temporizador a 24 días?
Se puede ajustar un máximo de 2.147.483 segundos (correspondientes a 35.791 minutos, 596 horas o 24 días). No es así como se maneja el temporizador en el probador.
Contrapregunta. ¿Por qué se ha programado el temporizador para 24 días?
Quiero que la posición se cierre después de la apertura en el tiempo de 1 segundo a 10 años, dependiendo de algo.
Lo intenté de esta manera
request.type_time=ORDER_TIME_SPECIFIED; // El pedido será válido hasta la fecha de vencimiento
request.expiration=1; //o TimeCurrent()+time; (int time=1;)
no funciona con los segundos.
Se ha evitado este problema con EventSetTimer( ). También está limitado a 24 días. Lo más importante es que no me esperaba semejante lío con el cronómetro. Deberías haber sido advertido. Oh, bueno.
Por cierto, ¿la hora del temporizador es la hora real del calendario o sólo la hora de la negociación? En otras palabras, inmediatamente después del fin de semana, ¿cuánto tiempo se muestra en el temporizador?
Nuevamente se ha reportado un caso de pérdida parcial de comunicación entre el terminal y el servidor. Construye 360. No se reciben cotizaciones, pero se actualiza la información sobre el tiempo y el volumen de las transacciones. Hay un círculo giratorio con sectores grises en el indicador de estado de la conexión. Hay mensajes en el registro:
2010.11.29 18:03:03 Operaciones '630031' : operación #2107036 compra 0.10 GBPUSD a 1.55387 realizada (basada en la orden #2157432)
2010.11.29 18:00:02 Operaciones '630031' : operación #2106895 compra 0.10 GBPUSD a 1.55341 realizada (basada en la orden #2157265)
2010.11.29 17:07:49 Red '630031': autorizado en MetaQuotes-Demo
2010.11.29 17:07:47 Red '630031': se ha perdido la conexión con MetaQuotes-Demo
2010.11.29 16:10:47 Red '630031': se ha desactivado la negociación - modo inversor
2010.11.29 16:10:47 Red '630031': terminal sincronizado con MetaQuotes Software Corp.
2010.11.29 16:10:47 Red '630031': autorizado en MetaQuotes-Demo
2010.11.29 16:10:45 Red '630031': se ha perdido la conexión con MetaQuotes-Demo
Observe que no hay ningún mensaje de "terminal sincronizado con MetaQuotes Software Corp." después de las 17:07:49, al mismo tiempo que se reportan nuevas operaciones.
Rosh:
Сделайте прогоны с одинаковым количеством тиком и разным количеством сделок. Тогда можно сравнивать.
Aquí tienes.
Sistema de prueba (¡sea cual sea!): Windows XP SP3, Pentium 4, 3GHz, 1,25Gb de memoria
Todas las ejecuciones se realizaron con Alpari-Demo, GPBUSD M1, período 04.10.2010-05.11.2010 (1521376 ticks, 34194 barras) en modo Normal, cada tick, depósito 10000USD (por cierto, ¿de dónde sacaste 1000000USD depósito? Mi lista termina con 100000), apalancamiento 1:100. He construido un Asesor Experto que utiliza la peculiaridad de la cuenta Alpari-Demo - margen cero - para simplificar su construcción. Por cada tick, el Asesor Experto abre una orden de 0,1 lote en una dirección, hasta que alcanza la cantidad de operaciones especificada mediante el parámetro, el resto de los ticks se omiten. Así, la influencia del número de operaciones se minimiza (se obtuvo 1 operación en todas las ejecuciones de prueba). Por cierto, al final de cada prueba comprobamos el tiempo aproximado de formación del informe en el formato Open XML (no ha superado el umbral de paciencia hasta ahora). No se han tenido en cuenta las operaciones generadas por el probador al final de la prueba (una operación por ejecución).
Así:
La primera serie de pruebas de 10 a 100 operaciones con incrementos de 10 no son de interés debido al pequeño tiempo de prueba - tiempo de generación de ticks de 5359 a 6453.
La siguiente serie va de 100 a 1000 operaciones en incrementos de 100 (el resultado de 100 se toma de la serie anterior):
14
Todo bien, pero el problema de la generación de informes está empezando a aparecer
Todas las ejecuciones se realizaron con Alpari-Demo, GPBUSD M1, período 04.10.2010-05.11.2010 (1521376 ticks, 34194 barras) en modo Normal, cada tick, depósito 10000USD (por cierto, ¿de dónde sacaste el depósito de 10000USD?
La serie final (más pruebas en este hardware es demasiado duro para mí;) de 1000 a 10000 en pasos de 1000:
Aquí es donde los frenos a los que Rosh se ha referido de forma cuestionada aparecen en todo su esplendor.
**
Parafraseando a Rosh, como se puede ver en el diagrama, la dependencia del tiempo de prueba del número de RATEs NO es estrictamente lineal. Más bien, no es lineal en absoluto.
El resultado a 5.000 y 6.000 está probablemente un poco sobrevalorado, pero se puede ver una tendencia.
Quiero recordar que este resultado se obtuvo utilizando el Asesor Experto más simple que prácticamente no dedica tiempo a ningún análisis y no utiliza indicadores; es decir, los resultados serían aún peores en un EA que funcione.
Para comparar:
Ejecutar esta prueba con 10000 operaciones en una máquina Windows 7, Intel Pentium Dual-Core E5400 @ 2.70 GHz, 2038 MB (PR111) tomó 472866ms.
A la luz de lo anterior, existe cierta probabilidad de que algunos de los candidatos al Campeonato 2010 hayan sido injustamente eliminados debido a la barrera de los 15 minutos y a las peculiaridades del probador (si hubiera muchos tratos).
** - varias veces al final del probador, el gráfico del símbolo que muestra las operaciones no se mostró.
Interesting:
Это не проблема, нужная сумма может быть вбита руками.