Si MetaTrader 6 sale mañana - página 3
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
Quiero opciones a MT, con todos los deltas y engaños.
Me gustaría que el probador se dividiera en dos partes, probador-optimizador rápido y probador-depurador preciso (debería incluir también el visualizador).
El optimizador sólo comprueba la rentabilidad de las señales de los indicadores, el depurador comprueba la precisión de la ejecución.
Parece que es necesario separarlos hace mucho tiempo, incluso sin el depurador. // El uso del probador y del optimizador desde un mismo botón es un coñazo, la usabilidad es baja.
¿Qué puede aportar en la práctica?
1. pruebas hasta el minuto actual.
Si es comprensible limitar el optimizador de esta manera, ¿por qué limitar las pruebas?
Creo que ahora se debe al excesivo pegado de probador+optimizador, estoy empezando a ver todo tipo de horrores de la serie:
"Renat: - ¿Sugieres inundar servicedesk con peticiones que los resultados de la optimización no coinciden con los resultados de las pruebas?" :)))
2. La posibilidad de probar a fondo las implementaciones individuales de los conjuntos de parámetros sin interrumpir el proceso de optimización, una característica muy útil.
3. Por último, llame para probar y optimizar directamente desde los Asesores Expertos que trabajan en los gráficos (desde MQL).
El último argumento "en contra" mencionado por los desarrolladores: "¿Cómo probar los EA autooptimizados? Cuando el comprobador y el optimizador se implementan por separado, la recursividad se evita fácilmente prohibiendo que el optimizador llame al comprobador, pero permitiendo que el optimizador sea llamado desde el comprobador.
4,5,6.... Puedo dar muchos más argumentos, pero cualquiera de ellos será suficiente.
Y también desde hace mucho tiempo hay una solicitud para hacer el análisis Walk-Forward en el probador.
Por ejemplo, en C#. Al intentar enlazar una función o una variable, el compilador generará un error, porque la función o la variable son conceptos de un nivel inferior y sólo pueden colocarse dentro de una clase o estructura. Y en MQL5, parece haber cierta confusión - hay clases, pero también hay funciones que llaman a estas clases, y debería ser al revés: muchas clases se comunican entre sí a través de métodos soportados por ellas.
1 Gráficos. Mejorar la usabilidad de la carta, los objetos gráficos... Quiero una sombra para las etiquetas de texto. Y estilos con puntos para ser dibujados con puntos... Y ventanas de gráficos que se dibujan detrás del terminal, y ventana de propiedades que se estiran, y pestañas que se arrastran en la ventana de mercado. Eso es todo.
2 Historial personalizado.
3 CCA, Si se hace
Realizar la formación de NS en un probador.
Me gustaría ver una cosita así como eventos de clic de ratón o pulsación de teclas, además de los eventos de pulsación ya existentes.
Esto es superficial. Necesito ventanas normales manejadas por MQL, diálogos estándar de Windows y medios para su edición visual. Naturalmente, con un manejo completo de todos los eventos del usuario.
Lo ideal sería que toda la interfaz del terminal se implementara en mql6. Entonces los desarrolladores seguramente no echarán de menos consultas tan claras del programador a las funciones de la interfaz.