понедельник, 4 июня 2018 г.

Design do sistema de comércio amibroker


Base de Conhecimento dos Usuários.


14 de outubro de 2018.


EOD Gap-Trading Portfolio sistema.


Adicionado em 29 de fevereiro de 2018, pontos adicionais a considerar:


1) Este sistema depende da obtenção de preenchimentos precisos ao preço aberto. Para obter esses preenchimentos, é necessário um feed de dados de atraso mínimo de qualidade e habilidades avançadas de programação para implementar a automação comercial.


2) Ao definir o preço de entrada ligeiramente abaixo do preço de abertura (tentando melhorar o desempenho), o sistema falha miseravelmente. Mesmo melhorar o preço por apenas um centavo mata o sistema. Isso sugere que a maior parte do lucro vem dos dias em que o preço do Open foi igual ao Baixo diário, ou seja, o preço subiu do Open e nunca caiu abaixo dele. Isso, é claro, é óbvio. Para confirmar isso, adicionei esta condição de teste (olha para frente) para excluir dias em que Open == Low:


Compre = Compre E NÃO O == L;


Isso mata o sistema e prova que a maior parte do lucro vem dos dias em que O == L. Para confirmar ainda isso adicionei a condição oposta:


Comprar = Comprar AND O == L;


Isso dá lucros quase infinitos e prova que a maioria dos lucros vem de dias em que o preço se move imediatamente a partir do Open e nunca retorna abaixo dele. Tentando melhorar o preço de entrada é um erro; deve-se entrar em um Stop set 1-2 ct acima do preço Open, isso eliminará os dias em que o preço cai e nunca volta. Isso melhora significativamente o desempenho.


3) Este sistema comercializa respostas / padrões de tradutores do joelho. Esses padrões geralmente são afogados por grande volume de negócios, portanto, esse sistema funciona muito melhor quando você seleciona tickers com volumes entre 500.000 e 5.000.000 ações / dia. Isso também melhora significativamente o desempenho.


A adição das duas características acima resulta em uma curva de equidade muito melhor do que a mostrada abaixo. Desculpe, não tenho tempo para documentar o acima em maior detalhe. Boa sorte!


Esta publicação descreve uma idéia de negociação muito simples apenas para Long-only que compra em uma determinada porcentagem abaixo de ontem e baixa, e sai no dia seguinte # 8217; s Open. Às vezes, pode ser difícil obter o preço aberto exato, a alta rentabilidade deste sistema torna um bom candidato para novas experiências. O sistema funciona bem com Watchlists como N100, SP500, SP1500, Russel 1000, etc. Desempenho no Russel 1000, com max. posições abertas definidas em 1, para o período de 12/10/2003 a 12/10/2018, tem essa aparência:


Algumas das outras Watchlists dão menos exposição (lucros), mas isso vem com DDs menores. As comissões foram fixadas em US $ 0,005 por ação. Nenhuma margem utilizada.


Não é utilizada classificação explícita; Os tickers são negociados com base em seu tipo alfabético na Watchlist. Isso pode parecer estranho, mas é significativo: ao reverter esse tipo, o sistema falha. Isso pode significar que, devido a problemas de varredura em tempo real, os símbolos listados no topo deste tipo podem ser negociados de forma diferente dos listados na parte inferior.


Preste atenção ao Liquidity (você pode querer negociar mais de uma posição) e slppage (A entrada é bastante livre de risco, mas as saídas podem ser problemáticas). Os DDs são significativos, mas podem ser compensados ​​com entradas e saídas negociadas em tempo real melhoradas. Ao negociar automaticamente, pode ser possível colocar ordens de entrada OCA DAY-LMT para todos os sinais e apenas esperar e ver o que preencher. Como as saídas são mais difíceis do que as entradas, você pode querer explorar outras estratégias de saída.


Os valores padrão dos parâmetros são escolhidos apenas de um chapéu. Praticamente você pode otimizá-los ou ajustá-los dinamicamente para os tickers individuais. Testei brevemente este sistema no modo Walk-Forward e os resultados foram lucrativos para todos os anos testados. Exceto pelo número de ações, os parâmetros negociados não são muito críticos. O excesso de otimização não parece um problema neste caso.


O código abaixo é muito simples e requer poucas explicações. No entanto, é importante entender que este sistema goza de uma pequena vantagem ao negociar no Open e ao calcular o TrendMA usando o mesmo preço Open. Alguns podem interpretar isso como vazamento futuro, no entanto, se você trocar este sistema em tempo real, não é. Muitas pessoas não percebem que, se você trocar no Open, você também pode usar esse preço em seus cálculos e # 8212; contanto que você os execute em tempo real & # 8212; É aqui que a AmiBroker e a tecnologia podem lhe dar uma vantagem. Se você Ref () retornar a TrendMA por uma barra, o sistema ainda é muito lucrativo, porém os DDs aumentam para algumas Listas de Verificação. Se você usa investimentos fixos, a diferença é insignificante.


O procedimento de negociação seria começar a digitalizar antes do mercado abrir e remover os tickers com preços tão remotos que não são susceptíveis de atender ao OpenThresh. Assim, você pode começar a escanear 1000 símbolos, mas muito rapidamente o número escaneado diminui para apenas uma dúzia de tickers. Quando você se aproxima das 9h30, sua varredura em tempo real será muito rápida e você poderá colocar sua ordem LMT muito próxima do Open & # 8211; você pode até mesmo melhorar o preço aberto.


Embora algumas pessoas tenham olhado o código abaixo e não encontraram nada errado, os lucros parecem bastante elevados para um sistema tão simples. Informe os erros que você pode ver.


Arquivado por Herman às 7:03 pm sob Ideas (Experimental)


Comentários desativados no sistema EOD Gap-Trading Portfolio.


1 de setembro de 2018.


Uma idéia comercial de EOD Gap de longa duração.


Essa idéia foi postada (# 161332) na lista principal do AmiBroker em 3 de julho de 2018. Houve inúmeros comentários excelentes na lista e se você está interessado em trabalhar neste sistema, você faz bem em lê-los todos antes de começar. Depois de postar, encontrei uma série de postagens na web discutindo essa idéia comercial, alguns alegaram estar negociando um sistema similar com um bom sucesso.


Eu me referi a este sistema a & # 8220; Gap Trading & # 8221; sistema, mas isso pode ser um pouco de um nome incorreto, & # 8220; Reversão média & # 8221; pode ser uma classificação melhor. Googling para isso irá obter muitos mais hits para sistemas semelhantes. Aqui estão alguns links:


Parece ser uma idéia comercial bastante amplamente discutida e eu sugiro que você faça alguns Googling por conta própria para aprender o mais recente. Como um usuário Amibroker, você possui melhores ferramentas do que a maioria dos comerciantes e você tem uma chance melhor do que a maioria de apresentar uma variação que funcione. Talvez com um pouco menos lucros, e com uma quantidade significativa de código adicional # 8212; ele ganhou & # 8217; t ser um & # 8220; quicky & # 8221; projeto :-)


Algumas pessoas comentaram que este sistema não funcionará na negociação real, enquanto eles podem estar certos, outros dizem que regimes como este trabalho. Eu não terminei o sistema e não posso reivindicar se é negociável ou não.


O sistema compra a uma determinada porcentagem abaixo de ontem & # 8217; s Low, em uma ordem LMT, e sai no mesmo dia no fim.


Arquivado por Herman às 6:53 pm sob Ideias (Experimental)


Comentários desativados em uma idéia de negociação de Long-only EOD Gap.


28 de novembro de 2007.


Retorno inverso ao sistema médio.


Arquivado por brian_z às 11:54 pm sob Ideas (Experimental)


Comentários desativados no sistema Inverse Return To Mean.


22 de outubro de 2007.


MACD Trend System.


Eu uso um pequeno critério de configuração para procurar minhas ações.


Procuro guias de histograma 4 e 1 barra para sinal de compra (eu tenho o histograma definido como vermelho para baixo e azul para cima para que eu possa ver.


MACD acima da Linha Zero.


Este sistema baseia-se no comércio de tendências. Comprar no pullback quando o mercado continuar sua tendência ascendente.


Para procurar MACD Trend setups:


1) Insira a seguinte fórmula em um gráfico.


Os estoques que atendam aos critérios serão reportados na lista de resultados.


Nota: algumas variações das regras de configuração podem definir sinais que são bastante raros e, em bancos de dados pequenos, é possível que não haja configurações em nenhum dia determinado (portanto, nenhum estoque será relatado pela verificação).


3) Clique em qualquer símbolo no painel Resultados para visualizar o gráfico, para esse símbolo, em segundo plano.


Nota: neste exemplo, foi utilizado um banco de dados de treinamento, que apenas contém dados até 5/11/2007.


Idéia comercial por protraderinc. Comentários e fórmulas de Bill & # 8211; WaveMechanic.


Arquivado por brian_z às 11:06 pm sob Ideias (Experimental)


Comentários desativados no MACD Trend System.


14 de outubro de 2007.


Sistema de negociação de 15 dias.


Arquivado por brian_z às 10:43 pm sob Ideas (Experimental)


Comments Off no 15 Day Performers Trading System.


19 de agosto de 2007.


KISS-001: Intraday Gap Trading.


Esta é a primeira de uma série de idéias de negociação KISS (mantê-lo simples, estúpido) para você brincar. Todas as ideias do sistema apresentadas aqui não são comprovadas, não finalizadas e podem conter erros. Eles são destinados a mostrar padrões possíveis para uma maior exploração. Como sempre, você é convidado a fazer comentários e / ou adicionar suas próprias idéias a esta série.


Eu prefiro os sistemas em tempo real que comercializam rápido, são automatizados e estão desprovidos de indicadores tradicionais. De preferência, eles não devem ter parâmetros otimizáveis; No entanto, eu nem sempre posso conseguir esse objetivo. Nem todos os sistemas serão "isso" simples; haverá alguns que utilizam funções de média simples ou de tipo HHV / LLV. O primeiro sistema mostrado abaixo é uma cópia do sistema de demonstração que uso para desenvolver rotinas de Automação de Comércio em outros lugares neste site.


Para ver como isso funciona, você deve fazer o Backtest em dados de 1 minuto com uma periodicidade no intervalo de 5-60 minutos. Sua primeira impressão pode ser que esses lucros são simplesmente devido a um mercado superior, no entanto, o fato de que os lucros Longos e Curtos são aproximadamente iguais sugerem que há mais. Porque 98% de todos os negócios caem entre as 9:30 da manhã e as 10:30 da manhã, esse tipo de sistema é bom se você quer trocar pouco tempo a cada dia. Isso reduz o risco em relação à exposição ao mercado e dá mais tempo para aproveitar outras atividades.


