NECESITO UN PROGRAMADOR

 

Necesitamos escribir un EA que construya canales y opere en ellos en modo semiautomático.

Descripción del programa:

A partir de tres extremos adecuados en el gráfico, el programa construye un canal que se muestra en azul. Llamemos a este canal desbloqueado. Se puede cambiar y mover en el gráfico con el ratón. Cuando llega un cuarto extremo, el programabloquea el canal y cambia su color a verde si el extremo toca la pared del canal. Si un extremo está fuera de lugar, el canal se reconstruirá automáticamente dentro de ciertos límites o se borrará. Un canal bloqueado no se modifica ni programada ni manualmente, pero puede desbloquearse, por ejemplo, haciendo doble clic en él o seleccionando la opción adecuada en el menú contextual (según lo que resulte más fácil de hacer) y modificándolo y bloqueándolo de nuevo.

Cuando aparece un canal verde en un símbolo determinado en un marco temporal determinado, el programa sigue buscando extremos y construye otros canales. Así, se pueden mostrar varios canales en el mismo gráfico al mismo tiempo y no deben ser aproximadamente iguales, pero se permite mostrar canales uno dentro de otro. Cuando el precio se desplaza fuera del canal y permanece allí durante algún tiempo, el canal se borra.

Cuando el precio alcanza la pared del canal verde, se comprueban los indicadores adecuados y se abre una posición. Sólo se puede abrir una posición dentro de un canal a la vez, pero si hay canales de plazos inferiores dentro del canal, se pueden abrir posiciones adicionales.

El programa debe operar en los marcos temporales M1, M5, M15, M30, H1, H4, y en varios instrumentos al mismo tiempo. Todos los canales deben mostrarse simultáneamente en todos los marcos temporales con sus correspondientes etiquetas (por ejemplo, "M5" junto a la esquina superior izquierda del canal). Sin embargo, el código debe implementarse de forma que se pueda desactivar fácilmente la visualización del canal en marcos temporales superiores o inferiores (por ejemplo, no mostrar los canales M1 en H1, etc.) o bloquear la operación en determinados marcos temporales (por ejemplo, operar sólo en H1 y M15).

El código debe implementarse de tal manera que sea fácil deshabilitar (por ejemplo, comentando algunas partes del código) algunos marcos temporales, pares de divisas y todo el gráfico, con el fin de ahorrar recursos durante la optimización posterior. Además, el código debe ir acompañado de comentarios detallados. Las variables y funciones deben ir acompañadas de comentarios detallados sobre su finalidad, incluyendo contadores y banderas.

Algunas variables deben contener los valores de la anchura del canal y su pendiente respecto al eje horizontal (el valor de la variable es positivo si el precio sube, negativo si baja).

Para evaluar el programa, necesitaré capturas de pantalla de su trabajo y fragmentos de código para determinar la comprensibilidad de los comentarios. En consecuencia, cuanto más sencilla sea la estructura del programa, mejor.

Estimados programadores, espero sus sugerencias.

 
¡Una tarea seria! Pero en principio es factible. ¿Cuánto le gustaría ofrecer por el trabajo?
 
LSB >>

Basándose en los tres correspondientes *relevantes a qué? Se refiere a los tres últimos extremos del gráfico, el programa construye un canal, que se muestra en azul. Llamemos a este canal desbloqueado. Se puede cambiar y mover en el gráfico con el ratón. Cuando aparezca un cuarto extremo, el programabloqueará el canal y cambiará su color a verde si el extremo toca la pared del canal *¿Qué quiere decir? Si un extremo está fuera de posición, el canal cambiará automáticamente su posición dentro de ciertos límites o se borrará. Un canal fijo no se cambia ...No se puede hacer manualmente* con herramientasMQL, que yo sepa .Siempre se puede modificar manualmente* cualquier canal del gráfico , pero se puede volver a desbloquear, por ejemplo, haciendo doble clic o eligiendo la opción correspondiente en el menú contextual (según lo que resulte más fácil), modificarlo y volver a bloquearlo.

