¿La desaceleración lineal es un error de programación o una característica de MT4? - 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
Hay que dejar de perder el tiempo y empezar de una vez a desarrollar. Redactar los TdR.
El cliente quiere una solución, no un simple plazo.
Ya te ha explicado una persona experimentada por enésima vez que en este código, en una pasada de la función start
32 ciclos "para"
17 veces se escanean las órdenes (tanto las abiertas como las históricas),
24 llamadas de la función de borrado de órdenes pendientes, que también tiene un ciclo para todas las órdenes (* número de órdenes)
7 llamadas de la función de supresión de órdenes de mercado con el mismo ciclo para todas las órdenes (*número de órdenes)
6 modificaciones de Límites con ciclos dentro (* número de pedidos)
6 modificaciones de órdenes de stop con ciclos dentro (* número de órdenes)
10 llamadas a la función de pedido con ciclos dentro (*número de pedidos)
37 veces que imprime (Print),
7 (siete) veces se accede al historial completo de bares de todo el historial (y va creciendo durante la prueba).
Y lleva mucho tiempo.
Ni siquiera estoy hablando de filtros "if" no optimizados, condiciones complicadas en ellos (y no hay comprobación abreviada en MT4).
Y después de eso puedes cerrar los ojos ante un código absolutamente ilegible, no es importante, al menos puedes pasarlo por un estilizador y conseguir algo (aunque personalmente no me gusta su estilo):
¡Puedo repetirlo, pero! El primer y probablemente principal problema es que el código es ilegible y desestructurado. Es posible que tenga unos TdR bastante claros. Si se entienden los TdR y se escribe el código correctamente, (por regla general) se obtiene un beneficio considerable en cuanto a la velocidad de ejecución, pero también cuesta algo de dinero.
La conclusión es que se necesita un llamado diagrama de flujo, que le mostrará lo que se está ejecutando innecesariamente. Para los programadores principiantes (léase "traders") sería conveniente ver dicha visualización de código mediante el programa MT4.
La optimización más sencilla, a mi entender, es sistematizar el código de trabajo con las órdenes, es decir, hacer sólo 2 peticiones principales por barra y adicionalmente por 1 tick, si las condiciones del ToR requieren trabajar con las órdenes cuando se dan ciertas condiciones, como resultado recibiremos
1. Comprobar las condiciones para modificar/cerrar una orden cuando se abre una nueva barra;
2. modificar/cerrar la orden
3. Comprobar las condiciones de apertura de una nueva orden cuando se abre una nueva barra
3. Abrir un nuevo pedido
5. Comprobación de las condiciones para la actualización de la barra en cada tick
6. Modernización/Cierre de una orden cuando se cumple la condición 5.
Pero un programador me ha dicho que el código se ejecutará en cada tick de todas formas (comprobación de conformidad completa de la orden, y no sólo esa parte, que debería comprobarse en cada tick), ¿no se puede solucionar de alguna manera?
¿La función "imprimir" ralentiza el Asesor Experto durante la optimización?
¿Qué archivo adjuntaste después de ejecutarlo en el "styler"?
FAQ:
который вы выложили в первом посте темы.
Y en cuanto a "el código seguirá ejecutándose en cada tick (comprobación completa contra el TOR, no sólo la parte que debe comprobarse en cada tick)", ¿puede comentarlo?
Y en cuanto a "el código se seguirá ejecutando en cada tic (comprobación de la conformidad completa con la RPT, no sólo la parte que debe comprobarse en cada tic)", ¿cómo lo comentas?
Hay que rehacerlo, hay que rehacerlo con sabiduría. Entonces todo funcionará cuando y como debe.
No me refiero a este código, sino a nivel global. ¿Así que refutas esta afirmación?
No me refiero a este código, sino a nivel global. ¿Así que refutas esta afirmación?
No te metas en la teoría, de todas formas no entenderás nada.
Toda teoría sin un código o una aplicación concreta es una mera tontería.
Si quieres refutarlo o demostrarlo, haz el código y mira cómo se comporta.
no te metas en la teoría. de todas formas no entenderás nada.
Toda teoría sin un código o una aplicación concreta es mera cháchara.
Si quieres refutarlo o demostrarlo, haz el código y mira cómo se comporta.
Probablemente hay muchas cosas que no entiendo, pero estoy tratando de entenderlas...
Pensando en su llamada a la acción...
Pero tratando de entenderlo...
Hasta que no abras el MetaEditor y empieces a escribir tu propio código, no entenderás cómo funciona.
E incluso un pequeño proger principiante abrumará todos tus conocimientos teóricos con sus habilidades prácticas y observaciones empíricas.
Si no planeas "escribir tu propio código" - entonces ni siquiera empieces a preguntar en este foro por qué algo se retrasa, porque no tiene sentido para ti.
¿O has decidido convertirte en un codificador profesional siguiendo los consejos del foro? :)))) El nombre del tema "desaceleración lineal" nos dice que has estudiado en algún departamento de ciencias o una ingeniería.
No hay teóricos en la programación, al igual que no hay futbolistas/entrenadores/cirujanos/lingüistas profesionales que sean teóricos y nunca hayan estado en la práctica.
Todos tus esfuerzos por averiguar las razones por las que el programa no funciona no deben situarse en el plano del "quiero saber", sino en el vector concreto del "debo hacer".
Todos los demás razonamientos teóricos con nociones altisonantes no valen nada sin acciones concretas.
Y un poco de humor al grano.
Hasta que no abras el MetaEditor y empieces a escribir tu propio código, no entenderás cómo funciona.
E incluso un pequeño proger principiante abrumará todos tus conocimientos teóricos con sus habilidades prácticas y observaciones empíricas.
Si no piensas "escribir tu propio código" entonces ni siquiera empieces a preguntar en el foro por qué algo se retrasa, porque no tiene sentido para ti.
¿O has decidido convertirte en un profesional de la codificación gracias a los consejos del foro? :))) El nombre del tema "frenado lineal" nos indica que has estudiado en alguna facultad de ciencias o ingeniería.
No hay teóricos en la programación, al igual que no hay futbolistas/entrenadores/cirujanos/lingüistas profesionales que sean teóricos y nunca hayan estado en la práctica.
Todos sus esfuerzos por averiguar las causas del fracaso del programa deben situarse no en el plano del "quiero saber", sino en un vector particular del "debo hacer".
Todos los demás razonamientos teóricos con nociones pomposas no valen nada sin acciones concretas.
Y un poco de sustancia humorística al tema.
Gracias por el humor.
Pero sobre el tema, mi trabajo profesional radica en el campo de la optimización fiscal, así que estoy familiarizado con los algoritmos ;) Creía que mis TdR eran comprensibles, por supuesto después de especificar los detalles (intento hacer dibujos y cálculos en excel).
Además, estoy familiarizado con MetaEditor, y soy capaz de hacer un indicador simple o corregir la lógica de Expert Advisor. Pero tengo un gran problema con las funciones comerciales... Ahora tengo poco tiempo, y no me siento un programador nato, pero necesito entender los fundamentos y las características del lenguaje MQL, para defender mis intereses en la realización de mi pedido.
Y luego tengo mucha curiosidad.