Backtesting isso na lista de vigilância NASDAQ-100 (backtests individuais, 15 min. Periodicidade) dá os lucros mostrados abaixo para o período de 1 MAR 2007 até 17 de agosto de 2007. Os nomes de Ticker são omitidos para manter o gráfico compacto; O gráfico mostra simplesmente uma barra de lucro líquido para cada ticker testado. A exposição média deste sistema é de cerca de 15%; daí, você pode negociar carteiras para aumentar os lucros e suavizar as curvas de equidade. Seja advertido que, em sua forma bruta, as retiradas são inaceitáveis ​​e que pode haver restrições de volume para muitos tickers.


Uma vez que este sistema tem pouca exposição, pode ser um candidato para escaneamento de mercado e negociação de carteira classificada. RARs seria uma indicação dos lucros máximos absolutos que poderiam ser obtidos se conseguisse aumentar a exposição a cerca de 100%. No entanto, o movimento de preços de diferentes tickers pode ser correlacionado, e os negócios de diferentes tickers podem se sobrepor. Se muitos tickers operarem ao mesmo tempo, seria difícil aumentar a exposição do sistema.


Editado por Al Venosa.


Arquivado por Herman às 1:49 pm sob Ideias (Experimental)


Comentários desativados no KISS-001: Intraday Gap Trading.


17 de agosto de 2007.


System Ideas na Internet.


Você está convidado a enviar links para ideias do sistema em comentários para esta publicação.


Arquivado por Herman às 7:46 pm sob Sistemas de Negociação.


16 de julho de 2007.


Introdução aos Sistemas de Negociação & # 8211; Prático.


Esta categoria é reservada para sistemas reais de negociação, ou seja, que você negociou em algum momento ou que consideraria negociar. Uma vez que os critérios de negociação variam de pessoa para pessoa, e como os sistemas podem funcionar ou não dependendo de como eles são negociados, será difícil fazer a seleção de contribuições aqui. Com respeito ao que é publicado aqui, mantenha uma mente aberta e considere que o autor considera o sistema negociável.


Você pode contribuir postando como autor (requer registro) ou em um comentário para esta publicação.


Arquivado por Herman às 11:14 am sob Prático (Rentável)


Comentários desativados na Introdução aos Sistemas de Negociação & # 8211; Prático.


Introdução aos Sistemas de Negociação & # 8211; Idéias.


É aqui que você pode compartilhar sistemas de negociação que são marginalmente lucrativos, ou seja, aqueles que não devem ser negociados como estão, mas que mostram potencial. Normalmente, este seria um sistema básico que é rentável, mas as experiências diminuem 50%. Tais sistemas geralmente podem ser aprimorados pela adição de paradas, metas, gerenciamento de dinheiro, técnicas de portfólio, etc. A realidade é que, embora você não tenha a experiência para fazê-lo funcionar, outra pessoa pode.


Quase todos nós encontramos idéias do sistema de comércio em livros e revistas que codificamos na AFL para avaliação. Alguns desses sistemas podem estar por muitos anos, enquanto outros são idéias novas. Depois de codificá-los, quase sempre, estamos desapontados e retiramos o sistema (trabalho!). Em vez de jogar o seu trabalho, você está convidado a publicar o sistema aqui para dar a outro desenvolvedor a chance de corrigi-lo.


Você é convidado a contribuir como autor (requer registro) ou em um comentário para esta publicação.


Arquivado por Herman às 11:04 am sob Ideas (Experimental)


Comentários desativados na Introdução aos Sistemas de Negociação & # 8211; Idéias.


Postagens recentes.


Comentários recentes.


Richard Dale no Data Resources & # 8211; Forex Herman em solicitação de tópicos em tempo real aqui Mike B em solicitação de tópicos em tempo real aqui Tomasz Janeczko no banco de dados de estoque dos EUA (v2) brian_z na Configuração Um banco de dados personalizado e # 8211; Nasdaq.


Categorias.


Outubro de 2018 (1) setembro de 2018 (1) agosto de 2018 (1) julho de 2018 (1) abril de 2018 (2) março de 2018 (6) fevereiro de 2018 (2) janeiro de 2018 (2) fevereiro de 2009 (2) agosto de 2008 (1) Abril de 2008 (1) março de 2008 (20) fevereiro de 2008 (6) janeiro de 2008 (1) dezembro de 2007 (4) novembro de 2007 (18) outubro de 2007 (17) setembro de 2007 (17) agosto de 2007 (26) julho de 2007 (20) Junho de 2007 (17) maio de 2007 (8) abril de 2007 (16) janeiro de 2007 (1)


Este site usa a página do WordPress gerada em 0.858 segundos.


Base de Conhecimento dos Usuários.


21 de julho de 2007.


Armadilhas de Design do Sistema.


Quando você está projetando um sistema de negociação em tempo real, muitas coisas podem dar errado. Esta publicação destina-se a alertá-lo para algumas das possíveis armadilhas. No entanto, isso é tudo o que pode fazer. A única experiência pode ensinar-lhe como evitá-los. Esteja ciente de que mesmo os designers mais experientes farão alguns desses erros repetidamente.


Uma vez que documentar todas as armadilhas potenciais com exemplos de codificação consumiria muito tempo e espaço, eles são, por enquanto, apenas comentados brevemente. A maioria deles irá desencadear uma resposta do usuário de & # 8220; Ah, sim, isso aconteceu comigo! & # 8221 ;. Se você precisar de uma explicação mais detalhada, você pode postar perguntas em um comentário para esta publicação.


Não existem regras para provar que um sistema de negociação está livre de erros de codificação ou lógica. No entanto, dois indicadores são bastante confiáveis ​​ao sugerir que você pode ter um problema:


1) Seus lucros são simplesmente muito bons para ser verdade. Nesse caso, você não tem escolha senão trabalhar através do código linha por linha, tentando encontrar linhas de código que olhem para o futuro. Se isso não revelar quaisquer erros, então você teria que inspecionar os sinais plotados e trocar comércio por comércio.


2) Seu sistema é uma negociação muito rentável Long, mas não curto, ou curto comprar não longo. Quando isso acontece, você pode ter um erro nas partes Longas ou Curtas do seu código, e a comparação das duas seções geralmente revelará o problema (isso só funciona para sistemas de reversão). No entanto, também pode ser que o seu código esteja correto, mas que seu princípio de negociação é sensivelmente sensível às tendências. Isso quase certamente o levaria a problemas quando a tendência se reverta. Neste caso, não existe outra cura do que repensar o sistema básico.


Ao projetar sistemas de negociação de alta freqüência, ou seja, aqueles cujas durações comerciais são em minutos, tudo muda e muitos procedimentos tradicionais se desintegram. Os atrasos na Internet, os atrasos nos dados, os dados incorretos (picos), o sistema temporário congela (o Windows às vezes tem uma mente própria), relatórios de status atrasados, problemas de TWS, etc., todos se tornam problemas críticos que evitarão que você obtenha uma correspondência próxima com o Backtester.


Muitos desses problemas só serão exibidos quando você começar a negociar dinheiro real. Assim, as etapas finais do desenvolvimento de um sistema comercial devem sempre envolver o dinheiro real de negociação. Aqui é onde o simulador de conta Interactive Brokers (conta de negociação de papel) pode ser uma ferramenta indispensável, pois você pode testar seu sistema em tempo real sem comprometer dinheiro real. Mas, como o mercado não vê seus negócios, mesmo os resultados da negociação de papel serão diferentes do dinheiro real de negociação. Em geral, quanto mais rápido você trocar, maior será o seu resultado de negociação real se desviará dos seus resultados de backtest. Você também deve estar ciente de que as comissões desempenham um papel muito maior no desempenho de sistemas de negociação de alta freqüência porque os lucros comerciais são menores.


Não importa como você vá sobre isso, solucionar um sistema comercial complexo quase sempre será um trabalho tedioso e chato que pode mantê-lo ocupado por vários dias ou semanas. Se você achar que certos problemas continuam a ressurgir, eles provavelmente estão relacionados ao seu estilo de desenvolvimento pessoal e você poderá escrever algum código que verifique esses problemas específicos. Veja a categoria Depuração para algumas idéias.


A lista abaixo, que não é exaustiva, é apresentada para alertá-lo de que muitas áreas podem levar a problemas. Alguns são óbvios, enquanto outros podem ser expandidos conforme necessário e o tempo o permite.


& # 8211; Prioridade alta / baixa (contrariamente ao EOD, onde o Backtester não consegue determinar qual veio primeiro, a entrada / saída ou o alto / baixo, em tempo real, não pode haver ambigüidade na precedência de preços).


& # 8211; Atrasos de dados (dados em tempo real podem ser atrasados ​​por vários motivos e períodos de tempo (atrasos na Internet, falta de cotações, pacotes versus tiques, etc.).


& # 8211; Baixa liquidez (pode haver períodos de negociação sem volume).


& # 8211; Data Holes (barras sem trades).


& # 8211; Spikes de dados (picos altos sem volume podem desencadear negócios).


& # 8211; Recheio de dados (uma barra sem dados pode ser preenchida).


& # 8211; Premature Padding (a última barra pode ser uma barra acolchoada).


& # 8211; Precisão de dados (os preços que você recebe nem sempre são precisos).


& # 8211; Randly Slippage (você raramente receberá o preço esperado).


& # 8211; Deslizamento (você raramente receberá o preço Breakout do seu sistema).


& # 8211; Survivorship Bias (empresas que não fizeram bem e interromperam a negociação não estarão em seu banco de dados, ou seja, você está trabalhando acima das ações médias).


& # 8211; Lucky Trades (uma série de negócios de sorte pode parecer um bom desempenho).


& # 8211; Parâmetro sobre otimização (os parâmetros otimizados raramente são estáveis ​​ao longo do tempo).


& # 8211; Design sobre otimização (o teste freqüente é como executar uma otimização e pode levar a conclusões falsas).


& # 8211; Preços fora de limite (com PriceBoundChecking ativado, a AmiBroker força o preço de negociação no intervalo High-Low, isso pode ocultar erros de preços).


& # 8211; Arredondamento de preços (os preços podem ser arredondados ou truncados pelo corretor).


& # 8211; Uso incorreto de> = e = na mesma declaração, apenas a primeira condição igual será vista).


