Discusión sobre el artículo "Aplicando OLAP en el trading (parte 1): Fundamentos del análisis corriente de datos multidimensionales"
No como crítica, sino de acuerdo con la lógica del artículo:
Hubiera sido más correcto llamar al artículo"Aplicación de OLAP en el análisis de los resultados de las operaciones", porque el título da la impresión de que analizará la dinámica del mercado. Pero resulta que el experto no es trader.
No obstante, el artículo es interesante desde el punto de vista del análisis de datos finales no relacionados con el mercado.
El título correcto del artículo debería haber sido "Aplicación de OLAP en el análisis de los resultados comerciales".
El título es incorrecto, eso está claro.
En mi opinión, sería mejor llamarlo así: "Trabajar con espacios multidimensionales en el trading utilizando tecnología OLAP". Así que uno lee y piensa: ¿qué es OLAP y por qué está aquí?
En general, por lo que entiendo, el artículo propone una determinada clase de contenedor y la infraestructura correspondiente, que almacena convenientemente vectores (vector en el sentido estadístico: es decir, un conjunto de valores que caracterizan un punto en un espacio multidimensional). En principio, incluso sin este contenedor es posible agrupar los datos según las necesidades. Sin embargo, es mucho más difícil visualizar espacios multidimensionales. Por desgracia, no está escrito en el artículo, pero estoy seguro de que OLAP dispone de herramientas de visualización.
Que el nombre está mal, eso seguro.
En mi opinión, sería mejor llamarlo algo así: "Trabajar con espacios multidimensionales en el comercio utilizando la tecnología OLAP". Y entonces lees y piensas: ¿qué es OLAP y por qué está aquí?
Sería mejor que hubiera más artículos sobre trading.
Y así resulta que los programadores lanzan sus desarrollos desde otras áreas. No sé por qué, no sé a quién.
Creo que estaba en la lengua de muchos, yo solo lo he expresado ))
Sería mejor que hubiera más artículos sobre comercio.
Y así resulta que los programadores vierten sus desarrollos de otras áreas. No está claro por qué, no está claro a quién.
Creo que estaba en boca de mucha gente, yo sólo lo he expresado )).
No sé, prefiero leer sobre OLAP que artículos como "La Martingala como base de una estrategia de trading a largo plazo".
El artículo presenta clases universales, que pueden utilizarse para analizar cualquier dato numérico relacionado con el trading (se menciona), de ahí el nombre de "trading".
Considero esta herramienta muy útil para el trading, de la categoría de imprescindible. Si alguien quiere algo más "trader" -no sé con qué criterio- que deje peticiones concretas en el hilo correspondiente del foro, donde hay una tabla de "deseos".
He aquí una cita del principio del artículo:
//----------------------------
"Para un informe de trading, puede ser interesante obtener un desglose de los beneficios por símbolo, día de la semana, compras y ventas. O, por ejemplo, para comparar el rendimiento de varios robots de trading (es decir, por separado para cada número mágico).
Fin de la cita.
//----------------------------
Se trata de un problema práctico, cuya solución se enseña más adelante en el texto. Fin de la cita:
//---------------------------
"Para leer registros de alguna fuente abstracta (que en el futuro puede ser el historial de una cuenta de trading, un fichero CSV, un informe HTML o datos de Internet obtenidos mediante WebRequest), se necesita otra clase: un DataAdapter. "
Fin de la cita.
//---------------------------
Así pues, se supone que los datos se toman de diferentes fuentes (¿se conoce su formato de antemano?). Pero supongamos que el formato del registro de datos analizado es el mismo para todos los informes. En este caso, sugeriría una solución alternativa que no requiere una compleja organización OOP y OLAP.
Un informe describe el historial de una cuenta de operaciones. Todo informe comercial tiene un centro semántico: una OPERACIÓN. Las propiedades de este objeto son símbolo, fecha, lote y un número infinito de otras cosas. Cada propiedad, es un parámetro que tiene una historia de valores de profundidad indeterminada. Nuestra tarea es encontrar rápidamente los datos basándonos en criterios de composición libre. Su visualización es secundaria. Y así, cada propiedad es un parámetro con su propia historia de valores. La eficiencia de la recuperación de datos, por supuesto, depende del método de su almacenamiento, pero aquí está la cuestión: Los datos son infinitamente diversos, porque las propiedades del objeto principal del informe - Transacciones - son infinitamente diversas, y el estado de cada propiedad (el valor actual del parámetro) puede ser un filtro para buscar paralelismos en la historia de valores de otros parámetros. En otras palabras, existe una variedad infinita de opciones para la agregación de datos, y los intentos de distribuir y almacenar el historial en complejos preparados y estructurados de antemano, ¿no supondrán una disminución de la eficacia de la extracción y de la velocidad de agregación? Por supuesto que sí.
El único método universal de registro y almacenamiento de datos que puedo ver consiste en crear vectores paralelos (por ejemplo, recursos), cada uno de los cuales contiene un historial de los valores de sus parámetros. Dado que una transacción está vinculada a un momento concreto, tiene un número de serie y, por tanto, cada transacción combina un número cualquiera de propiedades, cuyo historial de valores se registra en un número n de vectores. Esta es la esencia del método que propongo para organizar y almacenar los datos de los informes. No veo nada más universal.
Ahora, sobre la agregación de datos. Por supuesto, hay que utilizar el paralelismo de vectores siempre que sea posible, y cuando la tarea sea más complicada, hay que utilizar los ciclos de búsqueda habituales. No necesitamos sistemas estructurados complejos para esto, y la solución universal es crear la función agregada principal usando diferentes métodos de filtrado de datos. Es decir, - un bloque de trabajo con un conjunto reponible de filtros. Todos.
//---------------------------
OLAP es una buena técnica, sin duda.
Pero, en mi humilde opinión, la principal característica de OLAP es la integración. Con almacenes y otras fuentes de datos. Entonces las posibilidades de análisis se expanden dramáticamente. Y dentro de una aplicación con sus propios conjuntos de datos no es muy cómico.
Espero que en los próximos artículos habrá ejemplos correspondientes.
¡Ah-da ! El artículo es genial, el código es excelente, es raro encontrar algo así aquí
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Artículo publicado Aplicando OLAP en el trading (parte 1): Fundamentos del análisis corriente de datos multidimensionales:
En este artículo, se describen los principios básicos de la construcción del framework para el procesamiento analítico en línea (OLAP en inglés), su implementación en MQL en el ambiente de MetaTrader, usando el procesamiento del historial de trading de la cuenta como ejemplo.
A menudo los traders necesitan analizar importantes volúmenes de datos. Normalmente, se trata de los números: cotizaciones, valores de los indicadores, resultados de los informes comerciales. Debido a una gran cantidad de parámetros y condiciones de las cuales estos números dependen, es mejor usar el principio «divide y domina», es decir, por partes, examinándolos de varios ángulos. En cierto sentido, el volumen entero de la información forma un hipercubo virtual donde cada parámetro define su dimensión de manera perpendicular al resto. Para procesar y analizar estos hipercubos se usa una tecnología bien conocida OLAP (en inglés, Online Analytical Processing).
La palabra «online» en el título no tiene nada que ver con la red Internet, y significa la rapidez (o interactividad) de la obtención de la información. El principio de la acción consiste en el cálculo preliminar de las células del hipercubo, y después de eso, se puede extraer rápidamente y visualizar cualquier sección transversal del cubo. Por ejemplo, se puede comparar eso con el proceso de la optimizacción en MetaTrader: primero, el Simulador de Estrategias calcula las variantes del trading (eso puede requerir bastante tiempo), y luego, obtenemos el informe que resume los valores de los indicadores en relación con los parámetros de entrada. A partir de la versión 1860, MetaTrader 5 permite cambiar dinámicamente los resultados de la optimización optimizados, alternando diferentes criterios de la optimización. Eso nos acerca a la idea de OLAP. Pero para un análisis completo sería bueno tener la posibilidad de seleccionar rápidamente muchas otras secciones del hipercubo.
Hoy, intentaremos aplicar el enfoque de OLAP en MetaTrader e implementar un análisis multidimensional usando herramientas de MQL. Pero antes de empezar, tenemos que decidir qué es lo que vamos a analizar exactamente. Por ejemplo, pueden ser informes comerciales, resultados de la optimización, valores de los indicadores. En principio, nuestra selección en esta etapa no es tan importante ya que el framework diseñado tiene que representar un mecanismo universal orientado a objetos aplicable a cualquier tipo de datos. Sin embargo, necesitaremos ejecutarlo en algo concreto, y una de las tareas más populares es el análisis del informe comercial. Así que nos centraremos en ella.
Autor: Stanislav Korotky