Biblioteca de clases genéricas - errores, descripción, preguntas, características de uso y sugerencias - página 12
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
¿Entiendes qué hace el código si no hay una implementación explícita de la funciónGetHashCode para el tipo T?
Respuesta: es una putada porque se silencia el problema de la falta de aplicación. Todos los objetos de la misma clase devolverán el mismo valor hash.
¿Qué tiene que ver la implementación (el cuerpo)? He añadido esto.
Introduje el cuerpo de la bola.
¿Qué tiene que ver la implementación (el cuerpo)? He añadido esto.
Puse la carrocería desde cero.
Te hablan de las moscas (que no debes hacer eso, el código puede enfermarte en el futuro) y sigues con las chuletas.
Bien, tened buen apetito.
Decidí mirar las características de velocidad de la solución propuesta. Asesoramiento experto para el probador
El Asesor Experto abre 100.000 operaciones y luego busca los beneficios totales de las operaciones al azar utilizando varios métodos (ver comentarios). El resultado es
Aquí comparamos los dos valores destacados. Resulta que el acceso al HashMap es 4 veces más rápido que el de los desarrolladores. Pero en los desarrolladores ya incluye la historia...
¿Es 4 veces más rápido o no es suficiente para esta situación? Pues aquí son 24 milisegundos. Si accede mucho al historial, probablemente podría ahorrar mucho. Pero no estoy seguro.
Para un caso de prueba más realista (2.000 operaciones y 1.000.000 de accesos al historial), el resultado es el siguiente
Se ahorran casi 100 mseg por pasada. Si, por ejemplo, hacemos Optimizar para 10.000 pases completos, la variante Hash acabará siendo 15 minutos más rápida.
Es demasiado pronto para dar a los desarrolladores un sobresaliente en Historia. Es obvio que pueden acelerarlo, ya que incluso la solución MQL es cada vez más rápida.
Decidí mirar las características de velocidad de la solución propuesta. Asesoramiento experto para el probador
El Asesor Experto abre 100.000 operaciones y luego busca los beneficios totales de las operaciones al azar utilizando varios métodos (ver comentarios). El resultado es
Aquí comparamos los dos valores destacados. Resulta que el acceso al HashMap es 4 veces más rápido que el de los desarrolladores. Pero en los desarrolladores ya incluye la historia...
¿Es 4 veces más rápido o no es suficiente para esta situación? Pues aquí son 24 milisegundos. Si accede al historial muchas veces, probablemente podrá ahorrar mucho dinero. Pero no estoy seguro.
En las llamadas a través de la plataforma, se pasa a través de objetos de sincronización dos veces en GetDealProfitFull y una vez en GetDealProfitClear y un montón de comprobaciones obligatorias en cada iteración.
Así que la velocidad es notoriamente más lenta que en limpio y optimizada con un montón de incrustaciones que trabajan en un hashmap local pre-preparado.
Cuando se llama a través de la plataforma, se pasa a través de objetos de sincronización dos veces en GetDealProfitFull y una vez en GetDealProfitClear y un montón de comprobaciones obligatorias en cada iteración.
Por lo tanto, la velocidad es intrínsecamente más lenta que en un trabajo limpio y optimizado basado en un hashmap local preliminarmente preparado con un montón de incrustaciones.
Corregido mi post anterior. Por eso el doble control se llama Full.
No entiendo muy bien de qué costosos objetos de sincronización y muchas comprobaciones estamos hablando en el Probador de Estrategias para HistoryDealGetDouble?Corregido mi post anterior. La doble comprobación es la razón por la que se llama Full.
No estoy muy seguro de qué costosos objetos de sincronización y masas de comprobaciones habla el Probador para HistoryDealGetDouble?Cuál es la diferencia:
He mirado nuestro código - hay una manera de optimizar las llamadas a la base comercial. Intentaremos implementarlo para el lanzamiento de la próxima semana.
Renat Fatkhullin:
En la plataforma, al extraer un solo valor, hay que tratar la consulta "como si fuera la primera vez", comprobando dos veces la corrección y la presencia de todos los datos
¿Pero no se llama a TryGetValue sin comprobar si es correcto? Según los registros, se puede ver que HistorySelect en el probador es libre.
Lo que no entiendo es por qué para obtener todos los datos de una operación hay que llamar a un montón de caras funciones HistoryDealGet*. Sólo hay una llamada para llenar la estructura MqlDeal.
Obviamente, el usuario, cuando quiera trabajar con el historial a través del HashMap, rellenará el CHashMap<ulong, MqlDeal>.
¿Tal vez deberíamos hacer MqlDealInteger, MqlDealDouble, MqlDealString o algo similar, para no multiplicar las costosas llamadas a la unidad, ya que toda la tabla del historial está en el probador de todos modos? Y es suficiente con comprobar la corrección del DealTicket una vez, no cada vez.
¿No se hace la llamada TryGetValue para comprobar la corrección? Según los registros, se puede ver que HistorySelect está libre en el probador.
Lo que no entiendo es por qué para obtener todos los datos de una operación hay que llamar a un montón de caras funciones HistoryDealGet*. Sólo hay una llamada para llenar la estructura MqlDeal.
Obviamente, el usuario, cuando quiere trabajar con el historial a través de HashMap, rellena el CHashMap<ulong, MqlDeal>.
No tenemos una estructura MqlDeal porque los formatos de los registros comerciales son flotantes y se expanden periódicamente. Sin ella, es imposible ampliar la funcionalidad de la plataforma.
Por lo tanto, la única opción es acceder a ellos a través de la función Get. Y el acceso a otros campos del registro al que se ha accedido anteriormente es mucho más rápido que el primer acceso, porque el registro se almacena en la caché.
Y es suficiente para comprobar la corrección entonces DealTicket una vez y no cada vez.
En la prueba anterior, cada vez el número de ofertas es nuevo, lo que interrumpe constantemente el caché de la oferta seleccionada anteriormente. Además, no hay garantía de que algo no haya cambiado entre las llamadas. Todavía se puede intercambiar entre las solicitudes de la historia.
¿Cómo es que es gratis? No es gratis en absoluto.
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Biblioteca de clases genéricas - errores, descripción, problemas, casos de uso y sugerencias
fxsaber, 2017.12.08 22:46
El asesor abre 100.000 operaciones, luego busca el beneficio total de las operaciones al azar utilizando diferentes métodos (ver comentarios). Resultado
Por cada 100.000 operaciones (y el mismo número de órdenes) 1 microsegundo es gratis. Todo depende del probador.
En la prueba anterior, los números de las ofertas son nuevos cada vez, lo que interrumpe constantemente el caché de las ofertas previamente seleccionadas. Además, no hay garantía de que algo no haya cambiado entre las llamadas. Puede intercambiar entre las solicitudes de la historia.
Así, el historial (especialmente en el probador) sólo se complementa, los registros antiguos no se modifican. Se trata de la variante Clear.
En el mercado real, parece que incluso cuando una orden se ejecuta parcialmente y genera varias operaciones, no llega al historial hasta que se ejecuta completamente o se cancela. Es decir, se mantiene la regla de la historia congelada.
Para 100.000 operaciones (y el mismo número de órdenes) 1 microsegundo es gratis. Todo gira en torno al probador todo el tiempo.
HistorySelect en el probador es absolutamente virtual/falsa, más aún con los parámetros 0, INT_MAX. Esto se optimizó hace mucho tiempo.
No se puede comparar HistorySelect(pone el rango de acceso en el probador) e HistoryDealSelect(ticket), que realmente busca un ticket específico y lo almacena en caché.