Mt4 Fin de soporte. - página 29
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 principal desventaja: la programación orientada a objetos obliga a fragmentar el código en muchas funciones.
Para los humanos es más fácil aceptar el código fragmentado, pero la fragmentación está contraindicada para cualquier mecanismo.
De acuerdo, pero ¿cuál es la desventaja?
Es la principal ventaja, precisamente porque es más fácil que una persona perciba el código fragmentado.
El ordenador tiene que adaptarse al humano, no el humano al ordenador.
Así es, pero ¿cuál es el inconveniente?
Esa es la principal ventaja, precisamente porque es más fácil que una persona perciba el código fragmentado.
El ordenador debe adaptarse a la persona, no la persona al ordenador.
Por desgracia, un desarrollador debería pensar primero en la eficacia de su mecanismo, no en su comodidad)).
De lo contrario, el mecanismo "cojea".
El desarrollador debe ajustarse al ordenador.
Si las cotizaciones proceden del mismo servidor, da igual el instrumento. Al fin y al cabo, las barras se abren en cada instrumento al mismo tiempo.
Es diferente si las fuentes de las citas están en diferentes partes del mundo. Para los minutos no importa, pero puede haber un problema con los plazos más altos. Tal vez haya que estudiar con más detalle las funciones temporales y realizar una corrección horaria precisa. Pero esa es la siguiente etapa en el desarrollo de esta solución...
Es necesario hacer una calibración para esta función...
Al principio quería leer todo lo que se escribía sin mí, por si ya había una pregunta y una respuesta, pero me temo que será difícil encontrar el post que hay que citar después.
Por ahora sólo hay una pregunta: Como todo el mundo sabe, una nueva barra no aparecerá hasta el primer tick del nuevo intervalo de tiempo. Por lo tanto, si debería haber una barra por milisegundos pero está ausente, puede obtener lecturas del indicador de la barra equivocada.
Espero encontrar una respuesta a la segunda pregunta, que fue formulada por Artem.
Al principio quise leer todo lo que se escribió sin mí, por si ya había una pregunta y una respuesta, pero me temo que será difícil encontrar el post que hay que citar.
Hasta ahora sólo una pregunta: Como todo el mundo sabe, una nueva barra no aparecerá hasta el primer tick del nuevo intervalo de tiempo. Por lo tanto, si debería haber una barra por milisegundos pero está ausente, podemos obtener los valores del indicador de la barra equivocada.
Espero encontrar una respuesta a la segunda pregunta, que fue formulada por Artem.
Sí, ya lo discutimos ayer.
Yo solía tratar con otra plataforma y allí las barras se formaban por tiempo independientemente de la llegada de las cotizaciones (mira la TWS).
Me han dicho que no es el caso de MT.
Añadiré una comprobación de la llegada de la cotización para confirmar el evento de la aparición de un nuevo bar.
Ya he contestado que los bares se abren independientemente de la llegada de una cotización. Si no hay cotización, el precio de la nueva barra será el precio de cierre de la barra anterior. El hecho de una nueva barra se fijará independientemente de la llegada de las cotizaciones, por los propios contadores, que funcionan con un temporizador.
El marco de tiempo específico no importa, porque es sólo un contador que alcanza su valor y establece el evento de la nueva barra de este marco de tiempo. Se trata simplemente de un método de sincronización con la aparición de nuevas barras de diferentes marcos temporales. SINCRONIZACIÓN.
El instrumento tampoco importa. Si las cotizaciones son de un mismo servidor, significa que tienen la misma hora de aparición de las nuevas barras. Por lo tanto, no importa qué instrumento, siempre y cuando estos instrumentos sean de un punto del globo.
Terminaré lo que he dicho y haré otras cosas. Un poco de cosas buenas).
¿Y cómo se explica que el cierre del viernes, la barra anterior de cualquier periodo sea igual a 1,20333, y la apertura del lunes de cualquier periodo sea igual a 1,20142?
Por supuesto, este es el presupuesto de un corredor, el otro podría ser un poco diferente, pero hay una diferencia en todos.
¿Y cómo se explica que el cierre del viernes, la barra anterior de cualquier periodo sea 1,20333 y la apertura del lunes de cualquier periodo sea también 1,20142?
Esto es, por supuesto, las cotizaciones de un corredor, el otro puede ser un poco diferente, pero todos tienen diferencias.
Se explica por la brecha. Sucede en la apertura de la sesión.
No soy un experto en comercio, así que no juzguen mi opinión con demasiada dureza).
Y sé aún menos sobre lo que ocurre en el mercado de divisas).
Por desgracia, el diseñador debe pensar primero en la eficacia de su mecanismo, no en su comodidad).
De lo contrario, el mecanismo "cojea".
El desarrollador tiene que adaptarse al ordenador.
No.
Deja que el ordenador se adapte a mí. Ya tengo bastantes otros problemas. El desarrollador sólo puede hacer retoques donde el ordenador no puede realizar la tarea, por ejemplo, en los cuellos de botella donde le falta rendimiento o memoria. Entonces, sí, le toca al promotor ajustarse. Pero hasta ahora no me he encontrado con ningún lugar en el que la POO imponga una carga adicional tan importante al ordenador como para tener que reducirla de alguna manera.
Algo así (código para MQL5):
Pero repito: soy partidario de la OOP.
Es sólo un ejemplo realmente fallido para mostrar lo que es imposible de hacer en la programación procedimental.
Cuando empecé con esto, no pretendía demostrar que todo es posible/imposible de hacer, sino simplemente que es más conveniente para usarlo en el futuro cuando escriba mis propios códigos.
Pero resultó, como dijo V.S., quería lo mejor, pero resultó como siempre.
Oh, no.
Es el ordenador el que se adapta a mí. Ya tengo bastantes otros problemas. El desarrollador sólo puede ajustar donde el ordenador "no puede manejar", por ejemplo, en los "cuellos de botella", donde no hay suficiente rendimiento o memoria. Entonces, sí, le toca al promotor ajustarse. Pero hasta ahora no he encontrado ningún lugar donde la POO suponga una carga adicional tan importante para el ordenador que deba reducirse de alguna manera.
La carga del ordenador se debe a la actitud descuidada del desarrollador con respecto a la cuestión de la coherencia de su mecanismo. El deseo de ahorrar energía para mejorar el sistema. Un derroche desmedido de recursos informáticos en nombre de la facilitación de su trabajo.
Mientras el ordenador se enfrente con éxito a un código escrito de forma ineficiente, el desarrollador seguirá "parasitando" la capacidad de procesamiento. Este es un camino sin salida.
Tarde o temprano, el mecanismo ineficaz dejará de desarrollarse y será sustituido por otro mejor.
El tiempo y el esfuerzo del hombre serán desperdiciados y su obra acabará en el cubo de la basura.
En el mundo de la competencia, este riesgo existe todo el tiempo.
Cuando diseñamos máquinas, debemos pensar primero en su rendimiento, y después en la comodidad y el confort para pasar nuestras horas de trabajo).
La carga recae sobre el ordenador por la actitud negligente del desarrollador respecto a la coherencia de su mecanismo. El deseo de ahorrar energía en la mejora del sistema. Consumo desmedido de recursos informáticos en nombre de facilitar su trabajo.
Mientras el ordenador se enfrente con éxito a un código escrito de forma ineficiente, el desarrollador seguirá "parasitando" la capacidad de procesamiento. Este es un camino sin salida.
Tarde o temprano, el mecanismo ineficaz dejará de desarrollarse y será sustituido por otro mejor.
El tiempo y el esfuerzo del hombre serán desperdiciados y su obra acabará en el cubo de la basura.
En el mundo de la competencia, este riesgo existe todo el tiempo.
Al desarrollar los mecanismos, debemos pensar en su rendimiento en primer lugar y en la comodidad y el confort de nuestras horas de trabajo en segundo lugar)).
Se llama escribir el programa. Por eso, primero hay que escribir un código que funcione correctamente (y que sea legible para cualquier otro desarrollador) y sólo después optimizarlo si hay algo que optimizar.