& # 8211; Comparando números de pontos flutuantes (os valores calculados podem ter várias casas decimais, valores redondos ou usar o AlmostEqual ()).


& # 8211; Justificação do gráfico (certifique-se de que está olhando para o último bar!).


& # 8211; Mortalidade do sistema (nenhum sistema funcionará para sempre).


& # 8211; Compartilhando Sistemas de Negociação (o compartilhamento de sistemas com outros comerciantes pode resultar em uma negociação excessiva de um sistema).


& # 8211; Sendo Duped por uma tendência (um ticker de rally pode fazer o seu sistema parecer o HG (santo Graal).


& # 8211; Truque AmiBroker (AmiBroker tem seus limites, é possível escrever código esotérico que produza resultados errados).


& # 8211; Visibilidade da encomenda (colocar o seu pedido para cada comerciante ver pode influenciar as encomendas que eles colocam).


& # 8211; Making the Market (exemplo extremo: se você colocar uma ordem MKT durante um período sem negociação, você mudará o gráfico).


& # 8211; Ordem de execução de janela / painel (ao passar variáveis ​​entre painéis ou janelas não presume que eles executem em uma ordem fixa, mais).


& # 8211; Negociação no Open (a execução da ordem no início / fim do dia é diferente do meio-dia devido a volatilidade e atrasos de dados).


& # 8211; IB Data Snap Shots (os instantâneos são apenas representativos dos preços negociados).


& # 8211; Atrasos de comércio (certifique-se de entender os atrasos de seu comércio quando backtesting).


& # 8211; EOD e lacunas intradiárias (não há intervalo de tempo nas lacunas RT).


& # 8211; Zonas horárias (certifique-se de que o seu time e o seu banco de dados estão devidamente configurados).


& # 8211; Quadros de tempo muito curtos (os preços saltam e são menos contíguos).


& # 8211; Definir os preços LMT (considere o arredondamento para execuções de pedidos mais rápidas).


& # 8211; 24 horas vs. RTH (hora de negociação regular) Backtesting (as horas prolongadas raramente podem ser negociadas como o RTH devido a grandes spreads de oferta / pergunta e baixo volume).


& # 8211; Nomeação de variáveis ​​estáticas (use nomes exclusivos para suas variáveis ​​estáticas).


& # 8211; Tempo de computador incorreto (o deslocamento do tempo do computador a partir do horário do mercado pode causar problemas reais).


& # 8211; Problemas de Look-Ahead (nem todos os problemas de codificação de look-ahead são óbvios).


& # 8211; Compre / Venda Precedência em um Loop (esteja ciente de que o AB e os rolamentos AFL personalizados importam uma prioridade de Compra / Venda).


& # 8211; RT Discrepancies de velas (RT Velas podem ser diferentes dos backfills posteriores, especialmente na impressão de abertura).


& # 8211; Barras carregadas (considere barras carregadas em relação à velocidade de execução e loops).


& # 8211; Tempo de vida do sinal (a intensidade do sinal decai rapidamente sobre as barras na negociação de alta freqüência).


& # 8211; SameBarExits (sinais de venda podem atuar como um qualificador para sinais de compra).


& # 8211; Projetando sistemas baseados em disparadores Alto e Baixo (estes podem preencher o Backtester, mas não na negociação real). mais & # 8230;


& # 8211; Usando o CommissionMode e / ou o CommissionAmount incorretos pode fazer com que qualquer sistema pareça bom ou mau e # 8230;


& # 8211; Usando zero TradeDelays está OK se você codificar os atrasos no código do seu sistema, caso contrário você pode estar olhando para o futuro.


Editado por Al Venosa.


Comentários desativados em armadilhas de design do sistema.


Comentários estão fechados.


Postagens recentes.


Comentários recentes.


Richard Dale no Data Resources & # 8211; Forex Herman em solicitação de tópicos em tempo real aqui Mike B em solicitação de tópicos em tempo real aqui Tomasz Janeczko no banco de dados de estoque dos EUA (v2) brian_z na Configuração Um banco de dados personalizado e # 8211; Nasdaq.


Categorias.


Outubro de 2018 (1) setembro de 2018 (1) agosto de 2018 (1) julho de 2018 (1) abril de 2018 (2) março de 2018 (6) fevereiro de 2018 (2) janeiro de 2018 (2) fevereiro de 2009 (2) agosto de 2008 (1) Abril de 2008 (1) março de 2008 (20) fevereiro de 2008 (6) janeiro de 2008 (1) dezembro de 2007 (4) novembro de 2007 (18) outubro de 2007 (17) setembro de 2007 (17) agosto de 2007 (26) julho de 2007 (20) Junho de 2007 (17) maio de 2007 (8) abril de 2007 (16) janeiro de 2007 (1)


Este site usa a página do WordPress gerada em 0.838 segundos.


Amibroker Trading System Design & # 8211; Bangalore Workshop & # 8211; Maio de 2017.


No Premier Inn, Brookfield Main Road, Opp to Shell Gasolina Pump, Seetharampalya, Hoodi, Bangalore, Karnataka, Índia.


Suporte ao Cliente: 09738383344/09535133445 (9 a. m & # 8211; 6 p. m IST Seg-Sex)


O que será coberto no Workshop?


1) Os vários aspectos do design de sistemas de negociação, como gerar idéias originais para sistemas, abordagens estatísticas de sistemas e o uso efetivo de indicadores.


2) Regras de negociação sobre quando ativar e quando descartar os sistemas de negociação.


3) Sistema de negociação simples versus sistema de negociação de carteira. Prós e contras.


4) Otimização do sistema de negociação, diretrizes e quão freqüente para ajustar o sistema.


5) Qual prazo para o comércio efetivamente. Que tipo de sistema comercial a seguir.


6) Discussão sobre Automatização do seu Sistema de Negociação, Plataformas Disponíveis, Custo.


7) Como construir sistemas de comércio sazonais e discretos.


1) Introdução rápida aos conceitos de Design do Sistema de Negociação, Backtesting e Otimização usando o Amibroker.


2) Que tipo de desempenho você pode esperar do sistema comercial. Testando a realidade de vários sistemas de negociação.


3) Como projetar Sistemas de Negociação Intraday ou Sistemas de Negociação Baseados no Tempo.


4) Como validar a robustez dos sistemas de negociação.


5) Sistemas discretos com abordagem totalmente sistemática.


6) Como escolher a abordagem correta de gerenciamento de dinheiro.


1) Qual prazo para o comércio efetivamente. Que tipo de sistema comercial a seguir.


2) Como medir o benchmark de vários sistemas de negociação.


3) Como construir sistemas de negociação de carteira.


4) Discussão sobre Automatização do seu Sistema de Negociação, Plataformas Disponíveis, Costfactors.


5) Discussão sobre qualquer outro sistema de que você queira falar.


6) Introdução ao Marketcalls Trading Studio (coleção de indicadores premium personalizados) e 1 Ano de Acesso Complementar ao Marketcalls Trading Studio.


Os participantes receberão vários dispositivos USB de slides, indicadores, dados de teste usados ​​durante as apresentações. Os apresentadores fornecerão os códigos de alguns sistemas ao vivo que eles atualmente usam para negociar para ajudar a explicar os vários conceitos que eles cobrem.


Os participantes também, obviamente, obterão o código de qualquer coisa desenvolvida durante o workshop.


1 Ano de Acesso Complementar ao Marketcalls Trading Studio.


1 ano de acesso a 20 horas de Tutoriais de codificação AFL Amibroker.


Ofertas especiais de nossos Patrocinadores de Eventos & # 038; Delicioso almoço.


Compreensão básica dos mercados de ações, futuros e opções.


Um laptop (Windows) com Amibroker versão 5.8 ou superior instalado.


Quem deve participar desta oficina.


Comerciantes, analistas, corretores, estudantes universitários, pessoas interessadas em investir, DayTrading, análise técnica, estratégias de negociação, softwares de negociação, desenvolvimento do sistema de negociação, entusiastas autotrading.


Leituras e observações relacionadas.


Tradezilla & # 8211; Programa de Mentorship Online para Comerciantes O Tradezilla é o primeiro e exclusivo programa de orientação de negociação on-line da Índia para comerciantes em ascensão. O evento se concentrará em fornecer informações de qualidade aos comerciantes, [& hellip;] Divergence 2018 & # 8211; Traders Annual Web Conference Divergence é a maior conferência na web de comerciantes da Índia e a primeira conferência on-line de marketcalls. Este ano estamos nos concentrando em tópicos como o sistema comercial, Amibroker AFL Programming, [& hellip;] Amibroker AFL 2018 & # 8211; Bangalore Workshop Galeria de fotos Amibroker AFL 2018 - Bangalore Workshop Galeria de fotos Amibroker AFL coding & # 8211; Galeria de fotos Em primeiro lugar, agradeço pessoalmente ao senhor deputado Jagdish Ahuja (organizador da ATMA) por fornecer oportunidade e organizar esta codificação Amibroker AFL para tornar este evento bem sucedido. O evento é menos de [& hellip;] & # 8220; Amibroker AFL coding & # 8221; & # 8211; 26º ATMA Bengaluru Meet Este é meu primeiro evento com ATMA. Estará falando sobre os conceitos de codificação AFR da Amibroker. Provavelmente o primeiro grupo a discutir sobre conceitos de programação e fornecer codificação ao vivo [& hellip;] Workshop Coimbatore Amibroker - Galeria de fotos Em primeiro lugar, agradeço pessoalmente ao Sr. Ravi Shengodan (corretor livre) o AP de Zerodha por organizar este workshop de forma ordenada e feito muitos esforços no backend para tornar este evento bem sucedido [& hellip;]


Sobre Rajandran.


Rajandran é comerciante de tempo integral e fundador da Marketcalls, muito interessado em construir modelos de timing, algos, conceitos de negociação discricionária e análises Sentimental de Negociação. Ele agora instrui usuários em todo o mundo, de comerciantes experientes, comerciantes profissionais para comerciantes individuais.


Rajandran frequentou a faculdade no Chennai, onde ganhou um BE em Eletrônica e Comunicações. Rajandran tem uma ampla compreensão de softwares de negociação como Amibroker, Ninjatrader, Esignal, Metastock, Motivewave, Market Analyst (Optuma), Metatrader, Tradingivew, Python e entende necessidades individuais de comerciantes e investidores usando uma ampla gama de metodologias.


