Comparación de la media móvil (y cualquier otro indicador) y el error - página 3

 
Dina Paches:

Gracias, Artyom, pero desgraciadamente resulta que también puede tener límites.

Espero no haber matado a nadie.
 
Artyom Trishkin:
Espero que no hayas matado a nadie.

No lo sé. No tiene nada que ver con mi entorno).

 
Dina Paches:

No lo sé. No tiene nada que ver con mi entorno).

¿Y qué hay de un bicho? ¿No? Lástima... ;)
 
Artyom Trishkin:

Bien, en primer lugar, la diferencia de dos valores normalizados dará finalmente un valor no normalizado. Hay que comprobar la diferencia normalizada.

En segundo lugar, si quiere capturar cruces dentro de una barra, tome los valores de todos los ticks en el cero y en la primera barra - capturará muchos ... ...sólo ten cuidado...

Si hace la prueba por la apertura de una barra, el Asesor Experto debe obviamente rastrear la apertura de una nueva barra y, después del hecho, comprobar los cruces.

Si quieres operar en la apertura de la barra o en cada tick, entonces escribe tu código. Y, en consecuencia, probarlo de la misma manera.

En primer lugar, escribí en el primer post que estoy operando sólo en la apertura de la barra. Hay una sutileza en el comercio de ticks. Puede obtener una señal, pero visualmente no habrá ningún cruce en el gráfico, porque se dibuja sólo a ciertos precios (apertura, cierre, etc.). No se dibuja con garrapatas. En este caso, explicar al profano que sí, no hay ningún cruce en el gráfico, pero porque es específico para el dibujo de muwings en la visualización sólo por valores espaciados (de nuevo, los precios de apertura y cierre, etc. - aproximación, si es que ha oído tal palabra) y no por tildes. En segundo lugar, la normalización de las diferencias no tiene sentido. NUNCA sabrás de antemano a qué signo tienes que normalizar para no obtener exactamente 0 (por no cortar estúpidamente todos los dígitos significativos). Llevo bastante tiempo dedicándome a la programación y, en relación con ello, entiendo bastante bien las matemáticas computacionales (en mi ocupación principal, la modelización de la física, donde tengo que luchar constantemente con la precisión de los cálculos). De hecho, en general, la normalización es una gran simplificación, si no se quiere profundizar en los entresijos de las matemáticas del cálculo, los errores, etc. Si te consideras tan gurú y no estás dispuesto a rebajarte a leer todo el tema con detenimiento y luego sacar conclusiones, eso es una cosa. Si ese no es el caso y también está operando en la apertura de una nueva barra, entonces intente probar su robot en la barra del 29.07.2015 a las 3:20 con los parámetros de dos SMAs 5 y 34 aplicados al precio de cierre, en un marco de tiempo de un minuto. Exactamente la situación en la que las mutaciones dentro de la misma barra se cruzan dos veces. Y esta situación no es realista cuando el comercio no se basa en los ticks. ¿Recibirá su robot de trading ambas señales? Y lo más importante, la respuesta a la pregunta de por qué en la misma barra la diferencia de muwings (o más bien sus valores iniciales) en diferentes momentos no es igual, no se ha dado todavía (sólo Alexey Lebedev lo ha intentado, gracias por ello, pero es sólo una suposición...). Y es imposible responder sin conocer los principios del funcionamiento de la AMI.

P.D. Sólo para charlar, creo que hay hilos especiales en el foro, si no quieres entrar en el núcleo del problema.

 
Dina Paches:

Gracias, Artyom, pero desgraciadamente resulta que también puede tener límites.

Gracias por el consejo, por supuesto, pero puedo leer la Ayuda por mí mismo. Y, de nuevo, las matemáticas computacionales no están vinculadas a un lenguaje de programación concreto. Son precisamente los errores de cálculo con los que hay que lidiar.
 
gammaray:
...

Sigue reinventando el hiperboloide. Siempre me funciona y cuenta correctamente. Ah, sí, lo siento, no soy un gurú en su matemática computacional, no invento mierda - hago programas para MT4 y MT5. Y te sigues haciendo el listo, si no quieres escuchar lo que te dicen (y no se trata de un libro de texto).

