Un robot sin indicadores - página 6
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
Hay indicadores que determinan...no una tendencia o un plano...de todas formas no existen en forma pura. Determinan la ventaja de las fuerzas en la compra o venta en general en cualquier dirección. No se puede determinar con los ojos. Porque no es la dirección del precio, sino el grado de entropía (aleatoriedad) en el precio. De hecho estos indicadores son algo así como inventos por eso no son populares, por supuesto tengo un par de ellos desarrollados por encargo en comunicación personal. No podré determinar la tendencia a priori. Pero un piso es muy posible. Ya que el plano + la aleatoriedad existe alrededor del 98% de todo el tiempo de mercado.
Un piso no existe el 98% del tiempo, existe exactamente mientras haya una tendencia. El mercado cambia de tendencia a plano, la ley de distribución fluctúa pero nunca se convierte en una distribución normal. Si el piso fuera el 98% de las veces, sería demasiado fácil ganar dinero con él.
Un piso no existe el 98% del tiempo, existe mientras haya una tendencia. La naturaleza del mercado cambia de tendencia a plana, la ley de distribución fluctúa en torno a la normalidad, pero nunca llega a serlo. Si un piso fuera el 98% de las veces, sería demasiado fácil ganar dinero con él.
1. Por favor, cuida tus emociones.
Sabes, me recuerdas a la categoría de personas que piden pruebas, y después de presentarlas dicen lo siguiente "tu prueba, no....".
Que puedo decir a esto "dice solo de un código indicador no óptimo", tienes razón, a tu entender el código óptimo es... No quiero ni adivinar qué es.
Tal vez te hayas perdido algo, pero inicialmente escribí que poner toda la lógica en el código del Asesor Experto no es una buena solución siempre que se abra y cargue N número de instrumentos en el terminal, porque en mi opinión la tarea del Asesor Experto es gestionar las órdenes en el tiempo.
Lo que he mostrado, y comentas "sobre el código no óptimo de los indicadores" (no digo lo contrario), siempre que estén abiertos un par de instrumentos y un par de bots e indicadores, no veo esos desfases, es decir, si seguimos tu lógica, sobre el código "óptimo", nunca aparecerán mensajes como"el indicador es demasiado lento", si están abiertos 10 o más instrumentos, ¿crees seriamente en ello?
Por experiencia personal llegué a la conclusión de que todos los cálculos "pesados" deben hacerse en un programa separado para no observar retrasos similares, y MQL se encargará de la tarea de servir órdenes basadas en los comandos recibidos del programa que no afecta directamente al motor MQL y su productividad. De hecho, lo estoy haciendo ahora.
En realidad, no tengo nada que probar, ya que no se ha encontrado, así que:
1. Eres un dios en el mundo de la programación :);
2. Es que aún no has escrito nada serio.
3. Sólo te calificas a ti mismo con tus hacks.
Sabes, me recuerdas a la categoría de personas que piden pruebas, y después de presentarlas dicen lo siguiente "tu prueba, no la prueba....".
Qué puedo decir a esto "sólo habla de un código indicador no óptimo", tienes razón, a tu entender el código óptimo es... No quiero ni adivinar qué es.
Tal vez te hayas perdido algo, pero inicialmente escribí que poner toda la lógica en el código del Asesor Experto no es una buena solución siempre que se abra y cargue N número de instrumentos en el terminal, porque en mi opinión la tarea del Asesor Experto es gestionar las órdenes en el tiempo.
Lo que he mostrado, y comentas "sobre el código no óptimo de los indicadores" (no digo lo contrario), siempre que estén abiertos un par de instrumentos y un par de bots e indicadores, no veo esos desfases, es decir, si seguimos tu lógica, sobre el código "óptimo", nunca aparecerán mensajes como"el indicador es demasiado lento", si están abiertos 10 o más instrumentos, ¿crees seriamente en ello?
Por experiencia personal llegué a la conclusión de que todos los cálculos "pesados" deben hacerse en un programa separado para no observar retrasos similares, y MQL se encargará de la tarea de servir órdenes basadas en los comandos recibidos del programa que no afecta directamente al motor MQL y su productividad. De hecho, lo estoy haciendo ahora.
En realidad, no tengo nada que probar, ya que no se ha encontrado, así que:
1. Eres un dios en el mundo de la programación :);
2. Es que aún no has escrito nada serio.
3. Sólo os estáis calificando a vosotros mismos con vuestros hacks.
Un piso no existe el 98% del tiempo, existe mientras haya una tendencia. La naturaleza del mercado cambia de tendencia a plana, la ley de distribución fluctúa en torno a la normalidad, pero nunca llega a serlo. Si un piso fuera el 98% del tiempo, sería demasiado fácil ganar dinero con él.
Por si no te has dado cuenta... "plano+aleatorio". Eso es lo que hace el 98% del tiempo.
Y las tendencias...son sólo valores atípicos...anomalías del mercado...ocurren raramente como el Brexit en el Reino Unido. Por supuesto, había una verdadera tendencia a la venta.
Estas "tendencias" no pueden detectarse sin una conexión de alta velocidad con la bolsa. También hay que inventar una herramienta matemática. Y ojo, aquí nadie lo dice, pero la tendencia en sí también puede ser aleatoria =) Suena absurdo, pero no por ello deja de ser cierto).
Por si no te has dado cuenta... "plano+aleatorio". Eso es lo que hace el 98% del tiempo.
Y las tendencias...son solo picos...anomalías del mercado...ocurren raramente, como el Brexit en el Reino Unido. Por supuesto, había una verdadera tendencia a la venta.
Estas "tendencias" no pueden detectarse sin una conexión de alta velocidad con la bolsa. También hay que inventar una herramienta matemática. Y ojo, aquí nadie lo dice, pero la tendencia en sí también puede ser aleatoria =) Suena absurdo pero no deja de ser cierto).
Permítanme explicarlo de otra manera. Si la probabilidad de reversión es del 50%, entonces no es una tendencia y no es un piso, pero el precio todavía se moverá en alguna parte. En ese caso, el gráfico tendrá una distribución de probabilidad normal (como proceso aleatorio). Pero en el mercado, la probabilidad de que se produzca un retroceso es mayoritariamente inferior al 50% si se trata de una tendencia, o superior al 50% si se trata de un retroceso. Pero si se toma durante un largo periodo de tiempo, la probabilidad de inversión es de alrededor del 50%. Así que el mercado fluctúa en torno a este valor. Aquí estoy hablando de forex y de los principales 28 pares. Es un poco diferente en el fondo.
Sabes, me recuerdas a la categoría de personas que piden pruebas, y después de presentarlas dicen lo siguiente "tu prueba, no la prueba....".
Qué puedo decir a esto "sólo habla de un código indicador no óptimo", tienes razón, a tu entender el código óptimo es... No quiero ni adivinar qué es.
Tal vez te hayas perdido algo, pero inicialmente escribí que poner toda la lógica en el código del Asesor Experto no es una buena solución siempre que se abra y cargue N número de instrumentos en el terminal, porque en mi opinión la tarea del Asesor Experto es gestionar las órdenes en el tiempo.
Lo que he mostrado, y comentas "sobre el código no óptimo de los indicadores" (no digo lo contrario), siempre que estén abiertos un par de instrumentos y un par de bots e indicadores, no veo esos desfases, es decir, si seguimos tu lógica, sobre el código "óptimo", nunca aparecerán mensajes como"el indicador es demasiado lento", si están abiertos 10 o más instrumentos, ¿crees seriamente en ello?
Por mi experiencia personal llegué a la conclusión de que todos los cálculos "pesados" deben realizarse en un programa separado para no observar retrasos similares, y MQL debe encargarse de las órdenes de servicio basadas en los comandos recibidos del programa que no afecta directamente al motor MQL y su productividad. De hecho, lo estoy haciendo ahora.
En realidad, no tengo nada que probar, ya que no se ha encontrado, así que:
1. Eres un dios en el mundo de la programación :);
2. Es que aún no has escrito nada serio.
3. Sólo te calificas a ti mismo con tus hacks.
Aprende a escribir el código correctamente. Sólo puedes culparte a ti mismo de tus retrasos. Llevo más de 10 años aquí y sólo he escrito un indicador con un mensaje así. Sin embargo, lo he corregido yo mismo.
Por supuesto, tengo mucha de su experiencia...
Pero por favor, dame el código del indicador que cuelga tu hilo.
Sabes, me recuerdas a la categoría de personas que piden pruebas, y después de presentarlas dicen lo siguiente "tu prueba, no la prueba....".
Que puedo decir a esto "solo habla de un código indicador no óptimo", tienes razón, a tu entender el código óptimo es... No quiero ni adivinar qué es.
Tal vez te hayas perdido algo, pero inicialmente escribí que poner toda la lógica en el código del Asesor Experto no es una buena solución siempre que se abra y cargue N número de instrumentos en el terminal, porque en mi opinión la tarea del Asesor Experto es gestionar las órdenes en el tiempo.
Lo que he mostrado, y comentas "sobre el código no óptimo de los indicadores" (no digo lo contrario), siempre que estén abiertos un par de instrumentos y un par de bots e indicadores, no veo esos desfases, es decir, si seguimos tu lógica, sobre el código "óptimo", nunca aparecerán mensajes como"el indicador es demasiado lento", si están abiertos 10 o más instrumentos, ¿crees seriamente en ello?
Por mi experiencia personal llegué a la conclusión de que todos los cálculos "pesados" deben realizarse en un programa separado para no observar retrasos similares, y a MQL se le deben confiar las órdenes de servicio basadas en los comandos recibidos del programa que no afecta directamente al motor MQL y su productividad. De hecho, lo estoy haciendo ahora.
En realidad, no tengo nada que probar, ya que no se ha encontrado, así que:
1. Eres un dios en el mundo de la programación :);
2. Es que aún no has escrito nada serio.
3. Sólo estás haciendo una calificación para ti mismo con tus hacks.
Respuesta:
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Mi robot sin indicadores
Artyom Trishkin, 2018.09.27 15:42
Creo que es bastante correcto (tolerante), el ejemplo de cálculo de todo el indicador, y una parte optimizada del mismo, la optimización da una ganancia de 1-2 órdenes de magnitud:
Si todas las barras se recalculan en cada tick (probablemente el 99% de kodobase), recibirá un mensaje sobre un indicador lento. Al llamar a icustom se calculan todas las barras.
Aprende a escribir el código correctamente. Sólo puedes culparte a ti mismo de tus frenos. Llevo más de 10 años aquí y sólo he escrito un indicador con un mensaje así. Sin embargo, lo he corregido yo mismo.
Por supuesto, tengo mucha de su experiencia...
Pero por favor, dame el código del indicador que cuelga de tu hilo.
No lo entiendes...
Es triste... Simplemente hay un algoritmo, con el que se está tratando, y hay un análisis de una gran cantidad de datos, y por mucho que optimices tu código, no puedes librarte de él, como ejemplos cito a los mineros, que piensan que hay un problema de código, que se necesitan megacomputadoras????
Así que sólo te advertí en mi post, mientras tú intentabas hacerte el listo. Este es el fin de la discusión, no tiene sentido.