Estou interessado em testar uma idéia para uma estratégia de impulso rotacional e me perguntei se este é um serviço que você oferece?


sim nós fazemos. Você pode enviar seus requisitos para rajandran@marketcalls. in.


Estou interessado em comercializar sinal em estoque uma idéia para uma estratégia momentum,


responda por idioma malayalam, sou malayalee de Kerala,


Deixe uma resposta Cancelar resposta.


Requisição de responsabilidade do governo dos EUA e regra 4.41 do CTFC.


© Copyright 2018 Marketcalls Financial Services Pvt Ltd & middot; Todos os Direitos Reservados & middot; E Nosso Sitemap & middot; Todos os logótipos e amp; Trademark pertence a seus respectivos Proprietários & middot;


Base de Conhecimento dos Usuários.


24 de dezembro de 2007.


Negociação automatizada de alta freqüência (HFAT); parte 2.


Dados de volume em tempo real dos corretores interativos.


Assim como os dados de preços, os dados de volume estão sujeitos a atrasos e correções de BF (Backfill). Além disso, IB (Interactive Brokers) relata os dados de volume de uma maneira que poderia causar grandes diferenças de desempenho entre backtesting e negociação real.


Esta publicação descreve procedimentos simples para coletar dados RT e BF para comparação. Não é feito nenhum esforço para explicar as diferenças ou para realizar análises estatísticas. As opiniões expressas aqui são baseadas em experiências pessoais e / ou podem ser anecdóticas; nem tudo que acontece no comércio em tempo real é fácil de explicar. Como sempre, se você tiver uma visão técnica e / ou veja imprecisões, comente para o benefício de futuros leitores.


Conforme esperado, os dados de volume de IB RT contêm os tiques e atrasos ruins usuais que são corrigidos durante o preenchimento. No entanto, e isso é muito importante para o comerciante de RT, o IB ajusta os volumes ao vivo em intervalos de cerca de 30 segundos. Isso significa que os volumes IB relatados durante a negociação RT não refletem com precisão a atividade do mercado. Isso significa também que os dados de volume podem ser atrasados ​​em até 30 segundos, em vez do atraso típico de instantâneo, que é cerca de 300 milissegundos para dados de preço. Comparando o volume recheio com volume em tempo real, parece que os ajustes de volume periódicos em tempo real são re-distribuídos em instantâneos individuais durante o preenchimento. Esta publicação destina-se a ajudá-lo a realizar sua própria análise de dados. Os métodos descritos abaixo são destinados a você começar.


Para coletar e salvar dados em tempo real: crie um novo banco de dados no intervalo de 5 segundos. Incorporar "RD", para Raw Data, ao nomear o banco de dados. Na Configuração do banco de dados, selecione o plugin Interactive Brokers. Escolha um estoque de alto volume, por exemplo, AAPL (usado nesta publicação). Conecte-se à TWS (Trader Work Station), iniciando sessão na sua conta Paper Trading. Não use a conta eDemo. Colete cerca de uma hora de dados em tempo real.


A primeira coisa que acontecerá quando você se conectar ao TWS é que o AmiBroker reabastece aproximadamente 2000 barras de dados de 5 segundos. Isso não pode ser evitado e você deve ter cuidado para observar o tempo em que termina o preenchimento e a coleta de dados em bruto começa. A maneira mais simples é colocar uma linha vertical em seu gráfico e rotulá-lo "Início dos dados em tempo real".


Para salvar o banco de dados: Desconecte o plugin IB (consulte o menu Plugin no canto inferior direito do gráfico). Abra Configurações de banco de dados e defina o banco de dados como Local. Coloque outra linha vertical para indicar onde a coleta de dados parou. Vá para o menu Arquivo e salve o banco de dados.


Certifique-se de configurar as Configurações do Banco de Dados - & gt; Fonte de dados - & gt; Local antes de salvar. Se você não fizer isso, o banco de dados será preenchido na próxima inicialização e isso pode corromper sua amostra de dados RT.


O próximo passo é coletar uma amostra de dados BF que sobrepõe a amostra coletada em tempo real previamente coletada. Para fazer isso, você precisa criar outro banco de dados. Uma vez que o preenchimento de IB apenas cerca de 2000 barras de dados de 5 segundos, você deve fazer isso o mais rápido possível depois de coletar dados brutos, senão os períodos de coleta podem não se sobrepor e você não poderá comparar os dois tipos de dados. O procedimento é o mesmo que acima, exceto que você deseja incorporar "BF" (para dados preenchidos) em vez de "RD" no nome do banco de dados.


Para comparar visualmente os dois bancos de dados, você pode abrir duas instâncias do AmiBroker e carregar o banco de dados RT em um e o banco de dados BF no outro. Você pode então exibir os dois bancos de dados ao mesmo tempo e comparar visualmente os respectivos gráficos. Você pode querer exibir um gráfico de preços e um gráfico de volume em painéis separados, conforme mostrado nas capturas abaixo.


Você pode usar o código abaixo para inspecionar seu gráfico de preços:


E este código para inspecionar seu gráfico de Volume:


As fórmulas acima exibirão gráficos básicos mais um valor cumulativo (área vermelha) para qualquer parâmetro que você gostaria de testar. No gráfico de preços, o intervalo alto-baixo (H-L) é somado enquanto no volume O volume simples é somado. Summation começa com a barra selecionada pelo cursor. Este recurso só é fornecido para revelar visualmente as diferenças de dados; não tem outro significado.


Os gráficos abaixo foram criados usando os métodos acima, que revelam rapidamente a diferença entre os dois tipos de dados. Para explicar por que essa diferença ocorre é deixada ao leitor especializado (porque não tenho uma pista!).


Figura 1 & # 8211; Dados preenchidos novamente.


Figura 2 & # 8211; Dados coletados em tempo real.


O indicador de volume a seguir pode ser usado para exibir a periodicidade do volume RT mais claramente:


Este código produziu os próximos dois gráficos abaixo. Um filtro de espiga simples (veja a definição do VSpike no código) é usado para identificar pontos de volume e fazê-los se destacar com um fundo preto. Como esses picos de volume não aparecem nos dados preenchidos, podemos assumir que eles não refletem a verdadeira atividade do mercado. Os três números na parte superior das barras de histograma, de cima para baixo, mostram o Volume / 100, o número de barras desde o último pico de volume e a segunda contagem derivada do selo de tempo de dados.


Figura 3 - Dados de volume coletados em tempo real.


A aplicação do código nos dados preenchidos produz o gráfico abaixo. Observe que muitos dos baixos períodos de volume entre as espinhas foram preenchidos (parece que os picos de volume foram distribuídos de forma retroativa) e que não há mais periodicidade de volume visível.


Figura 4 & # 8211; Dados de volume reabastecidos.


Comparando dados de diferentes bancos de dados.


Você pode comparar dados de diferentes bancos de dados em um único gráfico. A sobreposição de dois arrays de dados revelará imediatamente diferenças e também sugerirá análise mais sofisticada a ser realizada. O código abaixo pode ser executado por si só, ou pode ser anexado a qualquer outro programa. Neste caso, é codificado para comparação de volume. No entanto, você pode modificá-lo facilmente para comparar preço, indicadores ou qualquer outra matriz. A instrução SetBarsRequired () é necessária para o alinhamento de dados. Você deve usar o mesmo cronograma para gráficos RT e BF e para criação composta. Todos os testes nesta publicação foram realizados no período de 5 segundos.


Para comparar BF com arrays de volume RT, primeiro crie o composto para o volume BF e copie isso para sua base de dados RT para comparação. O procedimento é o seguinte: Carregue o banco de dados que contém sua amostra de dados BF. Exibir os dados e abrir a janela Param:


Selecione BackFillDataSample para o nome da variável estática. Clique em CREAR. Na barra de menu Amibroker, clique em Exibir - & gt; Atualize tudo. Na janela Indicador, defina Overlay Composite para YES. Os dados compostos devem ser exibidos como uma escadaria amarela sobreposta ao seu gráfico de volume. Feche AmiBroker. Use o Windows Explorer para encontrar seu banco de dados BF e copie o composto para o volume BF na pasta "_" e cole-o na pasta "_" do banco de dados RT. Exclua o arquivo Broker. Master do banco de dados RT. Este arquivo será recriado na próxima inicialização. Este passo é necessário para incluir o novo arquivo composto no índice do banco de dados. Inicie o AmiBroker e carregue o banco de dados RT. Exibe o gráfico de volume RT com o qual você estava trabalhando. Se os Parâmetros estiverem configurados como mostrado na captura acima, você deve ver a Escadaria Amarela para Volumes BF sobreposta ao histograma de volume da RT.


Neste ponto, você pode rolar para frente e para trás a tempo de ver como o volume do BF difere do volume coletado da RT. Não clique em CREAR, ou você substituirá o compósito BF. Os gráficos abaixo mostram como seus gráficos devem ser encontrados.


Figura 5 & # 8211; BF composto (amarelo) no histograma de volume BF.


A Figura 5 acima mostra um período em que o volume retalhado coberto composto (por exemplo, o período de preenchimento antes da coleta de RT). Como o composto copiou esses dados BF, eles combinam perfeitamente.


Figura 6 & # 8211; BF Composite (Amarelo) na RT coletou Histograma de volume.


A Figura 6 acima é para um período em que o composto (volume recheado) é sobreposto ao volume coletado em tempo real (histograma). Observe a diferença entre os dois tipos de dados.


O desenvolvimento de um sistema comercial deve começar com o aprendizado sobre o básico; atrasos e má qualidade dos dados podem matar qualquer sistema comercial HFAT, não importa quanto tempo você tenha desenvolvido. A melhor maneira de entender e saber com o que você está trabalhando é escrever alguns pequenos programas, como aqueles que foram incluídos nesta série.


Conclusão.


Nas discussões anteriores, tornou-se claro que o desenvolvimento de um sistema de comércio HFAT pode não ser tão fácil como você pensa. O googling para obter informações revelará muito poucos links para informações práticas; Você será principalmente por sua conta para descobrir as armadilhas. O desenvolvimento com dados ao vivo de sua conta de comércio de papel pode ser melhor do que usar dados preenchidos. No entanto, uma vez que é altamente provável que o IB execute negócios de papel sujeitos ao preço e ao volume relatados, os resultados da negociação de papel podem não corresponder aos resultados reais da negociação. A menos que você esteja plenamente consciente dos vários problemas e possa desenvolver o seu sistema para trabalhar em torno deles, parece inútil tentar desenvolver um sistema de comércio HFAT com dados IB de 5 segundos. Os padrões únicos de volume em tempo real também ocorreram em dados coletados da conta de negociação real.