Repito - si operas en la apertura de una nueva barra - la pregunta es: ¿por qué necesitas una cruz dentro de la barra (te importa? Si es así, te aconsejaré cómo hacerlo, si no - olvídate de ello).

No voy a utilizar mi robot en su serie temporal - dejé de operar con MAHs hace mucho tiempo. Y el hecho de que los MAE sobrepasan la barra cero cuando se calculan utilizando todos los precios excepto el precio de apertura es conocido hasta por un escolar. ¿Para qué necesitas explicar a alguien que estaba ahí y ahora se ha ido si operas en la apertura de una vela? Así que en la apertura y tomar los datos de la MAA.

¿Dónde encontró el problema? Aquí está tu cruz:


¿Puede darme un código que identifique correctamente este cruce?

 
Artyom Trishkin:

Sigue reinventando el hiperboloide. Siempre me funciona y cuenta correctamente. Oh, sí, lo siento, no soy un gurú en su matemática computacional, no invento mierda - hago programas para MT4 y MT5. Y te sigues pasando de listo, ya que no quieres escuchar lo que te dicen (y no se trata de un libro de texto).

Repito - si operas en la apertura de una nueva barra - la pregunta es: ¿por qué necesitas una cruz dentro de la barra (te importa? Si es así, te aconsejo cómo hacerlo, si no - olvídate de ello).

No voy a utilizar mi robot en su serie temporal - dejé de operar con MAHs hace mucho tiempo. Y el hecho de que los MAE sobrepasan la barra cero cuando se calculan utilizando todos los precios excepto el precio de apertura es conocido hasta por un escolar. ¿Para qué necesitas explicar a alguien que estaba ahí y ahora se ha ido si operas en la apertura de una vela? Así que en la apertura y tomar los datos de la MAA.

¿Dónde encontró el problema? Aquí está su cruce:


¿Puede sugerir un código que identifique correctamente este cruce?

No estoy inventando el hiperdolo. Si quisiera inventarlo, no le habría preguntado nada. Y no me estoy haciendo el listo; estoy dando contraejemplos (incluyendo tu normalización favorita). En cuanto a los cruces dentro de un bar. Las TS más primitivas en MA abren operaciones en su intersección. En el siguiente cruce en sentido contrario, lo primero es cerrar la operación abierta en el cruce anterior, y abrir una nueva en sentido contrario. Si se me escapa un cruce (y en el caso de cruce dentro de la barra dos veces, por así decirlo, será así), entonces se me escapa una señal. Y en consecuencia no cierro la operación actual. Y mi robot tiene dos operaciones activas, aunque siempre debería haber una operación en este TS. Por eso es importante cualquier cruce. Además, con respecto al precio en la apertura de una vela. En este caso, la mayor parte de las señales de cruce se perderán si tomamos, por ejemplo, los valores de la MA a precios de cierre. Un ejemplo sencillo - tomamos el precio de cierre de la MA (no importa cuál tomar para una nueva barra ya que acaba de aparecer; todos los valores de МА serán iguales). Imagínese la situación cuando las MAs se cruzan en algún lugar en el medio de la barra recién aparecida pero en el precio de apertura no se cruzan. En la siguiente barra nueva, esa intersección se pierde por completo porque tomamos el precio de cierre de la barra anterior (y se cruzaron en algún lugar entre los precios de apertura y cierre). Las señales vendrán sólo en ese caso raro que fue descrito originalmente por mí cuando la MA cruza precisamente en el precio de cierre de la barra. Significa que si la barra actual está abierta, ya hay una limitación de que МА se aplique a los precios abiertos.

He tratado el ejemplo que di introduciendo una desigualdad no estricta. Intente probar la barra de mi post anterior (donde hay dos cruces de MA en una barra) y vea si su robot detecta esos cruces? Si sólo funciona cuando aparece una barra, es imposible. Sólo si funciona por garrapatas. Y ya he descrito las trampas que hay ahí

 

Nunca es necesario normalizar nada cuando se comparan dos números reales.

Si los números son realmente iguales, se almacenan en la memoria por igual. En realidad, es precisamente gracias a esta propiedad que pueden existir las máquinas de computación.

Por lo tanto, las comparaciones de la forma si(a<b) o si(a==b) son correctas en cualquier caso y no se requiere ninguna normalización.

