![MQL5 - Lenguaje de estrategias comerciales para el terminal de cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
1. fácilmente. Especialmente en MT5.
2. Sospecho que lo estás haciendo sin escribir nada de código :) yyyy.
1. Este es el foro de MT4, así que es todo sobre MT4.
2- No nos pongamos personales, ¿vale? Hay otros hilos para la fluctuación. :)
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, antes nos tuteábamos, ¿no?
Sobre la spline, muy interesante la aproximación, intentaré explicar cómo la entiendo y qué se puede hacer con ella.
es una especie de definición, la spline cúbica. Ahora digamos que analizamos el movimiento de un objeto (puede ser cualquier objeto, un avión, un coche, una moneda...).
Usando de este algoritmo en una parte dada de la historia, encontraremos una función (la única que tiene velocidad y aceleración, que es mejor que ninguna (aunque lo dudo)). Sólo tenemos que suponer que durante algún tiempo el objeto se moverá a la misma velocidad y aceleración. Extrapolar. Y controlar el sesgo (error de extrapolación). Otras opciones, puede hacerlo con la llegada de nuevos datos, o puede establecer un umbral para cuando la discrepancia supere un valor predeterminado, y entonces recalcular.
Puede que me equivoque, pero me parece que hay algo en ello y es la física...
Intento ponerte en plural, aquí hay más programadores que yo, era una referencia a todos. Estás consiguiendo editar tu código, te envidio... No puedo crecer. Sólo puedo publicar malas ideas...)Estoy de acuerdo en que sí se puede, pero entiéndeme, yo también programaba en lenguaje ensamblador. Es que una vez que te acostumbras a algo bueno, es muy difícil alejarse de ello. Volver a un lenguaje de programación de bajo nivel es muy difícil. MQL es un lenguaje de programación de bajo nivel en comparación con matcad. Ejemplo por favor, me tomó 1 minuto para escribirlo
Y estoy seguro de que está calculado correctamente. Intente hacer lo mismo en MQL, calcular la integral doblemente definida de la función de Rayleigh-Reiss que contiene el cálculo de la función de Bessel de primer orden cero (por favor, no intente decir que no es necesario para el análisis del mercado, yo personalmente lo necesito).
S.I. Sólo tengo una idea y, por ejemplo, me gustaría comprobarla, así que la comprobé y seguí adelante. Si esta función fuera vital para construir el ATS (no se puede prescindir de ella), te aseguro que la pondría a trabajar, y pondría un precio muy suculento...
No veo ninguna contradicción. El algoritmo se puede esbozar en Matcad y en cualquier otro sitio, y si funciona, aún hay que convertirlo después a alguna forma aceptable para los cálculos de MT4/5. Matlab, por ejemplo, tiene convertidores de código, no sé si matcad - es mejor que nada, aunque no veo ningún problema para que tu nivel de conocimientos domine construcciones sencillas de C.
Creo que no tengo ninguna necesidad en Matkadec - incluso en Matkadec no hay ningún algoritmo que necesite ser traducido a MQL.
Intento usar el plural, hay más programadores por aquí que yo, eso iba dirigido a todos. Están haciendo cambios en tu código, te envidio... No puedo crecer. Sólo puedo publicar malas ideas...)
Hay muchos programadores por ahí, y el valor está justo en el algoritmo, y puede ser en cualquier lenguaje.
Si puedes dibujar un algoritmo que funcione en el mismo Matkad, entonces incluso los mejores programadores se compararán contigo como niños pequeños, ya que el algoritmo y la lógica son siempre primordiales, la implementación es secundaria.
....
Aparentemente no había necesidad de traducirlo a MQL, ni siquiera en Matcad, como tú dices.
Es más fácil y eficiente combinar MT4 con Matcad. Lo he hecho con el compostador hace mucho tiempo. Por cierto, hace tiempo que no le veo, a saber cómo está, qué le pasa.
¿Por qué un desconocido? ¿Es un número finito o infinito?
Puede ser bastante grande, aunque esto sería, por supuesto, una situación anormal.
Pero en general, quedémonos con el tema. Se dijo enseguida (y luego se repitió) que el código de los indicadores reales desde el principio se escribió como un código de uso único. Y el tema no es el estilo de programación. Si quieres, puedes iniciar un tema sobre cuándo, en qué situaciones y hasta qué punto está justificado el uso de las reglas de la programación "grande" en MQL.
Parece que te molesta que la moto no tenga un asiento anatómico. Bueno, es tu gusto, cada uno tiene derecho a hacerse una moto así, como mejor le parezca.
Ahora supongamos que estamos analizando el movimiento de un objeto (puede ser cualquier objeto, un avión, un coche, una moneda...)
Usamos de este algoritmo, en un tramo dado de la historia, para escoger una función (la única, no mejor (aunque lo dudo)) que tenga velocidad y aceleración. Sólo tenemos que suponer que durante algún tiempo el objeto se moverá a la misma velocidad y aceleración. Extrapolar. Y controlar la inconformidad (error de extrapolación).
Aquí he destacado la palabra más importante para mí. Hay una regla general (aunque probablemente no sin excepciones), a partir de cierto umbral, cuanto mejor sea la aproximación, peor será el resultado de la extrapolación. En principio, también pensé que las derivadas, si son necesarias, deberían calcularse por aproximación. Pero tiene que ser exactamente una aproximación "extrapolada", de lo contrario, simplemente arrastramos todo el ruido a esas derivadas. Así es el imho.
Y pensé que Kalman fue llevado al resultado, ¿no describiste el problema bajo Kalman? ¿O es más amplio que eso?
1. Puede ser bastante grande, aunque esto sería, por supuesto, una situación anormal.
2. Pero en general, mantengámonos en el tema. Y el tema no tiene que ver con el estilo de programación en absoluto.
1. Aunque el número sea grande, no es bueno multiplicar los objetos sin control. Hay que vigilarlo en cualquier caso, así que es mejor hacerlo bien desde el principio.
2. Disculpas por el offtop, simplemente no pude resistirme a hacer una simple y obvia observación sobre el estilo de programación... No esperaba que resonara tanto.
¿Dónde están las estadísticas de las pruebas de EA sobre este algoritmo? Sin ellos, tanto el debate como el propio tema carecen de sentido.
¿Y dónde está el algoritmo de EA?