Os dados de todas as fontes terão seus próprios problemas únicos e é prudente realizar alguns testes básicos para conhecer seus dados de RT antes de gastar muito tempo no desenvolvimento.


IB Snapshots e métodos de compressão de dados são relevantes para a discussão acima; Mesmo que não haja muitos detalhes disponíveis, você pode querer ler os seguintes tópicos para saber mais sobre esses tópicos.


Editado por Al Venosa.


Comentários desativados na negociação automatizada de alta freqüência (HFAT); parte 2.


28 de novembro de 2007.


Negociação automatizada de alta freqüência (HFAT); Parte 1.


Problemas de Backfilled vs Real-Time Data.


Se você não tem certeza do que é HFAT (High Frequency Automated Trading), por favor Google o tópico. Esta publicação destaca alguns dos problemas que você pode encontrar ao se aventurar no HFAT de ações. As opiniões expressas aqui são baseadas em experiências pessoais e / ou podem ser anecdóticas; nem tudo que acontece no comércio em tempo real é fácil de explicar. Se você tiver uma visão técnica e ver imprecisões, comente para o benefício de futuros leitores.


Projetar e implementar sistemas de negociação de alta freqüência é, do ponto de vista de um comerciante, provavelmente a melhor experiência. Para ver e ouvir trades executados a cada poucos segundos e ver os lucros que rolam, deve dar a qualquer comerciante um alto sem precedentes.


A captura é que projetar um sistema HFAT que funciona com dinheiro real é muito diferente de projetar um usando dados locais. Quanto menor o intervalo de tempo, maior o impacto de pequenas discrepâncias de dados. Em intervalos de tempo de sub-minutos, seu sistema HFAT pode executar de forma muito diferente com dados locais do que com dados de mercado em bruto em tempo real.


Um problema típico é que os dados do mercado ao vivo em tempo real são atrasados ​​por várias centenas de milissegundos e que as citações podem chegar fora da seqüência. O que você vê em seus gráficos pode ser várias citações depois que o comércio ocorreu. Este dado falho é o que seu sistema comercial está negociando e deve ser projetado para trabalhar. Os gráficos que você vê na AmiBroker são principalmente preenchidos e / ou atualizados após o horário de negociação. No final de um dia de negociação, você terá dados em seu banco de dados que tenham uma mistura de dados recheados (erros de tempo e dados foram corrigidos) e dados brutos (defeituosos) que foram coletados durante a sessão de negociação do dia atual # 8217; . Você também pode ter várias lacunas de dados que foram introduzidas quando você desligou o sistema e / ou perdeu seu feed de dados.


Embora o procedimento possa variar para diferentes provedores de dados, as cotações recebidas em tempo real serão atrasadas. Uma vez que os períodos de barras durante a coleta de dados ao vivo são baseados no relógio do seu computador, as cotações podem acabar na próxima barra devido à sua chegada atrasada. Os dados usados ​​para preencher seu banco de dados vêm de um servidor de dados diferente e serão marcados no horário. Isso permite que o AmiBroker corrija a posição das citações que foram recebidas fora da sequência. Este processo remove os atrasos em tempo real que estavam presentes quando os dados foram recebidos.


Uma vez que não há atrasos nos dados preenchidos, seus dados preenchidos parecem avançados por várias centenas de milissegundos em relação aos dados que você eventualmente estará negociando.


Não é incomum desenvolver um sistema com dados retalados de 5 segundos (onde todos os carrapatos ruins e erros de carimbo de horário foram corrigidos pelo provedor de dados) e obter o desempenho do Santo Graal somente para descobrir que, quando negociado com dados de transmissão em tempo real (onde os dados são atrasados, contém carrapatos ruins e erros de marcação temporária), o sistema é uma falha total. Os gráficos a seguir ilustram esse problema. Os dados à esquerda da linha vermelha são preenchidos e os dados à direita da linha Vermelha são dados coletados em tempo real. O branco é a equidade.


Você não poderá avaliar visualmente se os dados são preenchidos ou em bruto. As diferenças só aparecerão ao executar um sistema de negociação nos dados; seu sistema comercial pode ser a única maneira de distinguir entre dados preenchidos e dados brutos. O gráfico abaixo mostra um close up da mudança de dados.


O preenchimento do banco de dados acima e o desempenho de outro Backtest ao longo do mesmo período produzem uma equidade muito diferente:


Não há garantia de que um sistema desenvolvido em um tipo de dados funcionará igualmente bem com o outro. Quando você encontra uma grande redução de capital, você pode assumir que isso foi apenas um dia ruim e # 8221 ;; Afinal, todos os sistemas de negociação os possuem. Você pode ter desenvolvido e testado seu sistema em milhares de negócios, cobrindo um período de seis meses ou mais. Você tem sido um bom aluno e usou todos os métodos recomendados para validar seu sistema de negociação. Você testou intern e out-of-sample, aplicou otimizações inteligentes, usou o Walk-Forward testing, realizou a análise de Monte-Carlo e a lista continua. Depois de ser tão minucioso, como você pode dar errado? Você está pronto para negociar dinheiro real amanhã e faça seus primeiros 50% em um dia!


O objetivo é que todo esse esforço é desperdiçado se os dados usados ​​durante o desenvolvimento não forem 100% idênticos ao que você estará negociando.


A melhor maneira de desenvolver um sistema HFAT é usar dados de mercado real ao vivo. Quanto mais cedo, você muda de dados locais ou edemo para dados reais, mais tempo você economizará e mais decepções você será poupado. Um sistema HFAT nunca pode ser concluído fora da linha, com um banco de dados local ou com dados edemo simulados. Seu design deve sempre incluir uma fase significativa de negociação de papel e de dinheiro real.


Outro problema ao negociar sua conta de comércio de papel (simulado) do IB é que o usuário não conhece as regras que o Interactive Brokers usa para decidir se uma ordem deve ser executada ou não. Esses critérios de execução podem mudar sem aviso prévio. Isso impõe uma ordem artificial às suas execuções que é irreal; as condições de mercado simuladas serão diferentes das encontradas na negociação real. Você pode desenvolver um sistema de negociação que explora a maneira de processamento da IB de dar-lhe um desempenho irreal, mas esse sistema falharia na negociação real.


Além disso, seus negócios de papel não são vistos e não podem influenciar o mercado. Ao negociar dinheiro real, suas ordens poderiam estar configurando um novo alto ou um baixo, ou se você estiver negociando grandes somas, você poderia desenhar o preço para cima ou para baixo. Isso significa que, mesmo que o seu sistema seja extremamente bom na negociação simulada, isso não garante que seu sistema tenha um bom desempenho de dinheiro real.


Usar sua conta simulada para validar seu sistema nunca deve ser sua validação final antes de negociar lucros; você deve sempre incluir uma fase de avaliação de dinheiro real em seu plano de desenvolvimento. Seus primeiros negócios reais nunca devem ser ganhar dinheiro; eles devem ser planejados para validar seu sistema em condições variadas.


O comportamento do mercado é muito complexo; Esteja preparado para o inesperado e nunca salte um passo de desenvolvimento porque algo funciona muito bem. Por exemplo, você pode estar testando seu sistema usando sua conta de negociação de papel simulada do IB e ver seus lucros subir rapidamente demais, talvez ter 90% de vencedores e RARs que estão fora desse mundo. Quando isso acontece, é extremamente emocionante e divertido de assistir; É uma experiência rara que deve ser apreciada. Isso sugere que Holy-Grails é possível. Mas eles são? Tais condições comerciais favoráveis ​​podem durar algumas centenas de negócios, algumas horas, ou talvez alguns dias. Isso pode acontecer quando as condições técnicas e o comportamento do mercado são perfeitos para o seu sistema. Um fator desconhecido apenas fez com que tudo funcionasse perfeitamente. Quando você experimentar isso, você estará analisando seus gráficos, log de negociação, relatório de execução, etc., durante as próximas semanas. O fato é que talvez nunca mais aconteça, e talvez você nunca saiba o que realmente aconteceu.


Status da Ordem e Posição.


O relatório do tamanho da posição IB pode ser errático, sempre atrasado e pode incluir informações transitórias. Se você estiver negociando rápido e você usa o Tamanho da Posição IB para determinar sua próxima ação, isso será um problema. Este é especialmente o caso dos sistemas de inversão em que as capas podem ser processadas antes das compras, e pode haver muitos preenchimentos parciais. Por exemplo, se você estiver revertindo 100 ações, indo alternativamente Longo e Curto, você pode ler os tamanhos de posição de 0, 100, 200 e até 300 ações. Não baseie a ação do seu sistema exclusivamente em uma única leitura do tamanho da posição; Seus mecanismos de proteção desligarão seu sistema muitas vezes por dia. Se uma posição não é o que deveria ser em 5 consultas consecutivas (no intervalo de cotação), você pode fechar todas as posições, suspender a operação e continuar mais tarde, ou desligar o sistema e tentar novamente.


O relatório do status do pedido parece mais confiável e estável. Normalmente, não é necessário repetir as consultas do Status do Pedido.


Não abordado nesta publicação é a questão dos instantâneos no entanto, é extremamente importante para os comerciantes em tempo real entender como o IB comprime e transmite seus dados. Este tópico foi discutido em vários fóruns, para obter mais informações sobre os dados do IB em geral, leia os seguintes tópicos:


A Taxa de Mensagem Máxima IB.


IB tem um limite para a taxa máxima de mensagens (relacionadas à ordem) que você pode transmitir por segundo. A taxa de consultas não é limitada. O limite atual é de 50 mensagens por segundo. Se você exceder essa taxa, o IB produzirá um código de erro e, se continuar a exceder a taxa de mensagem, o IB suspenderá sua conexão. Isso, é claro, deve ser evitado a todo custo. As taxas de mensagens estão documentadas aqui. Como introduzir atrasos em tempo real, a medição em milissegundos é documentado na publicação em Intervalo de alta precisão e tempo de atraso.


Atrasos na Internet.


O status da ordem e da posição está sujeito a um atraso na Internet de 50-400 milissegundos. Esse atraso variará com a sua localização e o tipo de conexão com a Internet ao IB. Você pode testar esse atraso fazendo um ping no servidor IB. Para fazer isso, digite ping gw1.ibllc no comando na janela Iniciar & gt; Executar janelas (para Windows XP) e clique no botão Executar. Uma janela, como mostrado abaixo, aparecerá e mostrará os atrasos para três consultas consecutivas (pings) para IB:


If you encounter excessive delays or cannot connect at all, you can get more details about how your connection is routed by running tracert gw1.ibllc in the same manner. You may want to browse the Technical FAQ at IB for related items.


Editado por Al Venosa.


August 18, 2007.


Gap-Trading demo, Session Timing Example.


This post shows how to add intraday session timing to the Real-Time Gap-Trading (RTGT) system developed in the previous post. However, before tackling session timing, there are a few things you should be aware about:


Time-Synchronization.


In real-time trading there are many functions that are timed with reference to your system’s clock. It is therefore imperative that you always synchronize your computer clock with an Internet timeserver before each trading session.


Ferramentas - & gt; Preferências - & gt; Intraday settings.


Data Timestamps can be aligned to either the start or the end of the base period. The code developed here uses time of FIRST tick inside bar , i. e., the data timestamp returns the time at the start of the bar. This is when the first quote for the new period arrives and defines the Open for the new bar. Click Tools -> Preferences -> Intraday to set this option:


Backtesting and Bar-Replay.


During backtesting the timing resolution will be equal to the periodicity set in AA Settings. If you are comparing Backtester signals with the signals displayed on your chart, you must make sure that the AA and Chart use the same periodicity.


During Bar Replay the timing resolution will be equal to the greater of the base interval of your database or the Step Interval selected in the Bar-Replay window.


During Backtesting and Bar-Replay, AmiBroker will refer to the timestamp to know how prices change over time. Hence, you will have no choice but to time events, such as session timing, with reference to the data timestamp.


Live Trading.


When trading from an Indicator, the data timestamp is rounded to the selected chart-periodicity, i. e., if you display a 1-minute chart, the timing resolution will be one minute. This means you cannot implement delays based in seconds using the data timestamps of a minute database. This is why most functions in a real-time trading system use the computer clock as reference.


You can, with caution, use either the data timestamp or the system’s clock to control your session. However, since the data timestamp is dependent on the arrival of new quotes (ignoring data padding), using data timestamp could be unreliable. If you want higher timing resolution, you could create a 5-second database. However, this means working with slow backfills and slow AFL executions, due to lengthy data histories. To keep things simple, we will use a one-minute database.


Session Timing.


When you are developing real-time trading systems, it is often handy, even essential sometimes, to develop several code versions. Typically, these might include:


1) A version for Backtesting and Bar-Reply. This version would use the TimeNum function for timing.


2) A Real-Time trading version. This version would use the system clock (Now()) for timing and would be highly optimized for AFL execution speed.


3) A DebugView version. This is a useful intermediate development stage that lets you run your system in real-time without any TWS interfacing; it logs trades to DebugView instead of sending them to the TWS.


ParamTime() input statements are used to set the start - and end-time of the trading session. The code below is only intended for preliminary system evaluation using the Backtester: hence, is uses time-numbers for session timing.


The StartOfSession and EndOfSession variables are triggers (they last only one bar). They are used to initialize processes at the start of the session and clean up processes at the end of the session. The InSessionTime variable is True during trading and is used to control processes that must be turned On/Off depending on whether you are trading or not. These processes will be covered in future posts.


A TimeFrame Parameter has been added to help visualize how the system works in different timeframes. To see the equity for different timeframes, just drag the slider to see the system response to any timeframe from 1 minute to 1 hour. Having added Session Timing you can now explore whether this system is more profitable during certain hours of the trading day. I suggest you perform an individual backtest on you favorite watchlist; you may be surprised to find that with some systems there is no need to trade all day. Mais & # 8230;


For debugging purposes, you can turn On/Off a colored ribbon to display the Start - (Green), End - (Red) and In-Session (Yellow) variables.


For convenience the code below includes all previously developed parts. Just copy to an Indicator formula window, and click Apply.


Comments Off on Gap-Trading demo, Session Timing Example.


August 15, 2007.


Real-Time Gap-Trading Demo, Basics (v3)


This system was intended to provide signals to demo trade automation. However, its signals are not that frequent and it proved to be quite boring to automate it. The code is left here but I plan to use another system to demo trade automation. You may also note that I separated Real-Time System Design from System Automation. This was done to allow categories to evolve independent from each other.


To develop trade-automation code we need a demo system to generate signals and to test TWS interfacing. To be able to continue this series and not waste time looking for a superb system, I’ll use the following very simple trading rules:


Buy at the Open of the current bar if it falls below the previous Low.


Sell at the Close when the current Low falls below the previous Low.


Short at the Open when the Open exceeds the previous High.


Cover at the Close when the current High exceeds the previous High.


In AFL this looks like this:


The above code is a variation of The Full Gap-Trading system. You can read more about this type of system on the Stockcharts site and many other Internet sites.


This system will produce trades in all timeframes, trade frequently, and trade both long and short. Running this system in the 1-15 minute timeframe will give us lots of action and make it easier to develop and debug the Trade-Automation (TA) code. An AT trading system designed around a system that gives only a few signals a day will take forever to debug. Mechanical performance is the first objective.


For now we assume that we can enter at the bar’s Open price. Note that I exit at the Close of the bar because, in the AmiBroker database, this is the next price that is available. At this stage this system is designed to stimulate trade-automation code and not to make you rich; DO NOT TRADE IT. Order types and/or strategies will be decided on later. Trade-Delays are set to zero because they are better handled in the code. The Equity(1) statement is used to remove redundant signals. The indicator should display trades as follows:


Editado por Al Venosa.


August 12, 2007.


Designing a Tradable System – Spikes.


The phenomenon that is the basis of many trading systems is the observation and trading of an exceptional price movement followed by a pullback.


An extreme example of the pullback phenomenon would be a Spike as shown in the chart below. Because the price change is so extreme, the pullback or correction appears instantaneous. There is no clear market response, i. e., traders at large are not inclined to take the price change seriously.


The problem is that inadvertently you can easily write code that trades these spikes. Only when you start trading such a system will you discover that your orders are not filled because the volume just isn’t there. This is a common reason why backtested and real results may sometimes differ substantially. You may have designed a system that is completely rational, backtests perfectly, and stands up to the most detailed technical scrutiny, only to find out that in real trading it fails completely.


You might think that by increasing the timeframe, for example to 15-minute or even daily, you can minimize this problem. However, while doing this may make the spikes less prominent, the tradability will not improve. Consider the spike in the 15-minute chart below:


Adding a few percent bands makes this look like a real trading opportunity. It looks so easy! However, the Low of the bar is still created by a single trade and the chance to get your order filled would still be minimal. Designing trading systems around minimal-volume price changes is one of the easiest traps for a real-time system developer to fall into. When designing an intraday trading system you should design your code to minimize the divergence of the backtester with respect to real-trading results. You can do this by working in the smallest time frame possible. Even when trading at hourly intervals you should write your code in the minute (or even Tick) timeframe.


There are a number of ways in which to do this. Take a look at the 10:30 AM spike in the 15-minute chart below and consider how you would determine its tradability:


The fact is that there is no way to tell whether the 10:30 AM High is tradable. However, expanding the chart to the 1-minute timeframe, as shown below, lets you clearly see a gradual reversal pattern. This means your order could probably have been filled somewhere near the top of the 15-minute spike shown earlier.


Running your Backtester in the 1-minute timeframe and looking for one-bar confirmations may drop your backtester performance, but your results would have been closer to that which can be obtained in real trading. In this case you would have separate Backtester and Trading code versions for your system; the Backtester code would include signal confirmation while your Trading code would not.


Editado por Al Venosa.


Comments Off on Designing a Tradable System – Spikes.


July 21, 2007.


System-Design Pitfalls.


When you are designing a real-time trading system, many things can go wrong. This post is intended to alert you to some of the potential pitfalls. However, that is all it can do. Only experience can teach you how to prevent them. Be aware that even the most experienced designers will make some of these mistakes repeatedly.


Since documenting all potential pitfalls with coding examples would consume too much time and space, they are, for now, only briefly commented on. Most of them will trigger a user response of “Oh yeah, that happened to me!”. If you need a more detailed explanation you can post questions in a comment to this post.


No rules exist to prove that a trading system is free from coding or logical errors. However, two indicators are fairly reliable in suggesting you may have a problem:


1) Your profits are simply too good to be true. In this case you have no choice but to work through the code line by line, trying to find lines of code that look into the future. If that doesn’t reveal any errors, then you would have to inspect the plotted signals and trade list trade by trade.


2) Your system is very profitable trading Long but not Short, or Short buy not Long. When this happens, you may have an error in either the Long or Short parts of your code, and comparing the two sections will often reveal the problem (this only works for reversal systems). However, it could also be that your code is correct but that your trading principle is overly trend sensitive. This would almost certainly get you in trouble when the trend reverses. In this case no other cure exists than to re-think the basic system.


When designing high-frequency trading systems, i. e., those whose trade durations are in minutes, everything changes, and many traditional procedures fall apart. Internet delays, data delays, bad data (spikes), temporary system freezes (Windows sometimes has a mind of its own!), lagging status reports, TWS problems, etc., all become critical issues that will prevent you from obtaining a close match with the Backtester.


Many of these problems will only surface when you start trading real money. Hence, the final stages of developing a trading system should always involve trading real money. Here is where the Interactive Brokers account simulator (paper-trading account) may be an indispensable tool since you can test your system in real time without committing real dollars. But, since the market does not see your trades, even paper-trading results will differ from trading real money. In general, the faster you trade, the greater your real-trading results will deviate from your backtest results. You should also be aware that commissions play a much greater role on performance of high-frequency trading systems because trade profits are smaller.


No matter how you go about it, troubleshooting a complex trading system will almost always be a tedious and boring job that could keep you busy for several days or weeks. If you find that certain problems continue to resurface, they are likely related to your personal development style, and you may be able to write some code that checks for these specific problems. See the Debugging category for some ideas.


The list below, which is not exhaustive, is presented to caution you that many areas can lead to problems. Some are obvious, while others may be expanded on as needed and time allows.


& # 8211; High/Low precedence (contrary to EOD where the Backtester is unable to determine which came first, the entry/exit or the high/low, in realtime there can be no ambiguity in price precedence).


& # 8211; Data Delays (real-time data may be delayed for various reasons and time periods (Internet delays, lack of quotes, packets vs. ticks, etc.).


& # 8211; Low Liquidity (there may be no-volume trading periods).


& # 8211; Data Holes (bars with no trades).


& # 8211; Data Spikes (high spikes without volume may trigger trades).


& # 8211; Data Padding (a bar without data may be padded).


& # 8211; Premature Padding (the last bar may be a padded bar).


& # 8211; Data Accuracy (prices you receive aren’t always accurate).


& # 8211; Random Slippage (you will rarely get the expected price).


& # 8211; Breakout slippage (you will rarely get the Breakout price of your system).


& # 8211; Survivorship Bias (companies that didn’t do well and stopped trading won’t be in your database, i. e., you are working above average stocks).


& # 8211; Lucky Trades (a series of lucky trades may look like good performance).


& # 8211; Parameter Over-Optimizing (optimized parameters are rarely stable over time).


& # 8211; Design Over-Optimizing (frequent testing is like running an optimization and may be leading to false conclusions).


& # 8211; Out–of-Bound Prices (with PriceBoundChecking turned ON, AmiBroker forces the trade price within the High-Low range, this may hide pricing errors).


& # 8211; Price Rounding (prices may be rounded or truncated by the broker).


& # 8211; Wrong Use of >= and = in the same statement, only the first equal condition will ever be seen).


& # 8211; Comparing Floating Point Numbers (calculated values can have many decimal places, either round values or use the AlmostEqual()).


& # 8211; Chart Justification (make sure you are looking at the Last bar!).


& # 8211; System Mortality (no system will work forever).


& # 8211; Sharing Trading Systems (sharing systems with other traders may result in over-trading a system).


& # 8211; Being Duped by a Trend (a rallying ticker may make your system look like the HG (holy grail).


& # 8211; Tricking AmiBroker (AmiBroker has its limits; it is possible to write esoteric code that will produce wrong results).


& # 8211; Order Visibility (placing your order for every trader to see may influence the orders they place).


& # 8211; Making the Market (extreme example: if you place a MKT order during a no-trading period you will change the chart).


& # 8211; Window/Pane Execution Order (when passing variables between panes or windows do not assume that they execute in a fixed order, more).


& # 8211; Trading at the Open (order execution at the start/end of day is different from midday because of volatility and data delays).


& # 8211; IB Data Snap Shots (snapshots are only representative of prices traded).


& # 8211; Trade Delays (make sure you understand your trade delays when backtesting).


& # 8211; EOD and Intraday Gaps (There is no time interval in RT gaps).


& # 8211; Time Zones (make sure your computer and database timezones are properly set).


& # 8211; Very Short Time-Frames (prices jump and are less contiguous).


& # 8211; Setting LMT Prices (consider rounding for faster order executions).


& # 8211; 24-Hour vs. RTH (Regular Trading Hour) Backtesting (extended hours can rarely be traded like RTH due to huge bid/ask spreads and low volume).


& # 8211; Static Variables Naming (use unique names for your static variables).


& # 8211; Incorrect Computer Time (computer time offset from market time can cause real problems).


& # 8211; Look-Ahead Problems (not all look-ahead coding problems are obvious).


& # 8211; Buy/Sell Precedence in a Loop (be aware that AB and custom AFL loops enforce a Buy/Sell priority).


& # 8211; RT Candle Discrepancies (RT Candles may be different from later backfills, especially in the opening print).


& # 8211; Bars Loaded (consider bars-loaded with respect to execution speed and loops).


& # 8211; Signal lifetime (signal strength quickly decays over bars in high frequency trading).


& # 8211; SameBarExits (Sell signals may act as a qualifier for Buy signals).


& # 8211; Designing systems based on High and Low triggers (these may fill in the Backtester but not in real trading). more…


& # 8211; Using the wrong CommissionMode and/or CommissionAmount can make any system look good, or bad…


& # 8211; Using zero TradeDelays is OK if you code the delays in your system’s code, else you may be looking into the future.


Editado por Al Venosa.


Comments Off on System-Design Pitfalls.


June 19, 2007.


Introduction to Real-Time System Design.


Developing trading systems is a very personal activity, and opinions vary widely regarding what is the best approach. Most of the solutions presented here were developed by Herman van den Bergen. They may not be compatible with your personal preferences and you are encouraged to explore other alternatives more suited to your own trading style before deciding on a possible solution. To develop a Real-Time Automated Trading (RT/AT) system, you must have a trading system to automate. If you haven’t developed one yet, you may find some ideas in the Research and Exploration or Trading-Systems categories.


Modular design, readability, and simplicity of the system code are desirable to facilitate future maintenance. Posts in this category will progress through the various phases of developing a Real-Time Automated system.


Editado por Al Venosa.


Comments Off on Introduction to Real-Time System Design.


Postagens recentes.


Comentários recentes.


Richard Dale no Data Resources & # 8211; Forex Herman em solicitação de tópicos em tempo real aqui Mike B em solicitação de tópicos em tempo real aqui Tomasz Janeczko no banco de dados de estoque dos EUA (v2) brian_z na Configuração Um banco de dados personalizado e # 8211; Nasdaq.


Categorias.


Outubro de 2018 (1) setembro de 2018 (1) agosto de 2018 (1) julho de 2018 (1) abril de 2018 (2) março de 2018 (6) fevereiro de 2018 (2) janeiro de 2018 (2) fevereiro de 2009 (2) agosto de 2008 (1) Abril de 2008 (1) março de 2008 (20) fevereiro de 2008 (6) janeiro de 2008 (1) dezembro de 2007 (4) novembro de 2007 (18) outubro de 2007 (17) setembro de 2007 (17) agosto de 2007 (26) julho de 2007 (20) Junho de 2007 (17) maio de 2007 (8) abril de 2007 (16) janeiro de 2007 (1)


This site uses WordPress Page generated in 0.341 seconds.


Base de Conhecimento dos Usuários.


14 de outubro de 2018.


EOD Gap-Trading Portfolio sistema.


Adicionado em 29 de fevereiro de 2018, pontos adicionais a considerar:


1) Este sistema depende da obtenção de preenchimentos precisos ao preço aberto. Para obter esses preenchimentos, é necessário um feed de dados de atraso mínimo de qualidade e habilidades avançadas de programação para implementar a automação comercial.


2) Ao definir o preço de entrada ligeiramente abaixo do preço de abertura (tentando melhorar o desempenho), o sistema falha miseravelmente. Mesmo melhorar o preço por apenas um centavo mata o sistema. Isso sugere que a maior parte do lucro vem dos dias em que o preço do Open foi igual ao Baixo diário, ou seja, o preço subiu do Open e nunca caiu abaixo dele. Isso, é claro, é óbvio. Para confirmar isso, adicionei esta condição de teste (olha para frente) para excluir dias em que Open == Low:


Compre = Compre E NÃO O == L;


Isso mata o sistema e prova que a maior parte do lucro vem dos dias em que O == L. Para confirmar ainda isso adicionei a condição oposta:


Comprar = Comprar AND O == L;


Isso dá lucros quase infinitos e prova que a maioria dos lucros vem de dias em que o preço se move imediatamente a partir do Open e nunca retorna abaixo dele. Tentando melhorar o preço de entrada é um erro; deve-se entrar em um Stop set 1-2 ct acima do preço Open, isso eliminará os dias em que o preço cai e nunca volta. Isso melhora significativamente o desempenho.


3) Este sistema comercializa respostas / padrões de tradutores do joelho. Esses padrões geralmente são afogados por grande volume de negócios, portanto, esse sistema funciona muito melhor quando você seleciona tickers com volumes entre 500.000 e 5.000.000 ações / dia. Isso também melhora significativamente o desempenho.


A adição das duas características acima resulta em uma curva de equidade muito melhor do que a mostrada abaixo. Desculpe, não tenho tempo para documentar o acima em maior detalhe. Boa sorte!


Esta publicação descreve uma idéia de negociação muito simples apenas para Long-only que compra em uma determinada porcentagem abaixo de ontem e baixa, e sai no dia seguinte # 8217; s Open. Às vezes, pode ser difícil obter o preço aberto exato, a alta rentabilidade deste sistema torna um bom candidato para novas experiências. O sistema funciona bem com Watchlists como N100, SP500, SP1500, Russel 1000, etc. Desempenho no Russel 1000, com max. posições abertas definidas em 1, para o período de 12/10/2003 a 12/10/2018, tem essa aparência:


Algumas das outras Watchlists dão menos exposição (lucros), mas isso vem com DDs menores. As comissões foram fixadas em US $ 0,005 por ação. Nenhuma margem utilizada.


Não é utilizada classificação explícita; Os tickers são negociados com base em seu tipo alfabético na Watchlist. Isso pode parecer estranho, mas é significativo: ao reverter esse tipo, o sistema falha. Isso pode significar que, devido a problemas de varredura em tempo real, os símbolos listados no topo deste tipo podem ser negociados de forma diferente dos listados na parte inferior.


Preste atenção ao Liquidity (você pode querer negociar mais de uma posição) e slppage (A entrada é bastante livre de risco, mas as saídas podem ser problemáticas). Os DDs são significativos, mas podem ser compensados ​​com entradas e saídas negociadas em tempo real melhoradas. Ao negociar automaticamente, pode ser possível colocar ordens de entrada OCA DAY-LMT para todos os sinais e apenas esperar e ver o que preencher. Como as saídas são mais difíceis do que as entradas, você pode querer explorar outras estratégias de saída.


Os valores padrão dos parâmetros são escolhidos apenas de um chapéu. Praticamente você pode otimizá-los ou ajustá-los dinamicamente para os tickers individuais. Testei brevemente este sistema no modo Walk-Forward e os resultados foram lucrativos para todos os anos testados. Exceto pelo número de ações, os parâmetros negociados não são muito críticos. O excesso de otimização não parece um problema neste caso.


O código abaixo é muito simples e requer poucas explicações. No entanto, é importante entender que este sistema goza de uma pequena vantagem ao negociar no Open e ao calcular o TrendMA usando o mesmo preço Open. Alguns podem interpretar isso como vazamento futuro, no entanto, se você trocar este sistema em tempo real, não é. Muitas pessoas não percebem que, se você trocar no Open, você também pode usar esse preço em seus cálculos e # 8212; contanto que você os execute em tempo real & # 8212; É aqui que a AmiBroker e a tecnologia podem lhe dar uma vantagem. Se você Ref () retornar a TrendMA por uma barra, o sistema ainda é muito lucrativo, porém os DDs aumentam para algumas Listas de Verificação. Se você usa investimentos fixos, a diferença é insignificante.


