una estrategia de negociación basada en la teoría de las ondas de Elliott - página 291
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
Y en este caso las condiciones del experimento no permiten considerar estos resultados como una confirmación de la ventaja estadística.
Bien.
"SL<MO" ¿qué es MO?
Y otra pregunta, ¿cómo optimizar el SL, al menos en pocas palabras? ¿Designarlo como un parámetro externo, es decir, un SL para todas las operaciones?
El único pensamiento es que es difícil juzgar a partir de estos resultados, las condiciones del experimento no son las adecuadas.
Los nuevos resultados son aún menos reveladores. Al fin y al cabo, no hay estadísticas.
De los 21 meses de pruebas, 10 son de más de una sesión.
No está afirmando que su sistema no esté equivocado. Así que ponga un tope de 20 y vea lo que sucede. Al menos aparecerán estadísticas.
Y no pienses que lo que escribimos aquí es una crítica al Asesor Experto en comercio. En general, como crítica.
Por cierto, el cambio a todas las garrapatas ha llevado a la disminución de MO de 38 a 23. No es un mal resultado.
También sería interesante comparar las mismas cifras, pero con paradas en ambos casos.
MO es la expectativa matemática de ganancia.
SL se puede optimizar de forma muy sencilla. Emitirlo como un parámetro externo y ejecutar la optimización en el probador, estableciendo los límites y el paso. Por supuesto, en el código del Asesor Experto debe añadir la condición de cerrar una posición cuando el precio cae por debajo del SL para la compra y viceversa para la venta.
La única idea es que es difícil juzgar a partir de estos resultados, no las condiciones del experimento.
Los nuevos resultados son aún menos indicativos. Al fin y al cabo, no hay estadísticas.
De los 21 meses de pruebas, 10 son de sobre-seducción.
Yuri, no estoy para nada alterado, ni ofendido y está perfectamente bien. :о)))) MathCAD no tiene un exceso de 10 meses porque tiene un código que no permite esos tratos, pero por otras consideraciones. En cuanto al modelo, 10 meses de sobre-seducción no es un error. No ocurrió nada "terrible" para el modelo - el precio estaba sentado en el canal (colgando del borde). Por cierto, debido a casos como éste, empecé a intentar predecir la trayectoria en sí.
No está afirmando que su sistema no esté equivocado. Así que ponga un tope de 20 y vea lo que sucede. Al menos las estadísticas aparecerán.
No pretendo, aunque todavía no he encontrado ningún error evidente - durante la vida del canal el precio pasa el nivel calculado. Pero seguro que aparecerán antes o después, no me hago ilusiones, el modelo tiene algunos puntos débiles.
Probablemente, me desviaré de mi plan y utilizaré paradas. Sigo confiando en tus consejos, ya que ahora miro la MT como un neandertal en una calculadora. En matcad, es simple - las fórmulas como son. :о)
No dude en preguntar, a su servicio.
Pero para mí es al revés. :-))
Sin embargo, ahora no estoy mirando en matcad, sino en matlab. Y ya no como neandertal, sino como cromañón.
Dos puntos más:
- En principio es normal esperar una correlación entre el tiempo de mantenimiento de la posición y el valor de los beneficios. En los tiempos pequeños parece estar ahí (a ojo, puedo equivocarme). Pero en tiempos más largos (de nuevo "a ojo") la situación parece más aleatoria. Pero, por casualidad, debe haber pequeñas ventajas y pequeñas desventajas. Y no hay desventajas. ¿No hay salidas de "ajuste" ocasionales en el código?
- Casi cualquier estrategia tiene periodos de "aplicabilidad" y "no aplicabilidad". Si la superación del período de "no aplicable" enmascara, la introducción de topes podría ser un desastre para el informe. Y la no adopción puede ser desastrosa para la cuenta real.
Hay que contarlo. Si no es la primera vez, entonces la segunda. Puede ver cómo ocurre en el vídeo - https://www.mql5.com/zh/forum/103424
Entonces, ¿hay un recálculo automático? Pero por lo que tengo entendido, no hay sincronización de las cotizaciones con la hora del broker. Bien, si se trata de combinar dos piezas largas, entonces el salto temporal en el cruce, digamos de una hora, no será en principio importante. Pero, ¿y si la historia original es un conjunto de piezas y la carga de citas rellena los huecos? Sería una buena mezcla.
Después de cargar el historial yo mismo, lo transferí inmediatamente al terminal autónomo y no lo mezclé con nada.
He decidido ampliar un poco mi respuesta. A continuación puede ver las estadísticas de la vida de los canales (eurusd, horas) realizadas de la siguiente manera: fijo la longitud del canal, me muevo junto con el tiempo, construyo un canal de longitud fija para cada barra "actual" y estimo su vida (mirando al futuro, por supuesto). Al mismo tiempo, recogí todo tipo de parámetros adicionales de los canales. En este caso concreto, el canal tiene una longitud de 300 cuentas.
Por supuesto, es inferior a las imágenes de la transformada wavelet, pero preste atención a la propia forma de la curva (persiste para otros períodos y citas), el canal toma casi inmediatamente una posición estable, es decir, primero sigue un pico, y luego la duración disminuye, pero no al revés, aunque sería más lógico esperar exactamente una imagen así. Puedes ver que algunos canales viven bastante tiempo, alrededor de 3,5 de su longitud (permíteme recordarte que al mirar hacia el futuro, los parámetros del canal no cambian). Por lo tanto, no sé cuál es la trayectoria del precio durante este tiempo, pero es casi seguro que durante la existencia del canal, el precio pasará por el nivel calculado, por supuesto, si los criterios adicionales funcionan, incluyendo el índice de Hurst. Puede ocurrir en 20 minutos, puede ocurrir en unos días, puede ocurrir en unos meses. Por supuesto, esta es una de las características desagradables - creer o rechazar el comercio o permitir una pérdida. Características similares en cuanto al grado de "malestar", pueden encontrarse en número suficiente en cualquier otra estrategia y modelo.
En este modelo no busco una zona de inversión (otros modelos sí lo hacen). El código del modelo central en MathCAD ocupa unas pocas líneas, y el código que bloquea las operaciones de 10 meses ocupa unos cientos de líneas. Así, las primeras pruebas de este modelo mostraron un 20% de operaciones perdedoras (tras el bloqueo), ahora es un 2% en MathCAD, queda por ver qué pasará en MT.
Por cierto, la forma de la curva en sí es útil. Si recoges estadísticas (puede que ya las hayas recogido) podrás clasificar los extremos (ya sea basándote en el sentido común o recurriendo a sistemas profesionales), y observando su forma cerca del punto de referencia actual (retrocediendo un canal) podrás estimar el tiempo de existencia del canal con un alto grado de fiabilidad.
En general, los canales tienen mucho sentido... pero eso es sólo una filosofía.
a Candid
Dos puntos más:
- En principio, es normal esperar una correlación entre el tiempo de mantenimiento de la posición y el valor del beneficio. Parece que está presente en pequeños momentos (a ojo, puedo equivocarme). Pero en tiempos más largos (de nuevo "a ojo") la situación parece más aleatoria. Pero, por casualidad, debe haber pequeñas ventajas y desventajas. Y no hay desventajas. ¿No hay salidas de "ajuste" ocasionales en el código?
- Casi cualquier estrategia tiene periodos de "aplicabilidad" y "no aplicabilidad". Si la superación del período de "no aplicable" enmascara, la introducción de topes podría ser un desastre para el informe. Y la no adopción puede ser desastrosa para la cuenta real.
Exactamente por la razón de que aún es pronto (prueba filosófica) me estaba contoneando como un barco marqués cuando Yuri me clavó un SL en la pared. Y prácticamente me convenció en SL con una palabra amable y una pistola. :о)
Por cierto, antes no utilizaba el Stop Loss como parámetro de la orden y lo implementaba a través del control de una posición abierta, ya que las condiciones son siempre cambiantes.
a Yurixx
Yuri, por favor ayúdame con el SL. :о)
Como he escrito antes, nunca he utilizado SL, pero sí el control dinámico de órdenes. Probablemente no sea muy conveniente porque el sistema tiene que estar conectado al servidor todo el tiempo, pero en mi opinión tiene más sentido.
Recuerdo vagamente que tuve algunos problemas con SL (fue hace como un año), o mi empresa de corretaje no permitía colocarlos demasiado lejos o algo así. De todos modos, miré la documentación y "recordé" que ese es el nivel de precio al que se cierra la orden. Ok, me dije e introduje los siguientes parámetros para el SL en función del tipo de orden:
Bid-20*Point
Ask+20*Point
Ni una sola operación, ahora trato de entender por qué, o más bien solicitar el código de error. He introducido algunas opciones más, pero no hay trato. Al final me harté de él y especifiqué el nivel de precio de SL 20,0, y funcionó:
Como en aquel dibujo animado "no entiendo nada". Yuri, explícale al dinosaurio cómo configurarlos correctamente, y por qué el valor de, digamos, 1,2 es peor que 20,0
1. Usted no puede poner SL en absoluto, sino controlar dinámicamente el nivel de precios usted mismo y "cerrar" el comercio en el caso correcto. Todo es simbolismo, no comercio. Sólo es una recopilación de estadísticas. Pero en este caso todo debe hacerse manualmente, sin usar un probador. En otras palabras, sólo tenemos que escribir un script que recorra el historial implementando la estrategia y recogiendo los resultados en un archivo. No hay nada difícil, porque el 95% del script es el texto de su Asesor Experto.
2. Si utilizas el probador, entonces la SL debe ser fijada en las órdenes que realices, tal y como se hace en el mundo real. Lo que has escrito no entiendo cuál es el problema. La forma más fácil de solucionarlo es recortar los fragmentos de código donde se declara, define y utiliza SL y ponerlos aquí. Quizá el problema esté en la normalización (todos los precios de los pedidos deberían estar normalizados, es decir, redondeados a la precisión del punto). Por cierto, si ha especificado explícitamente 20,0, ese es exactamente el valor normalizado. Y 20*Punto no lo es. Si lo hubieras puesto explícitamente en 1,2, también funcionaría (para comprar). Pruebe lo siguiente:
Oferta-20,0*Punto
Oferta+20,0*Punto
Sin embargo, una vez más: Oferta,Oferta también pueden ser no normalizadas.
Eso es lo que voy a hacer, como lo llaman, como siempre.
2. Si utilizas el probador, entonces la SL debe ser fijada en las órdenes que realices, tal y como se hace en el mundo real. Por lo que has escrito no entiendo cuál es el problema. La forma más fácil de solucionarlo es recortar los fragmentos de código donde se declara, define y utiliza SL y ponerlos aquí. Quizá el problema esté en la normalización (todos los precios de los pedidos deberían estar normalizados, es decir, redondeados a la precisión del punto). Por cierto, si ha especificado explícitamente 20,0, ese es exactamente el valor normalizado. Y 20*Punto no lo es. Si lo pones explícitamente a 1,2, también funcionaría (para comprar)
El problema es que da el código de error 130 - paradas incorrectas. :о)
Qué difícil es. ¿Existe alguna función que simplemente redondee el número a 4 decimales?
Ahora bien, no sé cuál será la trayectoria del precio durante este tiempo, pero es casi seguro que durante la existencia del canal, el precio superará el nivel calculado, siempre que, por supuesto, funcionen los criterios adicionales, incluido el índice Hearst. Puede ocurrir en 20 minutos, en unos días o en unos meses.
Entonces, ¿el canal no se rompió durante esa operación de 10 meses (en este drawdown)? Sin embargo, fue un canal poderoso :)
Ok, me dije e introduje los siguientes parámetros para el SL en función del tipo de orden:
Bid-20*Point
Ask+20*Point
Ni una sola operación, ahora estoy tratando de entender por qué, o más bien solicitar el código de error.
Mira el registro, si OrderSend no funciona, hay un registro de la razón.