Si la mente inquisitiva de un investigador encuentra una contradicción con esta regla, significa que, o bien su máquina está averiada, o bien su mente. Uno de los dos.

La ayuda y la documentación, por supuesto, deben ser leídas al menos en ocasiones (también fueron escritas por humanoides como nosotros), pero es necesario tener un razonamiento propio y sensato.

 
gammaray:

No estoy inventando el hiperdolo. Si quisiera inventar, no estaría preguntando nada aquí. Y no me estoy haciendo el listo, sino dando contraejemplos (incluso para tu normalización favorita). En cuanto a los cruces dentro de un bar. Las TS más primitivas en MA abren operaciones en su intersección. En el siguiente cruce en sentido contrario, lo primero es cerrar la operación abierta en el cruce anterior y abrir una nueva en sentido contrario. Si se me escapa un cruce (y en el caso de cruce dentro de la barra dos veces, por así decirlo, será así), entonces se me escapa una señal. Y en consecuencia no cierro la operación actual. Y mi robot tiene dos operaciones activas, aunque siempre debería haber una operación en este TS. Por eso es importante cualquier cruce. Además, con respecto al precio en la apertura de una vela. En este caso, la mayor parte de las señales de cruce se perderán si tomamos, por ejemplo, los valores de la MA a precios de cierre. Un ejemplo sencillo - tomamos el precio de cierre de la MA (no importa cuál tomar para una nueva barra ya que acaba de aparecer; todos los valores de МА serán iguales). Imagínese la situación cuando las MAs se cruzan en algún lugar en el medio de la barra recién aparecida pero en el precio de apertura no se cruzan. En la siguiente barra nueva, esa intersección se pierde por completo porque tomamos el precio de cierre de la barra anterior (y se cruzaron en algún lugar entre el precio de apertura y el de cierre). Las señales vendrán sólo en ese caso raro que fue descrito originalmente por mí cuando la MA cruza precisamente en el precio de cierre de la barra. Significa que si la barra actual está abierta, ya hay una limitación de que МА se aplique a los precios abiertos.

He tratado el ejemplo que di introduciendo una desigualdad no estricta. Intente probar la barra de mi post anterior (donde hay dos cruces de MA en una barra) y vea si su robot detecta esos cruces? Si sólo funciona cuando aparece una barra, es imposible. Sólo si funciona por garrapatas. Y ahí ya he descrito los escollos

Busque los cruces en cada tic. ¿Cuál es el problema?
 
Andrey Dik:

Nunca es necesario normalizar nada cuando se comparan dos números reales.

Si los números son realmente iguales, se almacenan en la memoria de la misma manera. De hecho, es precisamente esta propiedad la que hace posible la existencia de las máquinas de computación.

Por lo tanto, las comparaciones de la forma if(a<b) o if(a==b) son correctas en cualquier caso y no se requiere ninguna normalización.

Si la mente inquisitiva de un investigador encuentra una contradicción a esta regla, significa que o bien su máquina está fuera de servicio, o bien su mente. Uno de los dos.

La ayuda y la documentación ciertamente deben ser leídas por lo menos algunas veces (también fueron escritas por la humanidad como nosotros), pero uno debe tener sus propias consideraciones razonables.

Si no hubiera necesidad de normalizar cuando se comparan números de tipo doble utilizando uno de los métodos propuestos en la Documentación, no surgirían estas cuestiones.

Y no tengo que utilizar la normalización para obtener la precisión necesaria de la activación de cualquier condición en mis códigos. Por no mencionar el hecho de que el uso de la normalización de los valores a diferentes decimales en la comparación, puede ser simplemente en sí mismo conveniente y necesario al establecer las condiciones de comparación, en función de las tareas a resolver.

P./S.: Pero, en general, lo he mencionado en este hilo y antes:

Sobre la posibilidad, con la ayuda de la normalización, de ajustar/ajustar el nivel requerido de exactitud de las comparaciones (y/o los valores de salida) y/o los errores tolerables para algunas tareas y propósitos, lo que a su vez, entre otras cosas, permite que las condiciones del programa funcionen exactamente donde y como se pretendía al prescribir condiciones específicas en el código.

Razón de la queja: