Discussão do artigo "Implementado OLAP na negociação (Parte 1): Noções básicas da análise de dados multidimensionais"
Obrigado, um exemplo claro de que o aplicativo funcionou bem. No joelho, se você precisar examinar rapidamente diferentes fatias, funcionou bem.
Invejo o nível de abstração com inveja branca.
O ZЫ MarketInfo apareceu acidentalmente no texto do artigo. Em fontes - normal.
Não como uma crítica, mas de acordo com a lógica do artigo:
Teria sido mais correto chamar o artigo de"Aplicação de OLAP na análise de resultados de negociação", porque o título dá a impressão de que ele analisará a dinâmica do mercado. Mas acontece que o especialista não é um operador de mercado.
Mas o artigo é interessante do ponto de vista da análise de dados finais que não são de mercado.
O título correto do artigo deveria ter sido "Aplicação de OLAP na análise de resultados comerciais".
O título está errado, isso é certo.
Na minha opinião, seria melhor chamá-lo de algo assim: "Trabalhando com espaços multidimensionais em negociações usando a tecnologia OLAP". E então você lê e pensa: o que é OLAP e por que ele está aqui?
Em geral, pelo que entendi, o artigo propõe uma determinada classe de contêiner e a infraestrutura correspondente, que armazena vetores de forma conveniente (vetor no sentido estatístico, ou seja, um conjunto de valores que caracterizam um ponto em um espaço multidimensional). Em princípio, mesmo sem esse contêiner, é possível agrupar dados conforme necessário. Entretanto, é muito mais difícil visualizar espaços multidimensionais. Infelizmente, isso não está escrito no artigo, mas tenho certeza de que o OLAP tem ferramentas de visualização.
Que o nome está errado, isso é certo.
Na minha opinião, seria melhor chamá-lo de algo assim: "Trabalhando com espaços multidimensionais em negociações usando a tecnologia OLAP". E então você lê e pensa: o que é OLAP e por que ele está aqui?
Seria melhor se houvesse mais artigos sobre negociação.
E então acontece que os programadores estão lançando seus desenvolvimentos de outras áreas. Não sei por que, não sei para quem.
Acho que isso estava na ponta da língua de muitas pessoas, eu apenas expressei ))
Seria melhor se houvesse mais artigos sobre negociação.
E, assim, acontece que os programadores descartam seus desenvolvimentos de outras áreas. Não se sabe por que, não se sabe para quem.
Acho que isso estava na boca de muitas pessoas, eu apenas expressei isso )).
Não sei, prefiro ler sobre OLAP do que artigos como "Martingale como base para uma estratégia de negociação de longo prazo".
O artigo apresenta classes universais, que podem ser usadas para analisar qualquer dado numérico relacionado à negociação (é mencionado), daí o nome "negociação".
Considero essa ferramenta muito útil para a negociação, na categoria de "must have". Se alguém quiser algo mais "comercial" - não sei por quais critérios -, deixe solicitações específicas no tópico correspondente no fórum, onde há uma tabela de "desejos".
Aqui está uma citação do início do artigo:
//----------------------------
"Para um relatório de negociação, pode ser interessante obter um detalhamento dos lucros por símbolo, dia da semana, compras e vendas. Ou, por exemplo, para comparar o desempenho de vários robôs de negociação (ou seja, separadamente para cada número mágico).
Fim da citação.
//----------------------------
Esse é um problema prático, cuja solução é ensinada mais adiante no texto. Fim da citação:
//---------------------------
"Para ler registros de alguma fonte abstrata (que no futuro pode ser um histórico de conta de negociação, um arquivo CSV, um relatório HTML ou dados da Internet obtidos usando WebRequest), é necessária outra classe - um DataAdapter. "
Fim da citação.
//---------------------------
Portanto, os dados devem ser obtidos de diferentes fontes (seu formato é conhecido antecipadamente?). Mas vamos supor que o formato do registro de dados analisado seja o mesmo para todos os relatórios. Nesse caso, eu sugeriria uma solução alternativa que não requer uma organização OOP e OLAP complexa.
Um relatório descreve o histórico de uma conta de negociação. Qualquer relatório de negociação tem um centro semântico: uma NEGOCIAÇÃO. As propriedades desse objeto são símbolo, data, lote e um número infinito de outras coisas. Cada propriedade é um parâmetro que tem um histórico de valores de profundidade indeterminada. Nossa tarefa é encontrar rapidamente os dados com base em critérios de composição livre. Sua visualização é secundária. E assim, cada propriedade é um parâmetro com seu próprio histórico de valores. A eficiência da recuperação de dados, é claro, depende do método de armazenamento, mas a questão é a seguinte: os dados são infinitamente diversos, porque as propriedades do objeto principal do relatório - Transações - são infinitamente diversas, e o estado de cada propriedade (o valor atual do parâmetro) pode ser um filtro para pesquisar paralelos no histórico de valores de outros parâmetros. Em outras palavras, há uma variedade infinita de opções para a agregação de dados, e as tentativas de distribuir e armazenar o histórico em complexos pré-preparados e estruturados não levarão a uma diminuição da eficiência da extração e da velocidade da agregação? Com certeza, sim.
O único método universal de registro e armazenamento de dados que consigo ver é a criação de vetores paralelos (por exemplo, recursos), cada um contendo um histórico dos valores de seus parâmetros. Como uma transação está vinculada a um horário específico, ela tem um número de série e, portanto, cada transação combina qualquer número de propriedades, cujo histórico de valores é registrado em um número n de vetores. Essa é toda a essência do método proposto por mim para organizar e armazenar dados de relatórios. Não vejo nada mais universal.
Agora, sobre a agregação de dados. Obviamente, você deve usar o paralelismo de vetores sempre que possível e, quando a tarefa for mais complicada, você deve usar os ciclos de pesquisa usuais. Não precisamos de sistemas estruturados complexos para isso, e a solução universal é criar a função de agregação principal usando diferentes métodos de filtragem de dados. Ou seja, um bloco de trabalho com um conjunto de filtros que pode ser reabastecido. Todos.
//---------------------------
Sem dúvida, o OLAP é uma boa técnica.
Mas, na minha humilde opinião, o principal recurso do OLAP é a integração. Com armazenamentos e outras fontes de dados. Assim, as possibilidades de análise se expandem drasticamente. E dentro de um aplicativo com seus próprios conjuntos de dados não é muito cômico.
Espero que nos próximos artigos haja exemplos correspondentes.
Ah-da ! O artigo é ótimo, o código é excelente, é raro encontrar algo assim aqui
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Novo artigo Implementado OLAP na negociação (Parte 1): Noções básicas da análise de dados multidimensionais foi publicado:
O artigo descreve os princípios gerais de como construir uma estrutura para analisar dados multidimensionais (OLAP) rapidamente, além disso, apresenta como implementá-la em MQL e como usá-la no ambiente MetaTrader usando um exemplo que mostra o processamento do histórico de uma conta de negociação.
Os traders geralmente precisam analisar quantidades significativas de dados que, normalmente, são números, isto é: cotações, leituras de indicadores, resultados de relatórios de negociação. Devido ao grande número de parâmetros e condições de que esses números dependem, é melhor lidar com eles segundo o princípio de dividir e conquistar, isto é, em partes, e examiná-los de vários ângulos. De certo modo, toda a informação forma um hipercubo virtual, no qual cada parâmetro define sua dimensão de maneira perpendicular ao resto. Para processar e analisar tais hipercubos, existe OLAP (em inglês, Online Analytical Processing).
A palavra 'online' no título se refere à prontidão para obter resultados. O princípio de ação consiste no cálculo preliminar das células do hipercubo, para, depois, rapidamente extrair e ver qualquer seção transversal do cubo. Por exemplo, isso pode ser comparado com o processo de otimização no MetaTrader: primeiro, o testador calcula as variantes de negociação (o que pode levar muito tempo) e, em seguida, é obtido um relatório que mostra as leituras de indicadores em relação aos parâmetros de entrada. A partir do build 1860, o MetaTrader 5 permite que você altere dinamicamente os resultados de otimização visualizados, alternando vários critérios de otimização. Isso nos aproxima da ideia do OLAP. Mas, para uma análise completa, seria bom poder selecionar rapidamente muitas outras seções do hipercubo.
Hoje tentaremos implementar a abordagem do OLAP no MetaTrader e implementar análise multidimensional usando ferramentas MQL. Antes de começar, é necessário determinar quais dados analisaremos (por exemplo, relatórios de negociação, resultados de otimização, leituras de indicadores). Em princípio, nossa escolha nesta etapa não é tão importante, porque a estrutura a ser desenvolvida deve ser um mecanismo universal orientado a objetos aplicável a qualquer dado. No entanto, precisaremos executá-lo em algo concreto, e como uma das tarefas mais populares é a análise de relatórios de negociação, vamos nos debruçar sobre ela.
Autor: Stanislav Korotky