¡Necesito ayuda! No puedo resolver el problema, me encuentro con limitaciones de hardware - página 14
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 muchas secuencias de operaciones similares y cada secuencia está ordenada por tiempo.
¿Cabrá una secuencia en la memoria?
Puede escribir un Asesor Experto. Al principio, el Asesor Experto carga la secuencia # (parámetro en la ventana de propiedades) y negocia en esta secuencia. Optimizar №.
La tarea no está del todo clara, mientras que se pueden implementar muchas cosas diferentes.
¿Cabrá una secuencia en la memoria?
Puede escribir un Asesor Experto. El Asesor Experto carga el número de secuencia al inicio (parámetro en la ventana de propiedades) y negocia en esta secuencia. Optimizar №.
La tarea no está del todo clara, aunque se pueden fanatizar muchas cosas diferentes.
Si tenemos 20Gb (21 474 836 480 bytes), con 1 millón de secuencias, obtenemos unos 21 475 bytes de media por secuencia (~21Kb). Creo que debería caber en la memoria, incluso en el teléfono ))
О. Por cierto, ¿qué pasa con la computación distribuida? Deberíamos pensar también en esa dirección...
Perdón de nuevo por la pausa, he estado experimentando con la unidad RAM (sin mucho éxito hasta ahora). Respondiendo a todos en orden.
Pero las secuencias son independientes entre sí, ¿no? Entonces, ¿por qué no puedo hacer un bucle con las fechas de una secuencia cargada de una sola vez? Aquí, por cierto, sólo podría ser una oportunidad para ir a algún algoritmo de recurrencia eficiente, pero eso es la suerte. El tamaño de un millón sobre un millón se mantendrá, y el archivo se leerá una vez.
Por supuesto, un problema en el que el número de pasos sigue siendo el mismo en la siguiente iteración (es decir, el área de búsqueda no se reduce a medida que avanza el cálculo) no parece muy robusto. Pero, por supuesto, esto es subjetivo.
Independiente. ¿Y cómo podemos recorrer todas las secuencias a la vez sin cargarlas en la memoria?
El número de pasos se puede reducir, si se averigua cómo leer las secuencias desde el lugar correcto (las últimas X operaciones desde la fecha actual analizada).
¿Toda la base cabe en líneas de 10 años o no? todos los archivos acumulados
Un archivo por cada millón de secuencias (escribo cada una en 9 líneas por comodidad).
Bueno, o un millón de archivos, no importa.
¿He entendido bien lo siguiente?
1) Un archivo de 20 gb consta de aproximadamente un millón de secuencias ordenadas por tiempo
2) El tamaño de cada secuencia puede variar y depende del número de operaciones que contenga la secuencia
3) El tamaño medio de una secuencia es de 20/10^6 = 20 Mb, así que ¿qué podemos garantizar para descargar completamente una secuencia?
4) El coeficiente K depende sólo de los oficios dentro de la secuencia dada
5) Para cada secuencia, debemos encontrar K (un total de 10^6 piezas) y seleccionar las 10 mejores
Hasta que tuve esos volúmenes, simplemente descargué todo en la memoria y lo ejecuté en un bucle, contando todo lo que necesitaba.
Se debe seleccionar la mejor secuencia en cada punto de la historia (la mejor - secuencia con el mejor Criterio en el momento actual, el Criterio se calcula utilizando la última transacción cerrada.
A si creamos otro archivo con valores de distancias entre secuencias.
No entendí esto ni lo siguiente.
Por cierto, sí, puedes cargar lotes de secuencias a la vez.
No se guardará, se necesitan todos.
No lo entiendo en alguna parte.
Aquí está el criterio - todos - en el intervalo de Fecha1 a Fecha2.
Es decir, dice lo siguiente.
¿Por qué no dividir el archivo en muchos intervalos desde la Fecha1 hasta la Fecha2? Habrá secuencias trabajadas que se pueden cerrar, ¿no?
El intervalo "Fecha1 - Fecha2" cubre actualmente todas las transacciones de todas las secuencias.
Y la idea de dividirla en varias más pequeñas es bastante sensata. Cierto, entonces habría que leer la información del disco cada vez que se modificaran los parámetros... Pero eso es algo.
Al parecer, uno de los resultados de un pase de fecha única es una nueva fecha.
Sí, pero creo que se puede encontrar un punto en el que no haya tratos con ninguna de las secuencias y hacer una pausa.
Luego habrá una transición al siguiente intervalo. Lo intentaré.
si el problema es este:
dada una fila 1 2 3 4 5 6 7 8 9
La anchura está dada, por ejemplo 4, hay que moverse con esta anchura a lo largo de toda la fila para encontrar algún valor dentro de la anchura (por ejemplo el mínimo):
primero tienes que encontrar en 1 2 3 4 luego 2 3 4 5 luego 3 4 5 6 luego 4 5 6 7 luego .... etc.
Si X (número de operaciones) fuera fijo (4 en su ejemplo) y no hubiera otros parámetros, sí. Y así - no.
Me gustaría reflexionar sobre esta tarea
Las condiciones están indicadas arriba, bienvenido a unirse a nuestras filas ;)
Dado que el problema es más bien académico (parece una pregunta para contratar a un programador) y que mucha gente ha mostrado interés en él, ¿por qué no formularlo más estrictamente en términos de formato de descripción de datos de entrada, y todo el mundo podría generar 20 gigas de datos de prueba y presentar su solución práctica?
No hay problema.
Generar secuencias de operaciones aleatorias (en orden cronológico, incluso para 1 año) con todos sus atributos: fecha y hora de apertura, precio de apertura, SL, TP, fecha y hora de cierre, precio de cierre. Numera las secuencias del 1 al millón.
La tarea consiste en crear una nueva serie de operaciones consecutivas a partir de todas las operaciones de todas las secuencias (que no se solapen en el tiempo), y seleccionadas por un determinado criterio.
Dejemos que el criterio sea el beneficio medio de las últimas 20 operaciones de la secuencia.
Ejemplo de resultado:
¿entonces, estamos hablando de un probador/optimizador casero?
Sí, algo así.
nah, hay algo diferente allí.
Supongo que algún corredor/proveedor tiene la base de datos de ofertas. :)
Si sólo =)
Repetiré la tarea en términos más sencillos.
No, no lo es. He dado un ejemplo concreto, se puede considerar lo más cercano al problema real.
Típico de la base de datos. Pero no hay manera de hacerlo sin la agregación de datos. Puede escribir en una tabla separada los atributos únicos de una secuencia (fechas c), el valor medio de la ganancia K y la varianza D, y luego buscar las 10 primeras secuencias que se acerquen a los criterios que necesita. Con índices en estos campos, la búsqueda no tardará tanto (incluso en un millón de registros). Entonces, cuando consigas las 10 secuencias adecuadas, podrás hurgar en los datos brutos, pero ya no serán un millón de búsquedas, ya que tenemos un límite de fechas.
Si el Criterio fuera estático...
¿Y si sus parámetros cambian?
Sigue siendo un misterio: ¿qué debemos buscar? ¿Cuál debe ser el resultado de todas las operaciones? Si hablamos de tomar una decisión en términos de apertura/cierre de una orden, cualquier procesamiento de tal volumen tomará una cantidad de tiempo bastante grande.
Sí, entonces habrá un intercambio. Pero el recálculo sólo será necesario para los datos más recientes, no necesitamos recalcular todo el historial.
Hay otro punto. Ya que estamos hablando de ofertas, ¿quizás tenga sentido separar las ofertas de cada símbolo? Y escribir robots comerciales similares diseñados para EURUSD, USDJPY, etc.
Es un instrumento...
Me parece que de esa manera sólo se puede identificar la estrategia que se utilizó para operar (o el conjunto de parámetros del robot) de una determinada secuencia y cambiar a ella en una determinada situación de mercado.
Exactamente.
¿Cabrá una secuencia en la memoria?
Puede escribir un Asesor Experto. Al principio, el Asesor Experto carga el número de secuencia (parámetro en la ventana de propiedades) y negocia en esta secuencia. Optimizar el número.
Lo hará.
Pero no necesitamos un resultado único (final), sino en cada momento.
Básicamente, podríamos utilizar la nube dando como parámetro el número de secuencia y la fecha, hasta la que hay que leer. Pero apenas es más rápido que el recuento de un archivo)
О. Por cierto, ¿qué pasa con la informática distribuida? Deberíamos pensar también en esta dirección...
¿Qué calculamos en paralelo? ¿Valor del criterio para diferentes secuencias?
Pero para ello tenemos que cargarlos en la memoria. Y no importa si se carga desde un proceso (Expert Advisor, terminal) o desde varios procesos. Tal vez, podamos obtener 8 (o 12, 16, 20) en lugar de 4 Gb. Pero hay que "pegar" el resultado después.
¿Qué debemos contar como paralelo? ¿Qué significa el criterio de las diferentes secuencias?
La idea es dividir todas las historias en, digamos, 100 grupos y para cada grupo calcular el conjunto óptimo por separado.
Entonces, para cada grupo, dejaríamos sólo las historias que están en el conjunto óptimo del grupo y pasaríamos al siguiente paso con un número menor de historias. Entonces, teóricamente, se paraliza 100 veces.
Y de memoria todo está bien, el tamaño del grupo se puede ajustar
La idea es dividir todas las historias en, digamos, 100 grupos y para cada grupo calcular el conjunto óptimo por separado.
A continuación, para cada grupo, deje sólo las historias en el conjunto óptimo del grupo y proceda al siguiente paso, con menos historias. Entonces, teóricamente, se paraliza 100 veces.
Y de memoria todo está bien, el tamaño del grupo se puede ajustar
Si cargas 100 de 100 piezas en paralelo, no hay suficiente memoria =)
Y si se carga secuencialmente (memorizando cada vez una de las mejores variantes), ¿dónde está el paralelismo? Y el archivo seguirá siendo leído cada vez que vayas a la máquina.
Creo que es posible inventar un mecanismo inteligente de carga parcial, pero hay que inventarlo.
Por ejemplo, en la primera lectura, busque para cada pase la última operación cerrada antes de la fecha de inicio, retroceda y lea X operaciones anteriores, recuerde el punto del archivo donde termina esa operación.
Después de eso, encontrar el primer acuerdo en los resultados, y luego trabajar sólo con los datos frescos: leer el archivo desde el punto deseado a la nueva fecha real, y cada vez que las ofertas de cambio en la matriz (vamos a tener una matriz de tamaño fijo - X elementos).
Esto resolverá el problema con la lectura múltiple (simplemente no es necesaria), y con la memoria (sólo si podemos acomodar X millones de transacciones).
Me moveré en esta dirección.
El cambio a archivos binarios, por cierto, no supuso casi ninguna ganancia de tamaño.
El formato de texto que optimicé era muy compacto: la fecha se memorizaba de una sola vez (apertura de la primera operación), y todas las demás (tanto la de apertura como la de cierre) se memorizaban como un desplazamiento de la fecha anterior; SL, TP y PriceClose se guardaban también como un desplazamiento del precio de apertura.
Cuando pasé al formato binario no tenía sentido esta optimización - el desplazamiento en segundos (uint) ocupa tanto espacio, como la fecha completa (rechacé long-a, 2030 años es suficiente para mí), pero ushort no es suficiente (sólo 18 horas de desplazamiento máximo). Lo mismo con los precios - podría mover el offset a ushort, pero entonces tendría que añadir comprobaciones por desbordamiento (si, por ejemplo, SL = 0), y la ganancia sería de sólo 6 bytes en los 3 precios. Decidí no hacerlo.
Pero he eliminado un poco de información innecesaria, así que tengo un 20%. Tamaño proyectado del archivo original (que era de 20Gb) - 7-8Gb, un par de horas convertirá.
Bueno, también gané el tiempo de la CPU, que se utilizó para convertir las líneas.