Errores, fallos, preguntas - página 680
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
Vaya, qué gentil eres. Lo siento, olvidé que era tu fin de semana. ¿Y nosotros? Tal vez sería mejor liberar las construcciones los lunes para que no haya esos malentendidos... No tenemos días libres. A nosotros (comerciantes, no programadores) nos importa la calidad de la plataforma. ¿Y qué es lo que te anima?
No se preocupe, lo comprobaremos y lo arreglaremos.
Por ahora, puedes utilizar el modo tiki, como antes - es la única opción fiable para las pruebas. Utilice los otros métodos sólo para una evaluación aproximada de la estrategia (independientemente de lo que piense el autor de la misma).
Es el programador quien debe analizar los datos. La consulta anterior era puramente privada y no tenía nada que ver con nosotros ni con el terminal.
"Yo no soy yo y el caballo no es mío". Clásico.
Se trata, curiosamente, de Thomas, no de Yeroma: no de nuestro análisis, sino de su síntesis de los TFs superiores conservando algunos atributos precisos, concretamente temporales, del objeto llamado bar. Eso es todo. No hay nada más que necesites para ser feliz como programador.
Piensa en la cantidad de rutinas ineficientes que están sucediendo: ustedes, desarrolladores del terminal, se encargaron de la creación del TF senior de M1, pero la buena idea estaba muerta, y después de su síntesis debemos hacer la operación inversa - ¡análisis de datos! ¿Qué es el juego de "archivar-desarchivar"? ¿Qué tiene de divertido? Si ya ha inventado la síntesis, hágala lo más eficiente posible: proporcione sus resultados con más datos informativos. Así que, hagámoslo...
1. es el programador quien debe analizar los datos. La consulta anterior era puramente privada y no tiene nada que ver con nosotros ni con el terminal.
2. sus preguntas sobre las barras que faltan desde su ignorancia de la situación del mercado. Mire los gráficos de acciones o de futuros para ampliar sus horizontes y las preguntas sobre "no debería haber agujeros" desaparecerán al instante.
3. Son palabras generales. Especialmente sobre la estrategia.
Renat, estás muy equivocado en cuanto a la particularidad excepcional de esta consulta. ¿Quieres una votación en el foro sobre esta consulta "excepcionalmente privada"? Disipará al instante tus ilusiones.
2. Lo he visto. ¿Y qué? ¿Muchos bares perdidos? Tampoco me hago ilusiones. Tengo una pregunta. No es nada original y de ninguna manera es "exclusivamente privado". A saber: el modo de acceso (¡y visualización!) a las cotizaciones (incluidas, ¡sí, sí!, las de baja liquidez) automáticamente (!!) soportado por el fabricante del terminal, en el que todos los huecos intra-sesión de las cotizaciones se rellenan con esquivas con los parámetros {Volumen=0, Apertura=Alta=Baja=Cierre=[precio de cierre de la barra anterior]}. ¿Cree que este modo tiene demanda? ¿O soy un gran original? Sé sincero, Renat. Poner la mano derecha en el corazón izquierdo.
3. Vale. Dejemos lo de la estrategia, es sólo mi especulación.
Invito a un poco de margen de maniobra.
En algún lugar de las profundidades de la historia hay una barra D1- teóricamente son 60*24=1440 barras de minutos. Usando CopyTime(), mordemos en sus bordes un segmento en la expresión M1-historia y buscamos los extremos altos y bajos con ArrayMinimum() y ArrayMaximum() de la forma más precisa y más voluminosa. Encontrar el tiempo exacto de un extremo de un compás es un abrir y cerrar de ojos, pero ¿y si necesitamos calcular cientos? Pero es necesario. Al fin y al cabo, nadie tiene derecho a decir "¡oye, para, no quiero eso!" e incluso a reprocharnos un planteamiento erróneo dentro de los límites de las herramientas de las que disponemos. Y cuanto más lejos se encuentre la barra especificada en la historia, más lentamente se enfrentaráCopyTime() a ella. ¡Luego está esta conversión demoníaca entre la hora de la barra y su índice! No, no estoy a favor de mostrar las barras perdidas, más bien estoy de acuerdo con la ideología de MetaQuotes, pero no puedo dejar de señalar que esa conversión también consume muchos recursos, es confusa y abulta el código. Si siempre hubiera exactamente 60 barras de minutos en una hora terminal (24 barras de horas en un día, etc.), podría seleccionar inmediatamente la barra de índice requerida mediante simples operaciones aritméticas de multiplicación, suma y resta... seguro que no se perdería... y no hay conversión de doble cara.
Así que a la pregunta de peinar 1440 bares en busca de un extremo... Te diré que es una actividad que no tiene sentido. Y hablando de ingenio... - ¿hay alguna alternativa?
Sólo se me ocurrió una cosa (y hace como un año ya, así que ni siquiera era una alternativa, sino una solución básica, que pregunté aquí, pero nadie me contestó): ¿es adecuado el método de interpolación para sacar el valor exacto del tiempo? A saber: ¿manipulaciones secuenciales de sustitución con plazos cada vez más bajos hasta M1? Es decir, tenemos que hacerCopyTime()'s con subperiodos de interés, que no es una muestra de rendimiento, y luego sustituirlos en una matriz. En idea, se hace decenas de veces más rápido que la lectura simple completa de 1440 barras: en D1 tenemos 6xH4, en H4 - 4xH1, en H1 - 2xM30, en M30 - 2XM15, en M15 - 15XM1. Como máximo en cada periodo obtenemos el número total de pases:
en D1: 6 barras H4, se encontró una +
en H4: 4 barras H1, encontradas una +
en H1: 2 barras M30, encontradas una +
M30: 2 barras de M15, se encontró una +
en M15: 15 barras M1, se encontró una = ¡¡¡29 iteraciones como máximo frente a 1440!!!
Parece: la ventaja es evidente. Y ahora piensa, ¿no se ahogarían el cristal y la RAM con todas esas matrioskas BDSM-CopyTime() en un bucle durante varios periodos...? Personalmente, me estremece pensar en ello... Luego están todas esas comprobaciones de la disponibilidad simultánea de datos de diferentes plazos, que puede que nunca se produzcan, la sincronización, etc... Y todo el coqueteo con la selección de múltiplos de TFs inferiores para los superiores no estándar - ya no hablo en voz baja. Parece que mi codecraft ha echado raíces en la dirección equivocada...
En fin, no sé tú, pero a mí ya no me entusiasma perder el tiempo intercambiando un montón de código.
Por supuesto, sé que al sheriff no le importan los problemas de los indios. Entonces, ¿para quién es la terminal?
Les invito a que piensen un poco.
............
..........Por supuesto, lo entiendo: al sheriff no le importan los problemas de los indios. Entonces, ¿para quién es la terminal?
Es todo dolorosamente conocido. Y molesto año tras año. x100intraday, hagamos una votación, a ver cuántos más se hartan.
Es todo dolorosamente conocido, y se vuelve molesto año tras año. x100intraday, adelante con la encuesta, a ver cuánta gente más se desahoga.
Si en principio es importante que lo haga, instrúyeme (aquí mismo o puedes hacerlo en privado), pero si no es así, mejor hazlo tú, que yo estoy a favor.
P.D.: Y no creo en las urnas. Mira a mí mismo: como un miembro activo de varios foros y blogs, sin embargo pasa por alto algo que no me concierne o que simplemente no tienen tiempo para leer, incluso si es la mía. Y no todo el mundo puede votar, independientemente de la relevancia del problema para ellos. Y si el problema es totalmente ajeno, ¿por qué todo este trabajo extra? Tal vez no sea digno de un razonamiento así, pero no soy el único con el problema. El voto es cuasi-objetivo. Siempre hay que confiar en la objetividad, la discreción y la prudencia del colectivo profesional, que pretende saber mejor que nosotros, los usuarios, lo que necesitamos y lo que nos perjudica. ...Por no hablar de percances como el de lanzar votos entusiastas no por el principio de "¡Putin es el mejor político de la actualidad!", sino "¡es el más guapo!"
Es una política utópica hacer que un producto sea conveniente (= de algún modo atractivo?) para una mayoría estadística de usuarios y suponer que esta mayoría consumirá automáticamente el producto en masa. La manada tiene una estructura jerárquica y siempre sigue a los líderes de los subgrupos. Hasta que esto se convierta en un axioma de su estrategia de usabilidad, seguirá cometiendo graves errores de cálculo al evaluar el atractivo potencial de sus servicios.
En el contexto de lo anterior, hay tremendos recursos para aumentar el atractivo del terminal para las masas - por ejemplo, para implementar finalmente el historial de minutos "sin agujeros", la posibilidad de probar en otras cotizaciones, las órdenes CCA, y muchos otros servicios "estadísticamente no reclamados" que son de verdadero interés para los líderes intelectuales en sus propios foros (no sólo escritos de la nada).
En MT4, funcionaba así: #importar "TrendLine\\MemoryDLL.dll".
Lo curioso es que he probado un montón de opciones, incluida esta.
El resultado es el mismo - el archivo requerido no se encuentra (necesito llegar a *.ex5).
Antes funcionaba así
#import "\DirName\FileName.ex5"Ahora no funciona, ni tampoco otras variantes.Os da miedo gastar tiempo en calcular características adicionales de la barra para casos muy raros (cercanos al 0%), pero exigís alegremente que seamos nosotros los que preparemos un montón de datos en casos del 100%, ralentizando y consumiendo memoria muchas veces más.
Algunos dan metódicamente tan hermosos consejos para matarse contra la pared, que es hora de hablar de las plagas.
Los estrategas de este tipo son inmediatamente visibles.
No parece que pienses mucho en el futuro.
¿Tiene miedo de dedicar tiempo a calcular las características adicionales de la barra para casos muy raros(cercanos al cero %)?
Tengo la sensación de que habrá una votación :)