¿Quién quiere una estrategia? Lotes y de forma gratuita) - página 57
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 también puedes añadir la reducción en porcentaje, para que sea más fácil de ver. >> Gracias.
Esto puede ser el comienzo de un convertidor de FSB a MQL4.
Cualquier ayuda o comentario es muy apreciado.
Sería bueno si FSB podría generar una dll con la estrategia y la función podría ser como este:
que es enviar un número de barras a la dll y obtener una respuesta de la estrategia
La propia dll es así
de todas formas tienes todos tus propios indicadores y sólo necesitas datos de series temporalesProporcionaré el puente completo FSB <-> MT4 más tarde.
Así que FSB tomará la cotización y la información de la cuenta de MT y enviará de vuelta las órdenes de negociación. De este modo, podrá operar con las estrategias de FSB en MT.
Ahora estoy tratando de hacer algunos marcos básicos de EA para encajar las estrategias de FSB en MT como EA sin ningún tipo de interop.
Necesito varios patrones simples como:
* Introducir (añadir, reducir, cerrar) en la apertura de la barra (o valor del indicador) cuando:
- condición1 == true; y
- condición2 == true; y
- condición3 == true; y
- condición4 == true
* Salir al cierre del bar cuando:
- condición1 == true; o
- condición2 == true;
o
* Salir al valor del indicador.
o
* Salir en el Stop Loss permanente
o
* Invertir siguiendo las reglas de entrada.
La mayoría de los indicadores son estándar y los otros son bastante simples y pueden ser fácilmente reescritos en MQL4. Una vez que tengamos el patrón base del EA no habrá problema para trasladar los indicadores.
Las cosas que estoy probando ahora son:
Abrir la posición en la "Apertura de la barra" y cerrarla en el "Cierre de la barra".
Así que espero desarrollar dos nuevos productos:
1. FSB - Puente de alimentación y ejecución de datos de MT
2. exportador de estrategias a MQL4
Probablemente ambos programas serán de código abierto.
(oh, pensaba que el tema estaba tranquilo ahora... vamos a animarlo :)? (Voy a escribir mucho... intentaré ser lógico ;), y no sobrecargar el tema - lo dividiré en varios mensajes)
Señores, ¡bienvenidos!
Miroslav - en primer lugar, un par de palabras "sobre el tiempo" (la parte lírica)... (Espero sinceramente que su comprensión del ruso esté a la altura :))).
El producto, por supuesto, es impresionante. Hablo desde mi experiencia, como antiguo programador y como usuario abstracto (software abstracto). Se nota el cariño que se le pone (porque todo se hace con mucho cuidado) y hay esperanza de que el desarrollo del programa no se detenga "de repente" (no muera). Sí, lo más probable es que haya algunos errores lógicos (un ejemplo ilustrativo fue con Data Horizon), hay pequeños fallos en la interfaz... Pero en general - ¡ESTA ES LA CANCIÓN! ¡¡Es sólo una canción!!
Pido al público que preste atención a otro hecho revelador. La actitud hacia la crítica y el estilo de debate sobre los problemas/defectos/nuevas características/etc. Esto es yo en el contexto del comienzo del hilo, donde se inició el desarrollo del producto alternativo, y cómo el autor de la BLU reaccionó a los comentarios hechos a su dirección. No creo que Miroslav tenga también un "vagón" de tiempo para desarrollar un programa GRATUITO (y que sea tan programador). Pero encuentra tiempo para nosotros (para comunicarse), de acuerdo con nuestros comentarios y peticiones para finalizar el producto, corrige los errores y ofrece algo nuevo (ver sus mensajes recientes). Y todo con calma, con mesura, sin histeria, como en el citado caso de BLU. Eso merece un respeto (extra). Mis saludos, Miroslav...
Para terminar la parte lírica (distraídamente ahora) - que personalmente soy partidario de la teoría del "movimiento aleatorio de los precios". Es decir, en esta pregunta comparto completamente la opinión de un cierto círculo de personas (incluidos los creadores de sitios como http://www.bigmany.ru), que están convencidos de que el trabajo en el mercado (me refiero a Forex y "todo lo cercano a él") donde no hay manera de reconocer el segundo de (sólo) dos indicadores principales del mercado (me refiero a Volumen). - es sencillamente inútil y carente de sentido (carente de todo sentido razonable) confiar en cualquier información del análisis técnico y, en menor medida, del fundamental...
Podríamos haber terminado aquí en general :), pero como usted sabe - Rusia es notoria para los tontos y las carreteras, y utilizando el primer punto de esta declaración - Todavía no dejo la idea "para hacer millones" :D, de hecho - Sólo tengo curiosidad. Es interesante escuchar las "opiniones de los analistas" (como los astrólogos con sus horóscopos - "muchos especialistas", no sirven de mucho), es interesante sólo mirar los gráficos (estás de acuerdo - es increíble), es interesante trastear con los códigos (empiezas a entender realmente lo que la gente trata de expresar con determinados indicadores), ... Es simplemente interesante... Es interesante engañar (o mejor aún - NO engañar) al "sistema" un día... Por eso estoy aquí (en el mercado, condicionado). Y espero beneficiarme no sólo a mí, sino también al público. Porque como Miroslav - algún altruista por la vida.
Mi opinión actual es que los sistemas de análisis técnico que se utilizan actualmente en todo el mundo (y la clara mayoría) son, efectivamente, INVOLUCRADOS en el mercado. Es decir, la multitud de personas, mirando sus monitores y guiándose por los valores de sus indicadores, espera amistosamente un movimiento en una determinada dirección, hace tratos... y mueve ese mismo precio. Aunque sea a pequeña escala, aunque no siempre (todavía hay propietarios de "fábricas, periódicos, barcos de vapor" a los que les importa un bledo el AT, sólo necesitan comprar o vender un determinado volumen en un momento determinado). Pero sucede. En otras palabras, estando "en el bucle" (del mismo AT), puede intentar desplazar la probabilidad de sus movimientos aleatorios positivos en el mercado hacia (¿un poco?) más del 50%. No es fácil... ¡PERO es posible! Tan pronto como me decepcione este postulado, dejaré el mercado... (y no será por el tamaño de las ganancias/pérdidas, es que, bueno, es realmente frustrante e inútil trabajar dentro de un sistema completamente aleatorio... bueno, ver arriba)
Así que, ahora a los negocios.
1. Mientras ha habido una pausa aquí - he estado pensando. Sí, podemos esperar a Miroslav (cuando haga el puente entre MT y FSB, o aquí, el compilador de estrategias). Pero, al final, el que al menos hace algo por sí mismo obtiene el resultado :). Partí de la base de que tengo (garantizado) una herramienta determinada (FSB), tengo MT, supongamos, que además de estas dos entidades no habrá nada más - por lo tanto operamos dentro de su marco, a saber: FSB (por el momento) es un sistema cerrado; necesitaremos MT de todos modos; el código de asesor (robot de comercio) será necesario en cualquier caso - sí, debe haber una plantilla universal, que (aproximadamente) da los valores de los indicadores y todo, a continuación, de acuerdo con el "esquema aprobado"; por lo que necesitaremos indicadores mismos.
2. Me detendré enseguida en el código del Asesor Experto. No comparto el optimismo de los creadores de Asesores Expertos simples - bueno, es imposible imaginar el número de situaciones anormales en el terminal y el mercado. Y estamos hablando de dinero, no caben bromas (no han comprobado el código de error - han calculado alguna acción por defecto... y ya está, -1000 dólares desaparecen (condicionalmente)). Es decir, estoy convencido de que cualquier experto que se ocupe realmente del dinero (o, mejor, del dinero real) debe ser "férreo" en cuanto a las reacciones a los acontecimientos externos. El código debe prever un número máximo de variaciones en el terminal, el servidor o el propio mercado. En resumen - es bastante grave, y no se puede resolver (escrito) con un salto. Estaría encantado de participar en la creación de dichos patrones. Pero...
3. He decidido ir hasta el final desde el fondo. ¡Tuve una idea - si no hay nada con lo que operar en un Asesor Experto (indicadores en sí), entonces para qué necesitamos un Asesor Experto en absoluto :)! Así que tomé los indicadores.
La premisa era la siguiente. En primer lugar, nadie garantizará que los valores de los indicadores en el FSB sean equivalentes a los valores de los indicadores estándar o adicionales en la MT. Y para obtener resultados "comparables" en ambos programas, los valores deben ser los mismos. En segundo lugar, el número de indicadores propios (estándar) es SIEMPRE diferente. Y para utilizar (y buscar) los externos... de alguna manera me gusta el estándar o el propio (en la vida)... (Tercero - tengo la impresión de que la "conversión" del código de los indicadores de FSB no es una tarea tan grande, como mencionó Miroslav - los algoritmos en sí son bastante simples, los indicadores en sí están muy "organizados" en términos de código (el código está unificado), es decir, a grandes rasgos - crean un conjunto de errores.A grandes rasgos, creamos una plantilla una vez y la "llenamos" con algunos índices uno a uno (esta es la imagen ideal del mundo :))). Hay más en el cuarto - me preguntaba :).
En fin, de eso se trató el fin de semana. Antes de empezar algo, suelo "tomarme un buen tiempo para aprovechar" (en este caso, pensar). No tengo tiempo para modificar la plantilla en sí (lo entiendo). Especialmente cuando el número de indicadores supera una cifra determinada. Así que los puntos clave deben ser diseñados de una vez. En consecuencia, hice las siguientes suposiciones:
- Estos deben ser indicadores (y no sólo funciones para el futuro código del Asesor Experto). Después de todo, la percepción visual de la información no juega el menor papel para un humano (y para mí, en particular), y la llamada de un indicador desde el código del Asesor Experto no es un problema tan grande (el iCustom ya ha causado muchos problemas en el foro - cuando hay tantas opiniones, por lo general prefiero comprobar todo yo mismo, los resultados de mis "pruebas de campo" va a hacer, probablemente hay una pequeña sobrecarga, pero no es un gran (esto lo declaro con plena responsabilidad) y creo que puede ser descuidado en términos de universalidad). Pero para los "conocedores especiales" :) (por si acaso) en caso de que los cálculos en los indicadores se realicen en una función separada del mismo tipo (véase más adelante).
- Los indicadores deben emitir los mismos valores que en el FSB original (elemento negociado por separado más abajo). Es decir, se toma como base el código de FSB y, a ser posible, se modifica lo menos posible.
- El código debe ser optimizado para que funcione correctamente con IndicatorCounted (es decir, por la velocidad)
- Los parámetros de los indicadores, así como sus valores, deben ser uniformes y homogéneos. No estoy hablando de tipos de datos, como tal. Si miras el código de los indicadores de Miroslav, puedes ver una buena homogeneidad de los parámetros de entrada y los buffers de salida. La tarea consiste en mantener la imagen inicial para ayudar a los usuarios a guiarse fácilmente al indicar los parámetros o tomar los valores de los indicadores.
- La implicación del punto anterior es... mm (atención - esto es importante). La clave del uso de todos los indicadores no es que generen valores propios. Es que producen ¡SEÑALES! Realmente, para mí como persona - ¿qué diferencia hay en el valor de un índice ahora o después(?) Sigue siendo "cifras incomprensibles". Comprensible es cuando se trata de 'Comprar' o 'Vender' :). Todo lo demás es "poco claro". Miroslav utilizó esta idea de forma muy elegante creando dos buffers en cada indicador (para posiciones largas y cortas) que, dependiendo de cómo se utilice el indicador (como Punto de la Posición o Condición Lógica), obtienen valores de apertura/cierre de una posición o del filtro Sí/No (si todos los "Sí" en la lógica de apertura - abrir, si al menos un "No" en la lógica de cierre - cerrar (en general RTFM). ¡Genial! ;) He seguido este camino y he simulado este comportamiento. En este momento, los dos primeros buffers del indicador (cuyos valores se pueden ver en la Ventana de Datos) son los correspondientes a los filtros (1/0) o a los valores del precio para abrir posiciones al lado largo o corto, respectivamente, es decir Más tarde, al utilizar los indicadores en el código del Asesor Experto, no le importa realmente qué, dónde o qué valores genera un indicador en particular - sólo analizará los valores de los dos primeros búferes para un tema muy simple (Sí/No (condicionalmente) o toma directa del precio a partir de ahí) ... Y eso es todo. Hay un matiz - casi el 100% "tropezará" en Ishimoku (allí, la cantidad de búferes propios del indicador está cerca del límite de la propia MT (8)) - No quiero rechazar una buena idea (con los dos primeros topes), pero no puedo combinarlos en uno solo (estaba pensando... no sólo puede haber 1/0 (que podría convertirse en una máscara de bits), sino también etiquetas de precio). Lo más probable es que tenga que hacer algo con los propios valores de los indicadores... Veremos... Mientras vamos...
En general, en resumen (resúmenes): calidad (compatibilidad con FSB, libre de errores, etc.), facilidad de uso posterior, velocidad, legibilidad del código. En este orden.
Bueno, y (en realidad) - lo que pasó ... (breve historia)
- Todos los indicadores tienen el valor "fsb" en el prefijo del nombre del archivo (ejemplo: "fsbBlaBlaBla.mq4").
- Tomé los indicadores en un orden pseudoaleatorio, así que no me culpes. Hasta ahora, hay, eso es. Para mayor discusión/análisis, etc. - Creo que es suficiente.
- Miroslav usa tres funciones externas (que se colocan en las fuentes (en la parte inferior de la página)) para calcular la media móvil y los valores de los búferes lógicos. Tuve que empezar con ellos. Todas las funciones están empaquetadas en un archivo (" fsbCommon.mq4 "), dispuestas como funciones de biblioteca (" fsbCommon.mqh "). Hay otro archivo de esta ópera (" fsbConstants.mq4 "), que, respectivamente, contiene constantes por conveniencia en el código. No hubo problemas especiales con las funciones en sí (compliqué un poco la lógica inicial de los "osciladores lógicos", para verificaciones adicionales (matrices fuera de límites, valores iniciales correctos garantizados (el primero en la historia) (Miroslav, hay un error lógico en el código sobre este tema).... e intenté durante mucho tiempo "emular" el comportamiento de iShift en MovingAverage para que la función complete correctamente los valores del búfer resultante para cualquier valor sensato de este parámetro (y no solo por aquellas restricciones que se dan en el código original original) ... como resultado, abandoné este asunto por ahora, poniendo un "stub" al principio (con iShift distinto de "0" la función no trabajo todavía, que, sin embargo, aún no se ha necesitado)). MovingAverage resultó ser engorroso, pero mata varios pájaros de un tiro. Dado que devolver el búfer de la función como un valor en MT no es posible (tal vez no necesario) - apareció un parámetro adicional al final ( afTarget ) Además, considerando IndicatorCounted (), un paso más El parámetro es responsable del valor de la primera barra para el procesamiento. Bueno, el último parámetro adicional establece la "constante de precio" en términos de MT, por cuyo valor se calculan los valores de MovingAverage en sí mismos en función de las matrices de series existentes, o (si el valor Precio aplicado fuera de los valores de "constantes de precio" MT) - basado en afFuente . (de ahí la sobrecarga del código) Inmediatamente especificaré el matiz de la programación - donde hay ciclos intercalados con selecciones por caso - los ciclos se insertan dentro de las selecciones, y no (lo que suele ser más lógico) al revés. Hecho no porque no sepa cómo hacerlo bien, ¡sino porque sé qué tan rápido :)! (bueno, en el futuro, no me detendré en esto, quien quiera analizar el código, de nada, pero antes de hacer la pregunta "sobre la estupidez del código", piense un poco en lo que (potencialmente) podría causar tal programación).
Otro matiz está relacionado con MovingAverage (puede ser informativo para alguien), porque. Los valores de la media móvil en los modos de suavizado exponencial (incluido el suavizado) dependen directamente de sus propios valores anteriores: la elección del "punto de partida" se vuelve muy importante (qué valor tomar como base para cálculos posteriores). Por lo general, hay varios enfoques para esto. Alguien toma el precio de cierre del período anterior. Alguien promedió el precio del período anterior N... Miroslav tomó el segundo camino. MT claramente viene primero. De ahí las importantes discrepancias en estos dos modos de suavizado al principio del gráfico (¡agregué un espacio en blanco para probar el promedio móvil y todo lo demás (" fsbTest.mq4 "))! Y las restricciones impuestas por mí dentro de la función sobre la disponibilidad de datos del propio MovingAverage ANTES DE iFirstBar, o una cantidad similar de valores calculados DESPUÉS Primera barra. Porque los indicadores en sí usan una constante para el valor mínimo de las barras en el gráfico (ahora 2000); esto debería ser suficiente para cualquier situación (porque aún no he visto parámetros con períodos mayores a 200). A menos, por supuesto, que se use más de un MA a la vez ;).
- Por analogía con el párrafo anterior, se crearon archivos para subfunciones externas que ya utilizo en mi trabajo con este proyecto (prefijo "st": " stCommon.mq4 ", " stCommon.mqh ", " stConstants.mq4 ")
- Bueno, en realidad - los propios indicadores. En términos muy cortos (tomemos " Bar Range " como ejemplo):
tipo de ranura conjuntos tipo tragamonedas en Términos FSB (Punto de la Posición o Condición Lógica) . Esos indicadores que pueden ser no solo filtros de entrada/salida, sino también establecer el precio de apertura/cierre: este parámetro determina exactamente lo que generará el indicador en sus búferes lógicos. Ver todas las constantes en fsbConstants.mq4 (todo está bastante claro allí)
indLogic - de hecho, una condición lógica para el indicador (lleva una carga semántica diferente, dependiendo del valor tipo de ranura )
Bueno, los parámetros van más allá, en el orden en que aparecen en las fuentes de indicadores en forexsb.com, y cómo se muestran en el propio FSB. Los límites de los parámetros se especifican en los comentarios y se controlan al llamar a init() llamando a la subfunción PCheck().
Con los búferes, todo lo que se encuentra a nivel global se usa como búferes de indicadores (adjuntos al propio indicador). Solo los lógicos deseados (LPIndBuffer[], SPIndBuffer[]) (siempre y siempre en este orden (#0 - posiciones largas, #1 - posiciones cortas)), IndBuffer[] - datos del propio indicador. Pero en este caso, dado que se usa un histograma de color, este búfer solo transporta los valores en sí mismos, y se usan dos búferes adicionales para la reproducción del color (para ser honesto, MT comenzó a programar simplemente transfiriendo indicadores :), y ¿cómo puedes simule el comportamiento de los histogramas de color dentro de MT de lo contrario: nunca se me ocurrió (¿quién puede decirlo? Si esto es posible)). No se muestran en DataWindow de ninguna manera.
EN en eso() todo es como de costumbre (se verifican los valores de los parámetros, se establecen los nombres del indicador y los índices, se adjuntan los búferes, etc.)
En deinit(), estoy pensando en insertar lógica en caso de NO cerrar el indicador (conveniencia adicional, para que los parámetros allí no se restablezcan, etc.), en mi tiempo libre (aún no es una prioridad).
comienzo() muy primitivo Su tarea es verificar que haya suficientes barras en el gráfico (para calcular cualquier MA y en general) y llamar a la función para calcular el indicador en sí, luego de la llamada exitosa, se llama al dibujo personalizado del indicador (si es necesario). ser dibujado de alguna manera de una manera especial, como en este caso como -once)
Calcular() - cálculos reales. El código, en general, es similar al código de Miroslav, se hacen excepciones para optimizaciones relacionadas con IndicatorCounted(). Si se requieren búferes de indicador adicionales para calcular el indicador, se configuran dentro de la propia función (estático) (para no desperdiciar los índices del indicador en sí), y son atendidos por la función BufferSync(). Aquí hay una broma separada: inicialmente hubo un intento de limitar los cálculos con un parámetro constante más (iMaxBars). "Pruebas de campo" (parte 2) del comportamiento de arreglos de series en presencia de historia, ausencia, movimiento hacia el futuro (la llegada de comillas, aumento de arreglos a la DERECHA (ahora estoy visualmente, sobre la representación gráfica )), ... movimiento al pasado (cuando falta el historial (nos movemos hacia la izquierda en el gráfico) y el terminal lo carga desde el servidor... y las matrices se expanden hacia la IZQUIERDA)... Entonces. .. Se separó. Lo hice maravillosamente (traté de hacerlo) - dependiendo de la dirección de la expansión BufferSync () y expande la matriz resp. izquierda o derecha, completando los valores vacíos EMPTY_VALUE. Aquí solo MT normalmente no expande las matrices de índice a la IZQUIERDA. SIEMPRE los expande hacia la derecha (desde el lado de [0] Bar). Espero que quede claro de lo que estoy hablando: que durante el próximo salto en la historia, cuando el valor de las barras en el gráfico exceda iMaxBars (saltando, nuevamente), las situaciones son bastante posibles cuando el indicador no dibujará sus valores. a la izquierda de iMaxBars, pero aquí hay "datos extraños", a la izquierda de iMaxBars puede ser fácilmente. Tal vez nadie los mire ... Pero "no hermosos" (no es nuestro método). Y todo lo que se necesita es que MT en sí mismo complemente los búferes con valores vacíos en la dirección correcta... Es potencialmente posible detectar tal situación, pero... En general, dibujamos desde el comienzo mismo del carta... _siempre_. (Bueno, en la medida de lo posible para este indicador en particular)
Otro matiz está asociado con IndicatorCounted(), al parecer, una función divina. Devuelva los valores de las barras calculadas y no habrá reclamos en su contra... ¡SERÁ! Creo que no es el indicador contado () en sí mismo el culpable (así como los programadores de MQ), sino un grupo de programadores de indicadores personalizados, que no han alcanzado el propósito divino de esta función. Por lo tanto, se ve obligado a devolver siempre una pequeña cantidad de valores potenciales. O recalculamos el gráfico completo (IndicatorCounted() == 0), o el primero ((IndicatorCounted() == Bars - 1) o dos (IndicatorCounted() == Bars - 2) barras. Lo que quiero decir es que, por ejemplo, si la conexión se interrumpe y el gráfico "corrió" más de una barra por delante - eso es todo... "los árboles murieron en pie" (IndicatorCounted() == 0) - contamos todo el gráfico en un nuevo ¿Por qué? era imposible devolver el número de compases saltados (3, 4, ... 5... 10...)? (que es para lo que estaba pensada esta función, según tengo entendido, inicialmente) En general, así. ..
... Me "tropecé" con el RSI. Y en todos los sentidos. En primer lugar, no entendí el código de Miroslav (las preguntas para él irán más abajo). En segundo lugar, mientras probaba el indicador, vi discrepancias en los valores obtenidos dentro de MT y FSB. No, no es en absoluto lo que pensabas ("soportado torcidamente", bueno, admítelo, pensaste;)). El punto, desafortunadamente, parece estar en estas declaraciones:
Hablando brevemente - ¡ flotar ! Después de pensarlo un poco, disminuí la velocidad por el momento. la primera tesis (precisión y calidad) se ha vuelto cuestionable (y es una prioridad).
Aquí es posible el siguiente razonamiento: por un lado, la flotación no es mala, es, por así decirlo, un "desgaste" de los valores del indicador, lo que debería hacer que la estrategia comercial sea aún menos susceptible a picos aleatorios en el mercado. Por otro lado, por ejemplo, al cruzar algún fLevel (1.0, por ejemplo), estarás de acuerdo: 0.99998 y 1.00001 son dos grandes diferencias :). Y hay tales discrepancias. Y si la pose se abre en tal o cual momento, pero de hecho el nivel de FSB aún no llega a 1.0 y baja, ¿quién tiene la culpa? (¡¿el que transfirió los indicadores :D?!)
En realidad, hay dos soluciones (¡dado que float MT no es compatible!):
- emular un flotador en el propio MT (con algunas construcciones desgarradoras como NormalizeDouble(X, Digits + 2) ) - bueno, no en todas partes, pero considera que cada multiplicación/división por cualquier
- cambio de flotador en FSB a doble. Aquí debe comprender el alcance de los cambios, obviamente finitos, pero debe caminar con cuidado por todas partes. Y que el resultado potencial de las estrategias generadas en humanos pueda “flotar”. Y en general, ¿Miroslav lo necesita? (mi humilde opinión es que el propio FSB lo necesita, porque el extra de precisión nunca ha perjudicado a nadie, pero a la velocidad de los cálculos (si se perseguía este objetivo (?), pues no veo más razones) en este tramo horario de la realidad No debería tener ningún efecto significativo.) Estoy de acuerdo en este tema con los muchachos de MQ, porque. si no operamos con matemáticas enteras (algún Decimal), entonces al menos lo intentaremos con la máxima precisión posible. En general, aquí hay una pregunta tan ... no fácil ...
Perdón por la verborrea (no diré más, sólo la esencia).
Me gustaría escuchar una opinión - ¿debería continuar este tema (y luego "ir" más allá, el resto de los indicadores para cavar)? Puedo incluso en algún orden (ya que todos los mismos el lío original :)), que, tal vez, lo que necesita para seguir adelante. El tiempo, por desgracia, en el caso general se priva (director general adjunto en su despacho - "el día pasa volando" :D). Encuentro el tiempo normalmente por la noche. Pero uno o dos indicadores al día, creo que puedo proporcionar...
Así que, preguntas para Miroslav sobre el tema...
1. ¿Cuál es el valor de fMicron? (Lo puse (por reflexión) en 0,000001, parece, ¿o es aún más pequeño?
2. Cuál es el parámetro bIsDescreteValues (en la lógica del oscilador). Entiendo su significado, pero ¿cuál es su valor por defecto? ¿Y de qué condiciones depende el cambio? (o digamos - con qué está relacionado (en la interfaz del FSB o donde sea))
3. En realidad sobre RSI, ¿qué es este diseño?
:)? La motivación de la pregunta es la siguiente: Si mi visión es correcta, se trata de un MA suavizado. En el contexto de todo el código - se aplica a MA ya calculado y genera MA suavizado, donde sólo el primer valor permanece "vivo" :). Una pregunta lógica: ¿qué es lo que sobra aquí? Esta construcción, que entre otras cosas hace REALIZADO(!) la elección de los modos de suavizado de RSI en el propio indicador (siempre sale suavizado), así como en sus dependientes. ¿O cálculos previos de MA (con el modo correcto de los parámetros) para afPos, afNeg?
Evidentemente, el RSI clásico se basa en la media suavizada. Pero hay al menos una variante con Simple MA y sería lógico eliminar el código anterior haciendo operativo el comportamiento del parámetro maMethod. O eliminamos el cálculo de la MA antes de este ciclo y eliminamos los parámetros de la MA RSI en todos los indicadores (¡ya que no afectan a nada de todos modos!).
Yo eliminaría este código (arriba) :). (En el indicador convertido esta parte está comentada, quien necesita la funcionalidad original - ¡elimina las etiquetas de comentario! El código RSI es sólo de referencia... Hasta que lo decidamos aquí, yo lo usaría "bajo mi propio riesgo" :))
4. Como ya se ha dicho hay un error lógico no crítico en la lógica de los osciladores en el comportamiento en las barras iniciales. Ahora no puedo distinguirlo, mañana lo escribiré (dónde y cómo corregirlo).
5. ¿Qué hacemos con elflotador en el FSB? (o con la falta de ella en MT) :)?
El archivo contiene los ficheros necesarios, descomprimidos en la raíz de MT (el archivo estará en el próximo post)
Buena suerte a todos... escribir :)Archivo de indicadores actuales (2009-04-15)
Estoy de acuerdo en que la flotación no funciona: hay que buscar una salida. Tenemos que escribir la correspondencia. A continuación, cree una biblioteca de indicadores. Si puedo ayudar, será un placer.