Una vez hice una de estas cosas... - página 2
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
¿Has probado alguna vez esta aproximación https://ru.wikipedia.org/wiki/Кубический_сплайн? Es una función incorporada en Matkadec. A veces sale muy bien. Yo no he probado a programarla en MQL, ya que no soy muy manitas. Si lo haces, sería interesante y si es necesario puedo ayudarte a comparar los cálculos de matcad con el código MQL.
La cuestión es que la aproximación en sí no me interesa demasiado, me interesa la posibilidad de extrapolación. Y es deseable ver algún significado físico detrás. Y las estrías no parecen estar diseñadas para ello. ¿Qué sentido físico puede haber detrás de las estrías?
Por cierto, nos tuteamos, ¿no?
Ni siquiera he intentado programarlo en MQL. Viendo tus códigos, entiendo que se te da bien. Si de repente lo haces, sería interesante, y si necesitas ayuda para comparar los cálculos de matcad y el código MQL
La torpeza en la programación consiste simplemente en no conocer unas cuantas reglas sencillas para escribir programas con cuidado. En cuanto uno los entiende, la dejadez desaparece de inmediato. Por cierto, este código también sufre de descuido - el cuerpo de la función principal llamada no debe contener código computacional, por ejemplo, bucles y todo debe ser enrollado en funciones.
Por cierto, este código adolece también de alguna manía - el cuerpo de la función principal llamada no debería contener ningún código computacional, por ejemplo, bucles y todo debería estar colapsado en una función.
En general, evitar algunas de las reglas que son correctas para los proyectos grandes puede a veces acelerar un programa. Esto es especialmente cierto en el caso de MQL, teniendo en cuenta las especificidades de la aplicación. Puedo confesar que a veces uso código más o menos estructurado para depurar y luego lo vuelvo a cambiar a código lineal :). Aunque probablemente sea un extremismo :).
Pero en este caso pretendía una mirada rápida de "qué pasa", así que es código lineal en su forma más pura.
La torpeza en la programación consiste simplemente en no conocer unas cuantas reglas sencillas para escribir programas con cuidado.
Tonterías.
En cuanto uno los entiende, la dejadez desaparece inmediatamente.
Tonterías.
El cuerpo de la función principal a llamar no debe contener código computacional
¿Por qué?
Candidato:
Un día me di cuenta de una cosa muy sencilla: la aproximación por mínimos cuadrados se reduce esencialmente a minimizar una combinación lineal de vectores. Es decir, se puede hacer algún tipo de función aproximadora universal. Dicho y hecho, aquí está la cabecera de la función:
¿Dónde estabas antes? Justo ayer terminé de escribir lo mismo, aunque en C++. Gracias, también me será útil.
En general, no utilizar algunas de las reglas que son correctas para los grandes proyectos puede a veces acelerar considerablemente un programa. Esto es especialmente cierto en el caso de MQL, dadas las particularidades de la aplicación. Puedo confesar que a veces uso código más o menos estructurado para depurar y luego lo vuelvo a cambiar a código lineal :). Aunque probablemente sea un extremismo :).
En este caso pretendía una mirada rápida de "qué pasa", así que es código lineal en su forma más pura.
Estoy de acuerdo en que en la fase de depuración es conveniente mantener algunos fragmentos abiertos temporalmente... Y en la versión final se puede desenrollar todo el código haciéndolo ilegible y mejorando insignificantemente el rendimiento, pero en la práctica la legibilidad del código es siempre más importante sobre todo para la modificación posterior y la búsqueda de bugs.
Además, no es el hecho de que colapsar en función ralentizará el programa notablemente - es mucho mejor optimizar un algoritmo de cálculo donde muchas operaciones pueden no tener sentido.
1. Una basura.
1. Tonterías.
2. ¿Por qué?
1. ¿Por qué es una mierda? ¿En qué se basa esta conclusión?
2. La estructura de un programa escrito normalmente (de cualquier grado de complejidad) debe ser totalmente visible y legible en la función principal.
Si un programador es torpe y descuidado, es incapaz de hacerlo, lo que hace que el programa sea mal leído, incluso para el propio programador torpe, lo que lleva a multiplicar la torpeza en cualquier modernización y modificación del código.
1 ¿Por qué es una tontería? ¿En qué se basa esta conclusión?
2. La estructura de un programa escrito normalmente (de cualquier grado de complejidad) debe ser totalmente visible y legible en la función principal.
Si un programador es torpe y descuidado, no es capaz de hacerlo, lo que hace que el programa sea mal leído, incluso para el propio programador torpe, lo que lleva a multiplicar la torpeza en cualquier modernización y cambio de código.
Tal vez podrías hacer una clase magistral en lugar de blasfemar a los demás.
Por lo general, una vez que se ha dicho "A" se debe decir también "B".
Quizá puedas dar una clase magistral en lugar de blasfemar de los demás.
Normalmente hay que decir "A" y hay que decir "B".
¿Qué le interesa exactamente, podría especificar? ¿Cómo minimizar el código en una función para que la función principal no tenga código de cálculo disperso aquí y allá?
Gg :) ¿y si no tienes esta función tan importante? De todos modos, sin comentarios :)