Estrategias de negociación basadas en filtros digitales - página 33

 
SIMBA:
¿Te importaría compartir tus resultados?...Y la forma correcta de poner los datos ,coma,etc cuestión...será una emoción para nosotros poder hacer y compartir también

seguro...

Simplemente copié mi configuración de la coma de la fecha exactamente como lo hizo ND....

Luego cargué los datos de robertinno....y esto es lo que obtuve ( ver adjunto)...

Supongo que usó datos diferentes....y publicó un ejemplo de "cómo" hacer el roc en excel....mi espectro no se parece en nada al suyo....no importa cuántos registros pongas ahí....

cl

Archivos adjuntos:
 

ND,

¡¡¡¡ESO FUNCIONÓ!!!! ¡¡¡Gracias hermano!!!

Haz lo que dice Newdigital y prueba de nuevo. Mirando tu foto tienes un gran problema con tus datos importados.

Mira por ti mismo, hay una incoherencia total con tus velas.

Yo Linuxser,

Gracias por tus consejos. La razón por la que las velas se ven así no es porque algo esté mal con los datos importados sino porque en realidad no son velas OHLC. Son datos ROC (si no me equivoco). Diferente método de SA traído a nosotros por robertinno que supuestamente da una salida más precisa, ya que se basa en la serie de tiempo no estacionaria que es los mercados financieros frente a la habitual análisis estacionario poco realista (Alguien me corrija si me equivoco). De ahí surgió el problema. Era un tipo diferente de datos y de un ordenador (robertinno's) con un formato de fecha diferente, por lo que aquellos con un formato de fecha por defecto diferente se encontraban con problemas para cargar y pensábamos que era el hecho de que era un tipo diferente de datos. ¡Ufff!

Me desvío de la cuestión........

Lo hemos superado gracias a la lluvia de ideas y al trabajo en equipo de todos.

bien dicho... :-)

 
newdigital:
Acabo de explicar mi experiencia.

Cuando estamos usando alguna herramienta para importar los datos a un software que no es Metatrader (al software asctrend por la herramienta ForexClub de forma gratuita en lugar de usar esignal; y así sucesivamente) por lo que podemos tener este problema: la configuración de Windows de la fecha y los números. Y depende de donde se creó este software, y depende de qué Windows tienes.

Por ejemplo, mi Windows está en idioma ruso. Esto significa que 1,000 es uno en este Windows (y en el idioma ruso). Y 1.000 es mil si tienes un Windows en inglés. Y los mismos casos con deviders. Y es diferente para Europa y Asia también.

Por lo tanto, si usted está convirtiendo los datos de divisas de un software a otro utilizando alguna herramienta gratuita (hay un montón de herramientas gratuitas) por lo que esta herramienta lo hará de acuerdo a su configuración de Windows en la mayor parte del tiempo.

Sólo tienes que ir al Panel de Control, Idiomas y Normas y cambiar el formato y lo entenderás.

Lo más importante es el devider: puede ser coma o punto y coma.

Por ejemplo:

1.9864, 25.01.2006 (si es coma)

o

1.9864; 25.01.2006 (si es punto y coma).

Cuando se importan los datos para que su Windows pueda entender la coma como un desviador entre algunos datos y puede obtener un error.

Por lo tanto, compruebe en su configuración de Windows y cambiar si es necesario (pero no se relaciona con Windows americano como se estableció en la forma correcta ya). Pero como sé que el creador de esta DFG es ruso, puede ser que haya programado la coma en lugar del punto y coma y por eso no tengo ningún error (no me dio error y mi devider en la configuración de Windows es la coma por defecto).

ND,

¡¡¡¡ESO FUNCIONÓ!!!! ¡¡¡Gracias hermano!!!

Linuxser:
Haz lo que dice Newdigital y prueba de nuevo. Viendo tu foto tienes un gran problema con tus datos importados.

Mira por ti mismo, hay una incoherencia total con tus velas.

Yo Linuxser,

