Hora de escribir el asesor - página 5
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
Te puedo enviar una orden que hizo la fuente, se puede ver que entiende, la calidad o no lo hizo, simplemente no entiendo, la calidad o no, lo principal que trabaja en el algoritmo, y como el interior, no sharyu) 0
La mayor parte del código está en la biblioteca Trades.mqh, que supongo que te ha enviado. Por favor, adjúntelo para estimar la calidad.
No se puede juzgar mucho a partir de este archivo. Parece que no hay comprobaciones y normalizaciones donde deberían estar, pero podrían estar también en el archivo Trades.mqh incluido.
Y la mayor parte del código se encuentra en el mismo lugar.
Sin embargo, tengo algo que decir sobre el bloque de señales.
1) comparación de los dobles entre sí sin ninguna normalización.
2) El cruce de precios MA se implementa sin tener en cuenta la situación cuando el precio de cierre de la vela es igual al precio MA. Esto es raro, pero aún es posible.
No discuto que sea difícil y sí que hay muchos errores, pero hace 2 meses se les dijo que los errores son conocidos, subsanables y toda la parte más difícil ha terminado, lamentablemente no soy yo quien lo hace, y alguien que conoce todos los detalles de la estrategia, y acordó una tarifa por hora y un simple informe de trabajo y no pude demostrarle que estaba mal y equivocado
¿El trabajo autónomo se paga por horas?
Si puedes resolver los problemas a través de un arbitraje, que existe, lo solucionarán.
Permítanme unirme a la discusión, si están dispuestos a ello ))))
En primer lugar, por supuesto a 82Dmitry82 y al resto de su equipo, les pido disculpas por el retraso en el desarrollo. Como yo mismo he indicado a su representante que lamentaba haber asumido el desarrollo, admito que para mí es una tarea difícil. La tarea se dividió en partes, pero una fuerte complicación de los requisitos reveló en la segunda etapa, y de hecho, desde que lo tomé, decidí llevar a su fin, pero no fue tan fácil.
Ahora, sin desvelar la estrategia, intentaré esbozar el hecho de aumentar la complejidad de los TdR, para que nuestros programadores aprecien realmente cuánto complica este hecho el desarrollo.
La base es la construcción gráfica de los niveles a partir de los cuales deben abrirse las órdenes. Estos niveles no se pueden construir de inmediato en el borde del gráfico sin referirse al historial, tenemos que esperar hasta que el historial se construya o simplemente hacer que el Asesor Experto se refiera al propio historial y llegue al borde del gráfico con algunos datos. Esto es lo que hemos decidido hacer.
Inicialmente, nos imaginamos que íbamos a correr por velas y estimar 4 parámetros (Open, Close, High, Low) y construir en base a las condiciones. Y así hicimos la primera parte en un gran TF (ToR está dividido en 3 partes, 3 TFs para cada una de las cuales hay diferentes construcciones y condiciones para estas construcciones). Cuando pasamos a la segunda TF y empezamos a probar esencialmente la segunda parte lista, identificamos errores y la discusión general mostró que una vela en el historial debe ser rastreada en línea (es decir, como si fuera cero en el borde del gráfico) y las reconstrucciones deben hacerse mientras la vela está todavía abierta, lo que no es realista durante la ejecución a través del historial, porque en realidad hay 4 parámetros Open, Close, Low y High.
La discusión general ha decidido profundizar y desglosar hasta m1 para trazar la vela en línea lo más posible (como si fuera cero en el borde del gráfico). Se rechazó la idea de dejar la construcción de la historia como está por 4 puntos y trazar la lógica correcta en el borde del gráfico (cuando Close[0] está flotando). Los propios clientes entendieron que este hecho, revelado en el proceso de desarrollo, complica notablemente los TdR. Ya en esa etapa quise abandonar el desarrollo, pero como la primera etapa ya estaba hecha, y no está en mis principios abandonar el desarrollo a la mitad decidí continuar. Mientras adaptaba el algoritmo existente al hecho de que debía utilizar M1 y trazar TFs más altas, empecé a sentirme psicótico, porque había matado mucho tiempo para ello, y durante el proceso de no conseguirlo me derrumbaba y escribía a los clientes que debía subir el coste de desarrollo, pero cuando me alejaba del ordenador y me enfriaba un poco, seguía corrigiendo el problema.
Sugerí un pago basado en el tiempo sólo porque ya no podía sacar el proyecto por la cantidad negociada. Aunque se ofreció a dar el código fuente para posiblemente encontrar a alguien que traerá a la mente.
Si lo hubiera sabido desde el principio habría utilizado otro enfoque para seguir a М1 dentro del marco temporal superior.
Si tengo un error en la construcción, lo corregiré. No tengo oportunidad de comprobarlo todo yo mismo, ya que hay muchas condiciones en la estrategia que ni siquiera recuerdo. Ya he comprobado todos ellos para que no entren en conflicto, ese es el principal problema. Se hizo poco a poco, y los clientes admiten que la estrategia es difícil de entender, pero en general es ahora casi todo prescrito, pero como funciona ni siquiera puedo entender bien o no)))
Lo último en lo que se detuvieron fue en el caso que no se tuvo en cuenta (incluso según el representante de los clientes) y ahora tenemos que escribir, pegar y estar de acuerdo con una docena de otras condiciones una vez más. Así que el paso a una tarifa por hora por mi parte creo que está justificado.
82Dmitry82, si quieres, podemos hablar personalmente con el asesor, tienes mis contactos. He hecho otro EA para usted, creo que apreciará su capacidad de respuesta y apoyo, pero voy a pedir paciencia con este, a veces lo pospongo, sólo porque no entiendo a qué lado ir, para empezar a corregir otra construcción de nivel equivocado.
En este momento hay más de 1000 líneas de código en el Asesor Experto y esto es sólo la construcción de niveles, sin ninguna malla agradable e incluso órdenes, que aún no se han alcanzado.
Permítanme unirme a la discusión, si están dispuestos a ello ))))
En primer lugar, por supuesto a 82Dmitry82 y al resto de su equipo, les pido disculpas por el retraso en el desarrollo. Como yo mismo he indicado a su representante que lamentaba haber asumido el desarrollo, admito que para mí es una tarea difícil. La tarea se dividió en partes, pero una fuerte complicación de los requisitos reveló en la segunda etapa, y de hecho, desde que lo tomé, decidí llevar a su fin, pero no fue tan fácil.
Ahora, sin desvelar la estrategia, intentaré esbozar el hecho de aumentar la complejidad de los TdR, para que nuestros programadores aprecien realmente cuánto complica este hecho el desarrollo.
La base es la construcción gráfica de los niveles a partir de los cuales deben abrirse las órdenes. Estos niveles no se pueden construir de inmediato en el borde del gráfico sin referirse al historial, tenemos que esperar hasta que el historial se construya o simplemente hacer que el Asesor Experto se refiera al propio historial y llegue al borde del gráfico con algunos datos. Esto es lo que hemos decidido hacer.
Inicialmente, nos imaginamos que íbamos a correr por velas y estimar 4 parámetros (Open, Close, High, Low) y construir en base a las condiciones. Y así hicimos la primera parte en un gran TF (ToR está dividido en 3 partes, 3 TFs para cada una de las cuales hay diferentes construcciones y condiciones para estas construcciones). Cuando pasamos a la segunda TF y empezamos a probar esencialmente la segunda parte lista, identificamos errores y la discusión general mostró que una vela en el historial debería ser rastreada en línea (es decir, como si fuera cero en el borde del gráfico) y una re-construcción hecha cuando la vela aún no está cerrada, lo que no es realista durante la ejecución a través del historial, porque en realidad hay 4 parámetros Open, Close, Low y High.
La discusión general ha decidido profundizar y desglosar hasta m1 para trazar la vela en línea lo más posible (como si fuera cero en el borde del gráfico). Se rechazó la idea de dejar la construcción de la historia como está por 4 puntos y trazar la lógica correcta en el borde del gráfico (cuando Close[0] está flotando). Los propios clientes entendieron que este hecho, revelado en el proceso de desarrollo, complica notablemente los TdR. Ya en esa etapa quise abandonar el desarrollo, pero como la primera etapa ya estaba hecha, y no está en mis principios abandonar el desarrollo a la mitad decidí continuar. Mientras adaptaba el algoritmo existente al hecho de que debía usar M1 y trazar TFs más altas, empecé a sentirme psicótico, porque había matado mucho tiempo para eso, durante el proceso de no tener éxito me frustraba y escribía a los clientes que debía subir el coste de desarrollo, pero cuando me alejaba del ordenador y me enfriaba un poco, seguía corrigiendo el problema.
Sugerí un pago basado en el tiempo sólo porque ya no podía sacar el proyecto por la cantidad negociada. Aunque se ofreció a dar el código fuente para posiblemente encontrar a alguien que traerá a la mente.
Si lo hubiera sabido desde el principio habría utilizado otro enfoque para seguir a М1 dentro del marco temporal superior.
Si tengo un error en la construcción, lo corregiré. No puedo comprobarlo todo yo mismo, ya que hay muchas condiciones en la estrategia que ni siquiera recuerdo. Ya he comprobado todos ellos para que no entren en conflicto, ese es el principal problema. Se hizo poco a poco, y los clientes admiten que la estrategia es difícil de entender, pero en general es ahora casi todo prescrito, pero como funciona ni siquiera puedo entender bien o no)))
Lo último en lo que se detuvieron fue en el caso que no se tuvo en cuenta (incluso según el representante de los clientes) y ahora tenemos que escribir, pegar y estar de acuerdo con una docena de otras condiciones una vez más. Así que el paso a una tarifa por hora por mi parte creo que está justificado.
82Dmitry82, si quieres, podemos hablar personalmente con el asesor, tienes mis contactos. He hecho otro EA para usted, creo que apreciará su capacidad de respuesta y apoyo, pero voy a pedir paciencia con este, a veces lo pospongo, sólo porque no entiendo a qué lado ir, para empezar a corregir otra construcción de nivel equivocado.
En este momento hay más de 1000 líneas de código en el Asesor Experto y esto es sólo la construcción de niveles sin ninguna malla agradable e incluso órdenes a las que no hemos llegado todavía.
En definitiva, se ha vuelto aún más confuso de lo que era.
He entendido que debemos comprobar la coincidencia de condiciones en un marco temporal superior y si la coincidencia no se da, debemos ...
Si entiendo bien el algoritmo, no es tan complicado, 2-3 días como máximo.
En este momento hay más de 1000 líneas de código en el EA, y esto es sólo la construcción de niveles, sin ninguna malla agradable e incluso órdenes, que aún no se han alcanzado.
1000 líneas es por cierto el tamaño medio de cualquier EA por encima de uno simple. Creo que el problema es que has tomado el camino equivocado al pensar en cómo sortear los problemas que han surgido. El 90% del éxito consiste en formular el problema correcto, y su aplicación es una cuestión de décimo
.
.
De hecho, si hubiera sabido desde el principio que era necesario rastrear m1 dentro del marco de tiempo superior, habría construido la lógica del EA de manera diferente.
.
En este momento hay más de 1000 líneas de código en el EA, y esto es sólo la construcción de niveles, sin ninguna malla agradable e incluso órdenes, que aún no se han alcanzado.
Déjame apoyarte.
Por supuesto, mi estrategia no es exactamente así, pero es similar. Tiene en cuenta los niveles de soporte/cop, la tendencia, los retrocesos, el pullback y muchas otras cosas, sin utilizar indicadores externos (personalizados).
Llevo 3 años operando a mano con esta estrategia. Todo este tiempo estuve pensando cómo implementarlo y lo programé durante un año. Resultaron menos de 2000 líneas.
Todos los desarrolladores que pueden operar a mano, es más fácil para ellos cuando toman algunas barras como base para el análisis.
Pero un bar, aunque sea M1, ya es el pasado. Es inútil construir una estrategia en barras (especialmente en las más altas).
Debe hacerse utilizando cada garrapata.
En mi programa no hay un solo array (en el sentido absoluto), y no analizo lo que había en el pasado, pero por supuesto recuerdo los puntos de control necesarios en tiempo real (no en arrays).
En resumen: lo que se hace a mano y se dibuja tan fácil y bellamente en el gráfico, no siempre es posible programarlo.
Permítanme unirme a la discusión, si están dispuestos a ello ))))
En primer lugar, por supuesto a 82Dmitry82 y al resto de su equipo, les pido disculpas por el retraso en el desarrollo. Como yo mismo he indicado a su representante que lamentaba haber asumido el desarrollo, admito que para mí es una tarea difícil. La tarea se dividió en partes, pero una fuerte complicación de los requisitos reveló en la segunda etapa, y de hecho, desde que lo tomé, decidí llevar a su fin, pero no fue tan fácil.
Ahora, sin desvelar la estrategia, intentaré esbozar el hecho de aumentar la complejidad de los TdR, para que nuestros programadores aprecien realmente cuánto complica este hecho el desarrollo.
La base es la construcción gráfica de los niveles a partir de los cuales deben abrirse las órdenes. Estos niveles no se pueden construir de inmediato en el borde del gráfico sin referirse al historial, tenemos que esperar hasta que el historial se construya o simplemente hacer que el Asesor Experto se refiera al propio historial y llegue al borde del gráfico con algunos datos. Esto es lo que hemos decidido hacer.
Inicialmente, nos imaginamos que íbamos a correr por velas y estimar 4 parámetros (Open, Close, High, Low) y construir en base a las condiciones. Y así hicimos la primera parte en un gran TF (ToR está dividido en 3 partes, 3 TFs para cada una de las cuales hay diferentes construcciones y condiciones para estas construcciones). Cuando pasamos al segundo TF y empezamos a probar esencialmente la segunda parte lista, identificamos errores y la discusión general mostró que una vela en el historial debe ser rastreada en línea (es decir, como si fuera cero en el borde del gráfico) y las reconstrucciones deben hacerse cuando la vela aún no está cerrada, lo que no es realista durante la ejecución a través del historial, porque en realidad hay 4 parámetros Open, Close, Low y High.
La discusión general ha decidido profundizar y desglosar hasta m1 para trazar la vela en línea lo más posible (como si fuera cero en el borde del gráfico). Se rechazó la idea de dejar la construcción de la historia como está por 4 puntos y trazar la lógica correcta en el borde del gráfico (cuando Close[0] está flotando). Los propios clientes entendieron que este hecho, revelado en el proceso de desarrollo, complica notablemente los TdR. Quería abandonar el desarrollo ya en esa etapa, pero como la primera etapa ya estaba hecha, y no está en mis principios abandonar el desarrollo en la mitad, decidí continuar. Mientras adaptaba el algoritmo existente al hecho de que debía usar M1 y trazar TFs más altas, empecé a sentirme psicótico, porque había matado mucho tiempo para eso, durante el proceso de no tener éxito me frustraba y escribía a los clientes que debía subir el coste de desarrollo, pero cuando me alejaba del ordenador y me enfriaba un poco, seguía corrigiendo el problema.
Sugerí un pago basado en el tiempo sólo porque ya no podía sacar el proyecto por la cantidad negociada. Aunque se ofreció a dar el código fuente para posiblemente encontrar a alguien que traerá a la mente.
Si lo hubiera sabido desde el principio habría utilizado otro enfoque para seguir a М1 dentro del marco temporal superior.
Si hubiera sabido desde el principio que es necesario hacer un seguimiento dentro de M1 y en plazos más altos, lo habría hecho de otra manera. No tengo oportunidad de comprobarlo todo yo mismo, ya que hay muchas condiciones en la estrategia que ni siquiera recuerdo. Ya he comprobado todos ellos para que no entren en conflicto, ese es el principal problema. Se hizo poco a poco, y los clientes admiten que la estrategia es difícil de entender, pero en general es ahora casi todo prescrito, pero como funciona ni siquiera puedo entender bien o no)))
Lo último en lo que se detuvieron fue en el caso que no se tuvo en cuenta (incluso según el representante de los clientes) y ahora tenemos que escribir, pegar y estar de acuerdo con una docena de otras condiciones una vez más. Así que el paso a una tarifa por hora por mi parte creo que está justificado.
82Dmitry82, si quieres, podemos hablar personalmente con el asesor, tienes mis contactos. He hecho otro EA para usted, creo que apreciará su capacidad de respuesta y apoyo, pero voy a pedir paciencia con este, a veces lo pospongo, sólo porque no entiendo a qué lado ir, para empezar a corregir otra construcción de nivel equivocado.
Por el momento hay más de 1000 líneas de código en el EA y esto es sólo la construcción de niveles, sin mallas bonitas e incluso órdenes, que aún no se han alcanzado.
Por la descripción, está claro que no he tenido TOR y la tarea se parece a esto: Hazme esta estrategia, y debe funcionar de esta manera y al mismo tiempo pensar en cómo implementar todo esto, sin algoritmo.
En este caso, se trata de un trabajo intensivo, como he escrito más arriba, el programador se pone a pensar, y el coste de pensar es diferente para cada uno. Por lo tanto, el precio puede estar justificado.
La división del trabajo se inventó por una razón. El cliente entiende a un programador como un mago que puede trasladar cualquier idea a código. De hecho, las habilidades y competencias de una persona son siempre limitadas, y en las grandes empresas existe una división del trabajo entre una persona que crea algoritmos, un arquitecto y un programador, cada uno de ellos con su propia especialización. Así es como se desarrolló la situación.
Déjame apoyarte.
No tengo exactamente lo mismo, pero sí una estrategia similar. Tiene en cuenta los niveles de soporte/cop, la tendencia, los retrocesos, el pullback y muchas otras cosas, sin utilizar indicadores externos (personalizados).
Llevo 3 años operando a mano con esta estrategia. Todo este tiempo estuve pensando cómo implementarlo y lo programé durante un año. Resultaron menos de 2000 líneas.
Todos los desarrolladores que pueden operar a mano, es más fácil para ellos cuando toman algunas barras como base para el análisis.
Pero un bar, aunque sea M1, ya es el pasado. Es inútil construir una estrategia en barras (especialmente en las más altas).
Debe hacerse utilizando cada garrapata.
En mi programa no hay un solo array (en sentido absoluto), y no analizo lo que había en el pasado, pero por supuesto recuerdo los puntos de control necesarios en tiempo real (no en arrays).
En resumen: lo que se hace a mano y se dibuja tan fácil y bellamente en un gráfico, no siempre se puede programar.
Se puede programar cualquier cosa, pero primero hay que desarrollar un algoritmo, y eso es una gran parte del trabajo. En esencia, primero debe convertir lo que ve en fórmulas y lógica, y luego programarlas. Y la primera se subestima muy a menudo.
Permítanme unirme a la discusión mientras estamos en ello ))))
....
De hecho, si hubiera sabido originalmente lo que ....., habría construido la lógica del EA de manera diferente.
....
Esta es una situación conocida. Antes de empezar a escribir el código, se planifica su estructura y la lógica de su trabajo, pero una vez que el algoritmo está listo y es totalmente funcional, se empiezan a añadir algunas otras condiciones y nuevas funcionalidades, y finalmente queda claro que es más fácil revisar toda la estructura y reescribir completamente toda la lógica, que seguir intentando encajar algún nuevo concepto en el antiguo algoritmo. Resulta que es más fácil replantear todo con nuevas funciones y condiciones y reescribir el algoritmo, pero lleva mucho tiempo.
Una buena ilustración del "resultado del trabajo sin proyecto".
todo el mundo no está contento con los demás, hay cero producción...