Es más difícil entender los TdR hasta el final que escribir el código)) Parece que no es gran cosa.

 
Fduch писал(а) >>

Es más difícil entender los TdR que escribir el código). Parece que no es nada grave.

Haz el trabajo y luego cuéntame lo fácil que te resultó :-)

 
Integer >> :

Hazte cargo de la implementación y luego cuéntame lo fácil que te resultó :-)

¿Hay algo en este pliego de condiciones que pueda causar dificultades de aplicación? >> aparte de lo que he destacado en el post anterior.

 
Fduch писал(а) >>

¿Hay algo en este pliego de condiciones que pueda causar dificultades de aplicación? *Aparte de lo que he destacado en el post anterior*.

Hay algo en lo que hay que pensar mucho, pero parece que no tienes ni idea, así que me abstendré de explicarlo por ahora.

 
Integer >> :

Hay algo que hay que pensar, pero parece que no tienes ni idea, así que me abstendré de explicarlo por ahora.

¡Un acertijo TK! =)

¿Y cuánto crees que le costaría al cliente escribir un experto en esta RPT? *En mi opinión, no es más caro que 40 dólares por 20 dólares/hora de trabajo del programador*.

 
Fduch >> :

¡TK-jiggle! =)

¿Y cuánto crees que le costaría al cliente escribir un experto en esta RPT? *IMHO no más de 40$ por 20$/hora de trabajo del programador?

con la precisión del primer puesto hasta el más mínimo de los matices

y manejar los niveles de paso del ratón con la apertura de posiciones adicionales dentro del canal

y mostrar (como no lo describió el cliente por cierto) y no mostrar canales m1 en h1 etc.

"no debería ser aproximadamente lo mismo" ¿escribirías un programa de recuperación de imágenes? por 20 dólares la hora?

y así sucesivamente y hacer capturas de pantalla en 2 horas?

--

bueno... ¡buena suerte! y lo más importante, el tiempo, desde el inicio de la aplicación hasta el final

para que el cliente no le escriba una carta diciendo que esto no es lo que quería

--

¡A veces pensamos que es muy sencillo! ¡Y el mundo es transparente y no hay "tocones" con los que tropezar!

pero normalmente no lo es.

 
Sí, me equivoqué con todo el TdR: las capturas de pantalla, los comentarios y una estructura lógica del programa llevarán mucho más tiempo. Pero el código en sí es bastante realista para escribirlo en 2 horas, ¿no te parece?
 
Fduch писал(а) >>
Pero el código en sí es bastante realista para escribirlo en 2 horas, ¿no te parece?

Estoy de acuerdo, si escribes a 300 caracteres por minuto.

 
Fduch >> :
Sí, me equivoqué en cuanto a los TdR completos: las capturas de pantalla, los comentarios y la estructura lógica del programa requerirán mucho más tiempo. Pero el código en sí es bastante realista para escribirlo en 2 horas, ¿no te parece?

No, no estoy de acuerdo.


---

Empiezas escribiendo este trozo de RPT en 10-30-240 minutos = "no debería ser aproximadamente lo mismo" ---

Créanme que esto no es algo trivial.

( lo que es aproximado es una sustancia bastante subjetiva )

¡Tendrás que comparar dentro de unos límites algún objeto en forma de al menos 3 puntos!

Tendrás que usar un ritmo convencional, en realidad un triángulo según las reglas y cortar los objetos similares.

(e incluso no sólo cortar y que el autor de TK apruebe este corte

---

Estoy de acuerdo en que estás exagerando.

no es tan sencillo, pero si se habla con el autor de la RPT, se pueden resolver algunas cosas

pero no puedes hacerlo en 2 horas - incluso si tienes las bibliotecas listas ---

--

Yo, por ejemplo, ¡siempre dedico entre 3 y 4 veces más tiempo al trabajo de lo que espero!

sabiendo que podría encontrar un "tocón"... ¡con un problema que no esperaba!