Gracias por tu consejo. La razón por la que las velas se ven así no es porque algo esté mal con los datos importados, sino porque en realidad no son velas OHLC. Son datos ROC (si no me equivoco). Diferente método de SA traído a nosotros por robertinno que supuestamente da una salida más precisa, ya que se basa en la serie de tiempo no estacionaria que es los mercados financieros frente a la habitual análisis estacionario poco realista (Alguien me corrija si me equivoco). De ahí surgió el problema. Era un tipo de datos diferente y de un ordenador (robertinno's) con un formato de fecha diferente, por lo que aquellos con un formato de fecha diferente por defecto se encontraban con problemas para cargar y pensábamos que era el hecho de que era un tipo de datos diferente. ¡Ufff!

Me desvío de la cuestión........

Lo hemos superado gracias a la lluvia de ideas y al trabajo en equipo de todos.

 

¿Ajuste de curvas frente a resintonización?

Hola a todos,

Fascinante hilo. Gracias a todos los que lo mantienen en movimiento. Tengo una pregunta para vosotros, gurús, si no os importa.

Pregunta: ¿Qué pasa con el ajuste de curvas y la necesidad de reajustarlas? Me parece claro que este tipo de análisis es extremadamente ajustado a la curva, intencionadamente, como parte integrante del método. Me recuerda a algo de lo que he leído sobre las técnicas de IA - redes neuronales, etc. También he leído que los daytraders que utilizan con éxito técnicas neuronales tienen que reoptimizar o reajustar regularmente sus indicadores para que éstos sigan siendo precisos y relevantes para el mercado actual, algunos incluso cada día.

¿Qué ocurre con estos métodos de DF? ¿Es necesario reajustar (o reoptimizar) los indicadores? ¿Con qué frecuencia? Además, ¿qué diferencia hay entre utilizar el "periodo de aprendizaje" más corto, como 200-300 barras, frente a todas las barras disponibles? Si el FATL, el SATL, etc. se crean utilizando 200-300 barras, ¿con qué frecuencia aconsejaría reajustar los filtros para seguir generando curvas que sean realmente descriptivas y no empiecen a desprenderse?

Yo mismo empezaré a experimentar con algunos de estos métodos en breve, una vez que me ponga al día con los conceptos. Me imagino haciendo un backtest manual de algunas ideas básicas. Sin embargo, no creo que sea genuino hacer un backtest con indicadores que han sido altamente optimizados para los datos (conocidos) del pasado y luego esperar que el futuro (desconocido) se mantenga con ese resultado optimizado. Estoy pensando que lo mejor sería ajustar los filtros a una ventana de 200-300 barras, luego hacer una prueba contra las siguientes, digamos 100 barras, luego adelantar la ventana de ajuste de 200-300 barras 100 barras, luego hacer una prueba contra las siguientes 100 barras, etc, etc, para crear un backtest completo contra condiciones bastante realistas.

¿Algún consejo o comentario?

Lo mejor,

Scott

 
turboscottomatic:
Hola a todos,

Un hilo fascinante. Gracias a todos los que lo mantienen en movimiento. Tengo una pregunta para vosotros, gurús, si no os importa.

Pregunta: ¿Qué pasa con el ajuste de curvas y la necesidad de reajustarlas? Me parece claro que este tipo de análisis es extremadamente ajustado a la curva, intencionadamente, como parte integrante del método. Me recuerda a algo de lo que he leído sobre las técnicas de IA - redes neuronales, etc. También he leído que los daytraders que utilizan con éxito técnicas neuronales tienen que reoptimizar o reajustar regularmente sus indicadores para que éstos sigan siendo precisos y relevantes para el mercado actual, algunos incluso cada día.

¿Qué ocurre con estos métodos de DF? ¿Es necesario reajustar (o reoptimizar) los indicadores? ¿Con qué frecuencia? Además, ¿qué diferencia hay entre utilizar el "periodo de aprendizaje" más corto, como 200-300 barras, frente a todas las barras disponibles? Si el FATL, el SATL, etc. se crean utilizando 200-300 barras, ¿con qué frecuencia aconsejaría reajustar los filtros para seguir generando curvas que sean realmente descriptivas y no empiecen a desprenderse?

Yo mismo empezaré a experimentar con algunos de estos métodos en breve, una vez que me ponga al día con los conceptos. Me imagino haciendo un backtest manual de algunas ideas básicas. Sin embargo, no creo que sea genuino hacer un backtest con indicadores que han sido altamente optimizados para los datos (conocidos) del pasado y luego esperar que el futuro (desconocido) se mantenga con ese resultado optimizado. Estoy pensando que lo mejor sería ajustar los filtros a una ventana de 200-300 barras, luego hacer una prueba contra las siguientes, digamos 100 barras, luego adelantar la ventana de ajuste de 200-300 barras 100 barras, luego hacer una prueba contra las siguientes 100 barras, etc, etc, para crear un backtest completo contra condiciones bastante realistas.

¿Algún consejo o comentario?

Lo mejor,

Scott

Scott,

Sólo tengo un minuto rápido, pero quería darte mi comentario. En términos de "re-tuning", no hemos entrado mucho en eso pero eso no quiere decir que no haya surgido. Mi opinión sería (y este ha sido el consejo de SIMBA en el pasado) que cuando se utiliza SATL, FATL (que conduce a STLM y FTLM), tratamos de utilizar la menor cantidad de barras posible. Yo pensaría entonces que tal vez cada semana, se podría reoptimizar con las últimas 200 barras más o menos. Reoptimizar el sábado, por ejemplo, y utilizar los coeficientes de la semana siguiente. Los "ciclos" que hemos estado creando no los hemos tocado realmente. Ya que estamos usando el historial completo, asumiría que no tendrías que reoptimizar tan a menudo. Eso no quiere decir que no tengas que hacerlo nunca.

Lo siento, pero tengo que correr. Estoy seguro de que alguien más comentará más sobre esto.

Gracias,

cl

 

gracias

Gracias cl - Aprecio el aporte. Por lo que estoy leyendo aquí en el foro, así como los documentos originales (en el sitio de Robert), parece que cualquiera que utilice estas técnicas está trabajando en la frontera y tendrá que hacer un montón de experimentación y descubrimiento por ensayo y error. Mucho más interesante que trabajar con métodos con historias bien conocidas (y trilladas), como la mayoría de los indicadores clásicos de AT. Estoy deseando meterme un poco en esto. Lamentablemente, me voy a mudar en las próximas 3 semanas y eso tendrá prioridad, pero esa es mi cruz a soportar.....

mejor,

Scott

 

Yo Barnix,

Esto es algo profundo. ¡Debes estar tratando de darme un dolor de cabeza antes de ir a patinar. lol! Gracias por compartir, hermano. No seas un extraño, ya que podría hacer sólo un par de preguntas

Por lo que he entendido hasta ahora, este método funciona muy bien con datos no estacionarios.

FEI (Para información de todos)

Debes colocar el archivo SSA en la carpeta include y/o library y el #_FullSSA_normalize en la carpeta del indicador.

 

Esta noche he estado trasteando con este indicador, ejecutándolo a través de VHands. Es un cerdo en la memoria sin duda. Mi pregunta viene por el cálculo. La línea se repinta continuamente y se recalcula, por lo que en el pasado se ve muy bien. El externo "Lag" controla esto. "10" parece hacer que se recalculen las últimas 10 barras más o menos. Un número de "3" es mucho más irregular, y no repinta tanto el pasado como el 10. No estoy muy seguro de qué aplicaciones en "tiempo real" tendría este indicador. Me recuerda mucho a los indicadores fisher. ¿Tal vez hay un error de codificación que lo hace repintar? Supongo que no, pero pensé en publicar lo que noté...

Lo mejor,

cl

 

En el SSA:

Yo, así como varios otros miembros, han experimentado "recalcular" de este indicador. Puede cambiar después de varias barras cerradas. No estoy seguro de si esto es un error o si este indicador está destinado a ser como Zigzag es decir, dinámico. Cualquiera que sea el caso, cualquiera que lo utilice, le animo a tener precaución al hacerlo.

Quizás Barnix sea tan amable de arrojar algo de luz sobre este tema. Podría ser que no lo esté utilizando de la manera prevista. Si es así, pido disculpas por sacar conclusiones precipitadas. Barnix es uno de los pocos miembros altamente cualificados, cuyo trabajo conozco, así que dudo seriamente que nos diera intencionadamente un producto defectuoso. Espero que todavía esté pendiente y vea este mensaje. Espero con impaciencia que se hable más del tema.

Sobre los DF's:

Para los interesados, hay un indicador que fue codificado por el creador del software DFG, Sergey Iljukhin. Incluye .DLL's que llaman a funciones del software DFG, permitiendo la creación de filtros de paso bajo directamente en MT4. El propósito de utilizar el DFG se convierte entonces únicamente en el análisis espectral. Es mucho más fácil afinar y probar con datos en vivo frente al método tradicional de usar DFG para todo el proceso. Visite este enlace para descargar el indicador y los archivos .DLL.

Muy buen indicador en mi opinión. Tengo curiosidad por saber si alguno de los programadores estaría interesado en emprender un proyecto para crear un indicador similar que permita la creación de filtros FTLM y STLM optimizados. Esto fomentaría el progreso de métodos más fáciles de usar para optimizar y crear filtros digitales ajustados a diferentes series temporales.

También, algunos posibles mods el actual indicador DigitalFilter.mq4 para incluir un par de cosas extra como Aduanas de precios y una descripción de los tipos de filtros que se pueden crear y el valor numérico al que corresponden en los parámetros frente a tener que abrir indy en MetaEditor para averiguar o tratar de memorizarlo entre otros cambios que creo (basado en la investigación entre Simba, CLahn, y yo mismo) produciría un conjunto robusto de indicadores.

Con estos, estamos un paso más cerca de auto-optimizado DF's directamente en MT4. Jojo creó recientemente un indicador de análisis espectral para MT4 utilizando el algoritmo de Goertzel. Desafortunadamente, Jojo no se ha publicado en el hilo desde entonces, así que estamos en una pérdida en la forma de aplicar correctamente a nuestra causa. Tal como está ahora, estamos @ un punto de estancamiento. Si y cuando sabemos cómo casar los indicadores MT4 DF w / el indicador Goertzel SA.... .

Esperando cualquier y toda la retroalimentación.

Razón de la queja: