Librerías: MT4Orders Informe rápido - página 6
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
La información sobre la reducción máxima de largo es interesante. Lo hice para todo el array de cadenas. Todavía no he actualizado el código en el sitio.
Pero no está muy claro para qué sirve la fecha. Si hacemos un punto de división en back / forward pruebas (como he sugerido), entonces tenemos que calcular las estadísticas sobre ellos por separado en 2 tablas (períodos max drawdown estará allí también).
He hecho un cálculo completo de las estadísticas para back / forward pruebas
El archivo ha sido actualizado..
Lo que no queda muy claro con la fecha es para qué sirve.
Si quieres verlo a partir de 2020, eres bienvenido. Desde 2023, no hay problema. Es que a veces da igual lo que fuera en 2010. Y muestra que la mayor duración fue en 2010.
Establecer una fecha Forward ayudaría a separar las estadísticas.
Ah - entendí el punto. No para un probador con un experto/estrategia, sino para una cuenta real donde se probaran diferentes ideas.
Yo lo usaría sólo para un probador. Drawdowns reales no son interesantes en absoluto.
¿Qué tiene de malo?
Un estilo potencialmente peligroso. Por ejemplo, algún tiempo después querrás escribir tu propia función personalizada de formateo de fechas y su llamada se escribirá en una línea superlarga por costumbre:
Pero no hay garantía de que se llame a Format-ids después de MaxLengthDD, sólo porque aparezcan a la derecha entre los sumandos.
En principio, un registro superlargo de una línea tiene aspectos negativos: es difícil de leer y entender (de hecho, es difícil repetir en tu mente el análisis sintáctico de una expresión como hace un compilador, pero un humano no es un compilador al fin y al cabo), es difícil de depurar. Y un registro tan compacto tampoco aporta ninguna ganancia en rendimiento.
¡Superbiblioteca! ¡Gracias al autor!
Sugerencias de mejora:
- ocultar el gráfico interactivo (o añadir otro mecanismo para esto) al hacer clic en el gráfico de nuevo,
- guardar la fuente en UTF-8, para que pueda ser leída normalmente por GitHub (esto es un evento de una sola vez, que no amenazará nada, pero añadirá comodidad)
- comprobar el nombre de archivo de caracteres prohibidos (\ / / : * ? ? " < > | : :), y sustituirlos por algo neutro (-, por ejemplo)
- añadir un parámetro para guardar los informes en la carpeta común de los terminales, para no tener que buscarlos en las carpetas de los agentes.
Gracias de nuevo, ¡una herramienta muy útil!
Gracias de nuevo, ¡una herramienta muy útil!
Añadido 2 nuevos parámetros a la llamada
common_path - guardar en la carpeta común del terminal. Para evitar que los ficheros sean sobreescritos por otro agente durante la optimización, añadido el número de agente (3000, 3001,...) a los nombres de los ficheros. Cuando se guardan en la carpeta tester (false), se guardan en la carpeta del agente que realizó los cálculos.
fileANSI - guardar en codificación ANSI o en UNICODE. El tamaño de los archivos UNICODE es 2 veces mayor y tardan más en procesarse, por lo que si se cargan muchos datos, por ejemplo 1 GB, es más económico utilizar ANSI. UNICODE se añade por compatibilidad con servicios de terceros si lo necesitas.
También se añaden el comprobador de caracteres y el botón de ocultar, pero no los he descrito.
Añadidos 2 nuevos parámetros a la llamada
Así es como se añadirán nuevos parámetros. Por eso es mejor escribir la firma una vez, donde se introduce la estructura de las condiciones. Entonces la firma no cambiará. Eso es lo que hice en Informe.
Probablemente sea mejor. Pero ya es necesario mantener el esquema de llamada actual, por compatibilidad con los programas ya hechos que utilizan la biblioteca, para que alguien no tenga que editar el código.
La sobrecarga ayudará.