O procedimento de negociação seria começar a digitalizar antes do mercado abrir e remover os tickers com preços tão remotos que não são susceptíveis de atender ao OpenThresh. Assim, você pode começar a escanear 1000 símbolos, mas muito rapidamente o número escaneado diminui para apenas uma dúzia de tickers. Quando você se aproxima das 9h30, sua varredura em tempo real será muito rápida e você poderá colocar sua ordem LMT muito próxima do Open & # 8211; você pode até mesmo melhorar o preço aberto.


Embora algumas pessoas tenham olhado o código abaixo e não encontraram nada errado, os lucros parecem bastante elevados para um sistema tão simples. Informe os erros que você pode ver.


Arquivado por Herman às 7:03 pm sob Ideas (Experimental)


Comentários desativados no sistema EOD Gap-Trading Portfolio.


1 de setembro de 2018.


Uma idéia comercial de EOD Gap de longa duração.


Essa idéia foi postada (# 161332) na lista principal do AmiBroker em 3 de julho de 2018. Houve inúmeros comentários excelentes na lista e se você está interessado em trabalhar neste sistema, você faz bem em lê-los todos antes de começar. Depois de postar, encontrei uma série de postagens na web discutindo essa idéia comercial, alguns alegaram estar negociando um sistema similar com um bom sucesso.


Eu me referi a este sistema a & # 8220; Gap Trading & # 8221; sistema, mas isso pode ser um pouco de um nome incorreto, & # 8220; Reversão média & # 8221; pode ser uma classificação melhor. Googling para isso irá obter muitos mais hits para sistemas semelhantes. Aqui estão alguns links:


Parece ser uma idéia comercial bastante amplamente discutida e eu sugiro que você faça alguns Googling por conta própria para aprender o mais recente. Como um usuário Amibroker, você possui melhores ferramentas do que a maioria dos comerciantes e você tem uma chance melhor do que a maioria de apresentar uma variação que funcione. Talvez com um pouco menos lucros, e com uma quantidade significativa de código adicional # 8212; ele ganhou & # 8217; t ser um & # 8220; quicky & # 8221; projeto :-)


Algumas pessoas comentaram que este sistema não funcionará na negociação real, enquanto eles podem estar certos, outros dizem que regimes como este trabalho. Eu não terminei o sistema e não posso reivindicar se é negociável ou não.


O sistema compra a uma determinada porcentagem abaixo de ontem & # 8217; s Low, em uma ordem LMT, e sai no mesmo dia no fim.


Arquivado por Herman às 6:53 pm sob Ideias (Experimental)


Comentários desativados em uma idéia de negociação de Long-only EOD Gap.


28 de novembro de 2007.


Retorno inverso ao sistema médio.


Arquivado por brian_z às 11:54 pm sob Ideas (Experimental)


Comentários desativados no sistema Inverse Return To Mean.


22 de outubro de 2007.


MACD Trend System.


Eu uso um pequeno critério de configuração para procurar minhas ações.


Procuro guias de histograma 4 e 1 barra para sinal de compra (eu tenho o histograma definido como vermelho para baixo e azul para cima para que eu possa ver.


MACD acima da Linha Zero.


Este sistema baseia-se no comércio de tendências. Comprar no pullback quando o mercado continuar sua tendência ascendente.


Para procurar MACD Trend setups:


1) Insira a seguinte fórmula em um gráfico.


Os estoques que atendam aos critérios serão reportados na lista de resultados.


Nota: algumas variações das regras de configuração podem definir sinais que são bastante raros e, em bancos de dados pequenos, é possível que não haja configurações em nenhum dia determinado (portanto, nenhum estoque será relatado pela verificação).


3) Clique em qualquer símbolo no painel Resultados para visualizar o gráfico, para esse símbolo, em segundo plano.


Nota: neste exemplo, foi utilizado um banco de dados de treinamento, que apenas contém dados até 5/11/2007.


Idéia comercial por protraderinc. Comentários e fórmulas de Bill & # 8211; WaveMechanic.


Arquivado por brian_z às 11:06 pm sob Ideias (Experimental)


Comentários desativados no MACD Trend System.


14 de outubro de 2007.


Sistema de negociação de 15 dias.


Arquivado por brian_z às 10:43 pm sob Ideas (Experimental)


Comments Off no 15 Day Performers Trading System.


19 de agosto de 2007.


KISS-001: Intraday Gap Trading.


Esta é a primeira de uma série de idéias de negociação KISS (mantê-lo simples, estúpido) para você brincar. Todas as ideias do sistema apresentadas aqui não são comprovadas, não finalizadas e podem conter erros. Eles são destinados a mostrar padrões possíveis para uma maior exploração. Como sempre, você é convidado a fazer comentários e / ou adicionar suas próprias idéias a esta série.


Eu prefiro os sistemas em tempo real que comercializam rápido, são automatizados e estão desprovidos de indicadores tradicionais. De preferência, eles não devem ter parâmetros otimizáveis; No entanto, eu nem sempre posso conseguir esse objetivo. Nem todos os sistemas serão "isso" simples; haverá alguns que utilizam funções de média simples ou de tipo HHV / LLV. O primeiro sistema mostrado abaixo é uma cópia do sistema de demonstração que uso para desenvolver rotinas de Automação de Comércio em outros lugares neste site.


Para ver como isso funciona, você deve fazer o Backtest em dados de 1 minuto com uma periodicidade no intervalo de 5-60 minutos. Sua primeira impressão pode ser que esses lucros são simplesmente devido a um mercado superior, no entanto, o fato de que os lucros Longos e Curtos são aproximadamente iguais sugerem que há mais. Porque 98% de todos os negócios caem entre as 9:30 da manhã e as 10:30 da manhã, esse tipo de sistema é bom se você quer trocar pouco tempo a cada dia. Isso reduz o risco em relação à exposição ao mercado e dá mais tempo para aproveitar outras atividades.


Backtesting isso na lista de vigilância NASDAQ-100 (backtests individuais, 15 min. Periodicidade) dá os lucros mostrados abaixo para o período de 1 MAR 2007 até 17 de agosto de 2007. Os nomes de Ticker são omitidos para manter o gráfico compacto; O gráfico mostra simplesmente uma barra de lucro líquido para cada ticker testado. A exposição média deste sistema é de cerca de 15%; daí, você pode negociar carteiras para aumentar os lucros e suavizar as curvas de equidade. Seja advertido que, em sua forma bruta, as retiradas são inaceitáveis ​​e que pode haver restrições de volume para muitos tickers.


Uma vez que este sistema tem pouca exposição, pode ser um candidato para escaneamento de mercado e negociação de carteira classificada. RARs seria uma indicação dos lucros máximos absolutos que poderiam ser obtidos se conseguisse aumentar a exposição a cerca de 100%. No entanto, o movimento de preços de diferentes tickers pode ser correlacionado, e os negócios de diferentes tickers podem se sobrepor. Se muitos tickers operarem ao mesmo tempo, seria difícil aumentar a exposição do sistema.


Editado por Al Venosa.


Arquivado por Herman às 1:49 pm sob Ideias (Experimental)


Comentários desativados no KISS-001: Intraday Gap Trading.


17 de agosto de 2007.


System Ideas na Internet.


Você está convidado a enviar links para ideias do sistema em comentários para esta publicação.


Arquivado por Herman às 7:46 pm sob Sistemas de Negociação.


16 de julho de 2007.


Introdução aos Sistemas de Negociação & # 8211; Prático.


Esta categoria é reservada para sistemas reais de negociação, ou seja, que você negociou em algum momento ou que consideraria negociar. Uma vez que os critérios de negociação variam de pessoa para pessoa, e como os sistemas podem funcionar ou não dependendo de como eles são negociados, será difícil fazer a seleção de contribuições aqui. Com respeito ao que é publicado aqui, mantenha uma mente aberta e considere que o autor considera o sistema negociável.


Você pode contribuir postando como autor (requer registro) ou em um comentário para esta publicação.


Arquivado por Herman às 11:14 am sob Prático (Rentável)


Comentários desativados na Introdução aos Sistemas de Negociação & # 8211; Prático.


Introdução aos Sistemas de Negociação & # 8211; Idéias.


É aqui que você pode compartilhar sistemas de negociação que são marginalmente lucrativos, ou seja, aqueles que não devem ser negociados como estão, mas que mostram potencial. Normalmente, este seria um sistema básico que é rentável, mas as experiências diminuem 50%. Tais sistemas geralmente podem ser aprimorados pela adição de paradas, metas, gerenciamento de dinheiro, técnicas de portfólio, etc. A realidade é que, embora você não tenha a experiência para fazê-lo funcionar, outra pessoa pode.


Quase todos nós encontramos idéias do sistema de comércio em livros e revistas que codificamos na AFL para avaliação. Alguns desses sistemas podem estar por muitos anos, enquanto outros são idéias novas. Depois de codificá-los, quase sempre, estamos desapontados e retiramos o sistema (trabalho!). Em vez de jogar o seu trabalho, você está convidado a publicar o sistema aqui para dar a outro desenvolvedor a chance de corrigi-lo.


Você é convidado a contribuir como autor (requer registro) ou em um comentário para esta publicação.


Arquivado por Herman às 11:04 am sob Ideas (Experimental)


Comentários desativados na Introdução aos Sistemas de Negociação & # 8211; Idéias.


Postagens recentes.


Comentários recentes.


Richard Dale no Data Resources & # 8211; Forex Herman em solicitação de tópicos em tempo real aqui Mike B em solicitação de tópicos em tempo real aqui Tomasz Janeczko no banco de dados de estoque dos EUA (v2) brian_z na Configuração Um banco de dados personalizado e # 8211; Nasdaq.


Categorias.


Outubro de 2018 (1) setembro de 2018 (1) agosto de 2018 (1) julho de 2018 (1) abril de 2018 (2) março de 2018 (6) fevereiro de 2018 (2) janeiro de 2018 (2) fevereiro de 2009 (2) agosto de 2008 (1) Abril de 2008 (1) março de 2008 (20) fevereiro de 2008 (6) janeiro de 2008 (1) dezembro de 2007 (4) novembro de 2007 (18) outubro de 2007 (17) setembro de 2007 (17) agosto de 2007 (26) julho de 2007 (20) Junho de 2007 (17) maio de 2007 (8) abril de 2007 (16) janeiro de 2007 (1)


Este site usa a página do WordPress gerada em 0.858 segundos.

Комментариев нет:

Отправить комментарий