Amibroker define opções de gráfico
- define opções nas configurações de análise automática.
Caixa de ferramentas do sistema de negociação.
campo - é uma string que define a opção a mudar. Existem as seguintes opções disponíveis: & quot; NoDefaultColumns & quot; - se configurado como Verdadeiro - a exploração não possui colunas de Ticker e Data / Time padrão & quot; InitialEquity & quot; & quot; AllowSameBarExit & quot; "ActivateStopsImmediately & quot; & quot; AllowPositionShrinking & quot; & quot; FuturesMode & quot; & quot; InterestRate & quot; & quot; MaxOpenPositions & quot; - número máximo de posições abertas de forma simétrica (negociações) no backtest / otimização de portfólio "WorstRankHeld" - o pior nível de símbolo a ser mantido no modo de rotação comercial (veja EnableRotationalTrading para mais detalhes) & quot; MinShares & quot; - o número mínimo de compartilhamentos necessários para abrir a posição no backtester / otimizador. Se você não tiver fundos suficientes para comprar isso, o comércio NÃO será inserido & quot; MinPosValue & quot; - (4.70.3 e acima) o valor mínimo em dólares necessário para abrir a posição no backtester / otimizador. Se você não tiver fundos suficientes, o comércio NÃO será inserido & quot; PriceBoundChecking & quot; - se configurado como False - desabilita a verificação e o ajuste de preços de buyprice / sellprice / coverprice / shortprice para o símbolo atual High-Low range. CommissionMode -
0 - use tabela de comissão de gerenciador de portfólio.
1 por cento do comércio.
3 - $ por ação / contrato CommissionAmount - quantidade de comissão nos modos 1..3 AccountMargin (em versões antigas era 'MarginRequirement') - requisito de margem da conta (como em configurações), 100 = sem margem ReverseSignalForcesExit - sinal de entrada reversa força saída do comércio existente (padrão = Verdadeiro) UsePrevBarEquityForPosSizing - Afete como o percentual do dimensionamento da posição patrimonial atual é realizado.
Falso (valor padrão) significa: usar a equidade atual (intradía) para realizar o dimensionamento da posição,
Verdadeiro significa: usar o patrimônio de fechamento anterior da barra para executar o dimensionamento da posição PortfolioReportMode - define o modo de relatório do backtester:
1 - log detalhado.
3 - sem saída (apenas personalizado) UseCustomBacktestProc - True / False - permite ativar / desativar o procedimento de backtest personalizado EveryBarNullCheck - permite ativar a verificação de Nulos em operações aritméticas em cada barra na matriz (por padrão, está DESLIGADO - ou seja, AmiBroker verifica se há nulos que aparecem no início da matriz e no final da matriz e, uma vez que o valor não-nulo é detectado, não assume mais buracos (nulos) no meio). Girando & quot; EveryBarNullCheck & quot; para Verdadeiro permite estender essas verificações para cada barra que é a maneira como 4.74.x e versões anteriores funcionaram.
Observe no entanto que ativá-lo dá uma enorme penalidade de desempenho (as operações aritméticas são realizadas até 4x mais lentas quando esta opção está LIGADA, então não use a menos que você realmente precise). HoldMinBars - Número - se configurado para valor> 0 - desativa a saída durante o número de barras especificado pelo usuário, mesmo que os sinais / paradas sejam gerados durante esse período EarlyExitBars - Número se definido como valor> 0 - faz com que a taxa especial de saída antecipada (resgate) é cobrado se o comércio for encerrado durante este período EarlyExitFee - define o valor% (percent) da taxa de saída antecipada HoldMinDays - Number - se definido como valor> 0 - desativa a saída durante o número especificado pelo usuário de CALENDAR DAYS (não barras), mesmo que Os sinais / paradas são gerados durante esse período, EarlyExitDays - Number, se definido como valor> 0 - faz com que a taxa especial de saída antecipada (resgate) seja cobrada se o comércio for encerrado durante o período especificado nos dias de calendário (e não nas barras). DisableRuinStop - configurado para TRUE o arranque de ruína incorporado está desativado Gerar relatório - permite suprimir / forçar a geração do relatório de backtest. Valores permitidos: 0, 1 ou 2.
Por padrão, os relatórios de backtest são gerados SOMENTE para backtests de portfólio e para backtests individuais se o relatório individual estiver ativado nas configurações. Os relatórios são desativados para otimização.
Agora, com a função SetOption (), você pode suprimir a geração de relatórios para backtests ou habilitar a geração de relatórios durante determinadas etapas de otimização, tudo a partir do nível de código.
SetOption (& quot; GenerateReport & quot ;, 0); // suprime a geração do relatório.
SetOption (& quot; GenerateReport & quot ;, 1); // geração de força do relatório completo.
SetOption (& quot; GenerateReport & quot ;, 2); // apenas o relatório de uma linha é gerado (no arquivo results. rlst) visível como linha única no Report Explorer SeparateLongShortRank - True / False.
Quando a classificação long / short separada é habilitada, o backtester mantém dois "top" e "quot; top" listas de sinais, uma para sinais longos e outra para sinais curtos. Isso garante que os candidatos longos e curtos sejam independentes, mesmo que o escore de posição não seja simétrico (por exemplo, quando os candidatos longos têm pontuações positivas muito altas, enquanto os candidatos curtos têm apenas resultados negativos fracionários). Isso contrasta com o modo padrão onde apenas o valor absoluto do placar é importante, portanto, um lado (longo / curto) pode dominar completamente a classificação se os valores de pontuação forem assimétricos.
Quando SeparateLongShortRank está ativado, na segunda fase do backtest, duas listas de classificação separadas são entrelaçadas para formar a lista de sinais finais, primeiro tendo o melhor ranking, depois o melhor classificado, depois o 2º melhor classificado, o 2º classificado superior e o 3º topo classificou-se a longo e 3º melhor classificado, e assim por diante. (desde que os sinais existam em AMBAS listas longas / curtas, se não houver mais sinais de tipo dado, então os sinais restantes de listas longas ou curtas são anexados)
Por exemplo: sinais de entrada (pontuação): ESRX = Comprar (60.93), GILD = Curto (-47.56), CELG = Comprar (57.68), MRVL = Curto (-10.75), ADBE = Comprar (34.75), VRTX = Comprar ( 15.55), SIRI = Comprar (2.79),
Como você pode ver, os sinais curtos são intercalados entre sinais longos, mesmo que seus valores absolutos de pontuação sejam menores do que as correspondentes notas de sinais longos. Também havia apenas 2 sinais curtos para essa barra particular, então, o resto da lista mostra sinais longos em ordem de pontuação de posição.
Embora este recurso possa ser usado de forma independente, destina-se a ser usado em combinação com as opções MaxOpenLong e MaxOpenShort. MaxOpenLong - limita o número de posições LONG que podem ser abertas simultaneamente MaxOpenShort - limita o número de posições SHORT que podem ser abertas simultaneamente.
O valor de ZERO (padrão) significa NO LIMIT. Se MaxOpenLong e MaxOpenShort são definidos como zero (ou não definidos de forma alguma), o backtester funciona da maneira antiga - há apenas o limite global ativo (MaxOpenPositions), independentemente do tipo de comércio.
Observe que esses limites são independentes do limite global (MaxOpenPositions). Isso significa que MaxOpenLong + MaxOpenShort pode ou não ser igual a MaxOpenPositions.
Se MaxOpenLong + MaxOpenShort for maior do que MaxOpenPositions, o número total de posições permitidas não excederá MaxOpenPositions e limites individuais longos / curtos serão aplicados também. Por exemplo, se o seu sistema MaxOpenLong estiver configurado para 7 e maxOpenShort estiver definido para 7 e MaxOpenPositions estiver definido para 10 e seu sistema gerou 20 sinais: 9 longos (mais alto) e 11 curtos, ele abrirá 7 longos e 3 shorts.
Se MaxOpenLong + MaxOpenShort for menor que MaxOpenPositions (mas maior que zero), o sistema não poderá abrir mais do que (MaxOpenLong + MaxOpenShort).
Observe também que MaxOpenLong e MaxOpenShort limitam apenas o número de posições abertas do tipo dado (longo / curto). Eles não afetam a forma como a classificação é feita. Isto é, por ranking padrão é realizado usando o valor ABSOLUTE de positioncore.
Se o seu placar de posição NÃO for simétrico, isso pode significar que você não está recebendo os sinais de classificação superior desejados de um lado. Portanto, para utilizar completamente o MaxOpenLong e o MaxOpenShort em sistemas longos / curtos balanceados ("quot; mercado neutro"), é desejável realizar uma classificação SEPARADA para sinais longos e sinais curtos.
Para habilitar o uso de classificação longa / curta separada:
SetOption (& quot; SeparateLongShortRank & quot ;, True); RefreshWhenCompleted - quando configurado para TRUE, ele executará View-> Refresh All após a operação de análise automática (scan / exploration / backtest / optimize). RequireDeclarations - quando configurado para TRUE, o mecanismo AFL sempre exigirá declarações de variáveis (usando local / global) na base fórmula por fórmula ExtraColumnsLocation - permite ao usuário alterar a localização das colunas personalizadas adicionadas durante backtest / otimização.
a) qualquer métrica personalizada adicionada usando o backtester personalizado.
b) quaisquer parâmetros de otimização definidos usando a função Optimize ().
Se as métricas personalizadas e os parâmetros de otimização estiverem presentes, as métricas personalizadas aparecem primeiro, em seguida, os parâmetros de otimização.
Esta função é fornecida para permitir que o usuário altere o padrão "no final" localização de colunas personalizadas / parâmetros de otimização.
fará com que as métricas personalizadas e as paradas de opção sejam posteriormente adicionadas a partir da coluna 1 (em oposição à última coluna padrão)
Observe que esta configuração muda & quot; visual & quot; ordem das colunas, ordem realmente não na memória ou ordem de exportação, então os arquivos de dados exportados ou o formato de cópia / pasta não mudam. SettlementDelay - esta opção descreve o número de dias (não barras) que leva para que os recursos de venda se estabeleçam e estejam disponíveis para abrir novas posições.
SetOption (& quottageDelay & quot ;, 3); // isso fará com que o produto da venda só esteja disponível para negociação no terceiro dia após a venda.
Para rastreamento detalhado " Registro detalhado A opção de relatório agora mostra fundos disponíveis e não resolvidos para T + 1, T + 2 e assim por diante.
Nota: ao usar esta opção, recomenda-se que use backtestRegularRaw em vez de backtestRegular, caso contrário, algumas negociações podem não ser inseridas porque os fundos não são resolvidos imediatamente e você deve ser capaz de entrar não nos primeiros sinais de compra subseqüentes e é exatamente o que o BacktestRegularRaw ofertas.
Note2: backtester antigo (função Equity ()) ignora o atraso da liquidação StaticVarAutoSave - permite a economia automática periódica de variáveis estáticas persistentes (além de salvar na saída, o que sempre é feito).
SetOption (& quot; StaticVarAutoSave & quot ;, 60); // auto-salvar variáveis persistentes a cada 60 segundos (1 minuto)
É importante entender que as variáveis persistentes são salvas ON EXIT automaticamente, sem qualquer intervenção do usuário, por isso deve ser suficiente para a maioria dos casos. Se você, por algum motivo, quiser salvar automaticamente quando o AmiBroker estiver sendo executado, você pode usar essa função. Observe que escrever muitas variáveis estáticas no arquivo de disco físico leva tempo e bloqueia todo o acesso variável estático, então você deve EVITAR a especificação de pequenos intervalos de economia automática. Salvar cada segundo é uma má idéia - isso causará sobrecarga. Salvar cada 60 segundos deve estar bem. A função de chamada com intervalo definido para zero desativa a gravação automática.
SetOption (& quot; StaticVarAutoSave & quot ;, 0); MCEnable - controla a simulação de Monte Carlo: 0 - desativado, 1 - habilitado em backtests, 2 - habilitado em backtests e otimizações MCRuns - número de simulações de Monte Carlo (realizações) padrão 1000 MCPosSizeMethod - Monte Carlo método do tamanho da posição: 0 - não mudança 1, tamanho fixo, 2 - valor constante, 3 por cento do capital próprio MCPosSizeShares - número de ações por negociação na simulação MC MCPosSizeValue - valor em dólar por troca na simulação MC MCPosSizePctEquity - porcentagem do patrimônio líquido atual por troca na simulação MC MCChartEquityCurves - true / falso (1/0) - permite o gráfico de equidade de Monte Carlo MCStrawBroomLines - define o número de linhas de equidade desenhadas no gráfico de vassoura de palha de Monte Carlo WarningLevel - permite alterar o nível de alerta. O nível 1 é padrão para todas as execuções AFL com exceção do editor AFL e comentário em que o nível de aviso está definido para 4.
1 - relate apenas avisos de nível 1 (502 - lotes demais)
2 - avisos de nível de relatório 1 e 2 (acima, mais atribuição dentro de condicional, divisão por zero, período de tempo de conexão prolongado)
3 - avisos de nível 1, 2 e 3 (acima, mais createobject / createstaticobject)
4- relatar todos os avisos (padrão para o editor AFL)
AVISO: se você alterar a opção em base * por símbolo *, os resultados compostos (% de lucro, por exemplo) serão DISTURADOS, pois os cálculos assumem que as OPÇÕES são constantes para todos os símbolos em uma corrida de retorno. 'HoldMinBars', 'EarlyExit. & quot; as opções são uma exceção desta regra (ou seja, pode ser definida com segurança por símbolo)
SetOption (& quot; AllowPositionShrinking & quot ;, True);
Amibroker define opções de gráfico
- definir / limpar / substituir padrões para as opções do painel de gráfico.
chartShowDates, chartLogarithmic, chartShowArrows, chartWrapTitle (4.75 ou superior), chartHideQuoteMarker (v5.06). chartHideQuoteMarker - oculta a linha do seletor de cotações em cada painel, o mesmo que o diálogo Parâmetro -> Axes & Grid -> Vert. marcador de referência: Mostrar / Ocultar, chartDisableYAxisCursor (novo em 5.80) - desativa alterar o ponteiro do mouse para a seta para cima / para baixo ao passar acima do eixo Y, chartDisableTooltips (novo em 5.80) - desativa a exibição de dicas de ferramentas (dicas de dados).
gridFlags - (para uso interno do AmiBroker - não o use em sua própria codificação, pois esse parâmetro será eventualmente removido). Os valores permitidos são: chartGridDiv100, chartGridPercent, chartGridDiv1000, chartGridMargins chartGridMiddle, chartGrid0, chartGrid30, chartGrid70, chartGrid10, chartGrid90, chartGrid50, chartGrid100 , chartGrid20, chartGrid80, chartGrid1 ymin, ymax - (novo em 5.07), esses parâmetros especificam valores mínimos e máximos do eixo Y para escalabilidade personalizada. Se você especificar quaisquer valores que atendam a condição ymin // para marcar "Mostrar setas" por padrão em um novo uso de gráfico.
SetChartOptions (0, chartShowArrows);
Exemplo 2 (funciona apenas com a versão 4.75 ou superior):
SetChartOptions (2, chartWrapTitle);
Title = "isto é uma prova de envolvimento automático do texto do título que é muito longo para caber em uma única linha, por isso esta fórmula de exemplo usa texto muito longo. Espero que você esteja gostando da amostra & quot; ;
Você pode postar um gráfico da Amibroker para negociação de opções.
Gráficos não disponíveis em tópicos / posts antigos.
Teste minha habilidade - publique qualquer gráfico e verifique minhas habilidades de tomada de decisão de compra / venda.
Publique o seu aplicativo Charting para Android.
Qualquer um pode publicar os pls da AFL deste gráfico.
Qualquer um pode postar o afl para o quadro a seguir?
Compartilhe esta página.
Por agentes de ações populares.
Rs 899 Unlimited Equity.
Rs 499 Unlimited Curr.
ou Rs 15 por Comércio.
Menor taxa de transação.
Chamada mais baixa e amp; Taxa de comércio.
Menor cargo de selo.
Operações gratuitas de entrega de capital.
Flat Rs 20 por comércio.
Investimento do Fundo Mútuo Direto.
Reembolso de corretagem de 100% se em 60 dias você obteve lucro líquido.
Iniciante, investidor experiente, comerciante ativo ou HNI. Obtenha soluções personalizadas.
Rs 0 taxa de abertura de conta na negociação on-line + Demat Acct.
Base de Conhecimento dos Usuários.
9 de fevereiro de 2011.
Coletando e Plotting Ticks v2.
O programa abaixo mostra como você pode coletar dados baseados em tiques e exibi-lo em seu próprio painel.
Nota: Ocorreu um erro na versão anterior corrigida, v2 apenas coleta os tiques se o volume total para o dia mudar. Sinta-se à vontade para reportar quaisquer outros problemas (na lista principal ou em privado, por favor).
O exemplo mostra o preço Last, Bid e Ask. Você pode repetir as quatro linhas que traçam cada preço com a frequência desejada para adicionar outros tipos de dados baseados em tiques. Um gráfico típico parece assim:
Comentários desativados na coleta e plantação de tiques v2.
18 de fevereiro de 2008.
Leitura / Backup do Relatório de Execução Exportada TWS.
Certifique-se de configurar o TWS de acordo com as instruções fornecidas em Configurar seu TWS antes de testar este código. O código apresentado aqui lê o relatório de execução, converte-o para um formato. csv, fecha-o, faz backup para posterior utilização e, opcionalmente, exibe-o no título do gráfico. O código não faz nada de importante, além de exibir as informações no Título. A idéia é mostrar como ler o arquivo para que você possa extrair os preços de execução real, usá-los nos cálculos e traçá-los no seu gráfico. As opções Param são auto-explicativas:
O nome usado para o relatório de execução gerado pelo TWS não é datado. Por exemplo, se você configurar o TWS para exportar execuções sob o nome Simulated. Trades, esse mesmo nome será usado em dias sucessivos. Se o TWS encontrar um tradelist do dia anterior, ele simplesmente substitui-lo. Para evitar a perda deste arquivo legível AFL, é importante fazer backup do tradelist no final do dia. O formato do relatório de execução exportado pelo TWS parece assim:
O formato. csv do arquivo de backup produzido pelo código abaixo pode ser importado diretamente para o Excel e parece assim (observe que os pontos e vírgulas foram substituídos por vírgulas):
No Excel, o arquivo ficará assim depois de ativar Text to columns:
Lembre-se de que o intervalo mínimo de atualização que o TWS exporta o relatório de execução é aproximadamente de um minuto. Isso significa que levará algum tempo para que seus negócios apareçam na lista.
Antes de abordar a função de backup principal, há algumas funções auxiliares que você precisará. Embora estes estejam disponíveis em outros lugares neste site, eles são repetidos abaixo para sua conveniência. Para evitar conflitos entre variáveis estáticas usadas em diferentes programas, você deve digitar seus nomes com os gráficos; consulte Keying Static Variables para obter mais informações sobre isso. O DateNumToStr () converte DateNumbers em uma cadeia de data padrão.
O TWSBackupTradeList (TWSInputPath) listado abaixo lê o tradutor de TWS, extrai a data, converte-o para o formato. csv, o salva em um local diferente e, opcionalmente, exibe ambos os tradelists no título do gráfico. Para testar esta função, aplique-a para um novo indicador, abra a janela Param, configure os parâmetros e clique em BACKUP. O arquivo de backup é salvo no caminho definido pela variável TradebackupFolder. Se a função encontrar o relatório de execução e a sua exibição estiver ativada na janela Param, isso deve se parecer com o Título (apenas algumas linhas mostradas):
E, quando exibido, o arquivo de backup deve ser o seguinte:
Editado por Al Venosa.
Comentários desativados na leitura / cópia de segurança do Relatório de Execução Exportada TWS.
Cronograma do período da barra em tempo real.
Ao negociar em tempo real, muitas vezes você precisa saber quando um novo período começa e quanto tempo falta antes do término do período. O código abaixo lhe dará o tempo restante para a próxima barra, o tempo decorrido desde o início da barra e a segunda contagem desde a mudança de data. Os valores de temporização se ajustarão automaticamente ao intervalo de gráfico selecionado. Você pode usar as variáveis no código do seu sistema para programar diversos eventos.
Este código é mostrado em uma configuração de demonstração, e você terá que adaptá-lo aos seus requisitos pessoais. Para testar, basta aplicar o código a uma janela Indicador. Para um teste rápido, selecione o intervalo de tempo de um minuto.
Para verificação, o tempo é exibido no título do gráfico:
Editado por Al Venosa.
Comentários desativados no cronograma do período de barras em tempo real.
28 de dezembro de 2007.
Cronograma do período de barras em tempo real.
Na negociação em tempo real, muitas vezes é necessário saber quando um novo período começa e quanto tempo deixa antes do término do período. O código abaixo fornece esta informação. Certifique-se de sincronizar o relógio do seu sistema.
Para o teste e o tempo de verificação do código é exibido no título do gráfico:
Comentários desativados no tempo em tempo real do período da barra.
10 de novembro de 2007.
Retardo de alta precisão e tempo de intervalo.
Antes de continuar com esta publicação, você deve ler atentamente o tópico da Ajuda do AmiBroker para o getPerformanceCounter ().
O tempo de medição é um aspecto importante de todos os sistemas de negociação intradiária em tempo real. Tarefas típicas que exigem tempo de alta resolução incluem: Limitar a taxa de mensagem para Interactive Brokers (IB) para 50 / seg (API Error 100). Inserindo pequenos atrasos antes de pesquisar o status do IB, para permitir atrasos na Internet. O portfólio de balcão (entrelaçamento) negocia para espalhar a ação. Medindo e otimizando o tempo de execução do AFL. Modificando ordens após um pequeno atraso (para garantir preenchimentos). Execução periódica de tarefas, por exemplo, varredura de lista de observação, atualização de exibição e status, cálculos baseados em variáveis de mudança lenta, etc. Eventos de carimbo de tempo, por exemplo, colocação de pedidos. Cotações de coleta / pré-processamento. Superar gráficos de vida em gráficos mais rápidos e mais fáceis de gerenciar gráficos de 1 minuto.
A maioria dessas tarefas pode ser realizada usando apenas três funções de temporização personalizadas: GetElapsedTime (): uma função que retorna o tempo decorrido desde a reinicialização. SetDelay (): Uma função que retorna o tempo restante para alcançar um tempo futuro. GetDelayTrigger (): uma função que retorna um gatilho quando um atraso expira.
Esta publicação fornece funções de exemplo em um aplicativo de demonstração. Para permitir o uso de muitos temporizadores, cada função requer que você forneça um TimerName, que será usado para recuperar as informações do temporizador. As variáveis estáticas são globais e podem ser lidas de qualquer lugar; Isso significa que você deve ter cuidado para não fazer referência cruzada aos temporizadores usando o mesmo TimerName em diferentes painéis ou janelas. Ao executar várias cópias do mesmo código, você precisará digitar TimerNames. Para saber mais sobre como fazer isso, consulte Keying Static Variables na categoria Time-Time AFL Programming.
Os temporizadores abaixo são implementados usando o getPerformanceCounter (). Esta função retorna a quantidade de tempo decorrido desde o início do computador. Tomasz explicou recentemente o seguinte: & # 8220; O contador de alta freqüência subjacente funciona o tempo todo desde o início do computador. O que & # 8216; reset & # 8217; A bandeira realmente faz é armazenar o último valor, então a próxima vez que você lê, ele fica subtraído do último valor, dando a você a diferença. Se o reset for falso, o último valor é definido como zero, e você obtém o número original de & # 8216; tiques do relógio & # 8217; desde o início do computador & # 8220 ;.
Os temporizadores nesta publicação fazem sua própria amostragem do contador de alta freqüência subjacente e o argumento getPerformanceCounter () Reset sempre é definido como False.
O getPerformanceCounter () retorna valores com resolução de microssegundo; no entanto, a precisão prática é severamente limitada por interrupções do sistema operacional do computador. Não espere muito melhor do que uma precisão absoluta de 50 milisegundos. Além de projetar seu próprio hardware comercial dedicado (para substituir o PC), não existe muita coisa que possa ser feita sobre isso. Se você é corajoso, experimente aumentar a prioridade do programa na janela do Gerenciador de Tarefas.
As atualizações de gráficos são muitas vezes iniciadas por uma cotação que chega, mas também podem ser iniciadas com cliques do mouse, dicas de ferramentas e várias operações de gráfico. Isso significa que, quando a atividade de mercado é baixa e as coisas não estão acontecendo o mais rápido que você gostaria, você pode forçar execuções extra de AFL clicando em seu gráfico. Você pode verificar isso executando o código abaixo e, ao clicar rapidamente no gráfico, observe que as contagens do temporizador exibidas serão atualizadas com mais rapidez.
Você pode garantir uma atualização de gráfico de um segundo, adicionando um RequestTimedRefresh (1) ao seu código. Se a frequência dos dados que chegam é lenta, o seu código AFL pode ser executado de forma esporádica. Como o seu código deve ser executado para ler seus temporizadores, a resolução dos seus temporizadores será limitada pela taxa de atualização do gráfico. Se o seu gráfico atualizar uma vez por segundo, a resolução do tempo será de um segundo!
Normalmente, a maior parte do código AFL em uma janela Indicator é executada quando seu gráfico é atualizado; no entanto, para obter vantagens de velocidade, você pode executar seções não críticas (como informações da conta e Status do sistema) do seu código menos freqüentemente usando um temporizador. Você também pode executar pequenas seções de código com mais freqüência, colocando-os dentro de um loop bem controlado. Se você fizer isso, certifique-se de limitar o tempo máximo que seu código pode gastar dentro do loop para um segundo ou menos.
Para sistemas de negociação rápidos, a frequência das execuções AFL (atualizações de gráfico) pode ser lenta e isso pode dificultar a obtenção de preenchimentos LMT. Não há como ter um programa que requer 50 milissegundos por passe para executar 20 vezes por segundo.
Considerando o intervalo entre as execuções AFL, é importante planejar o layout do seu código para que todos os eventos sejam tratados na ordem mais eficiente. Se você não for, a transmissão do seu pedido pode ser atrasada até um segundo completo. Há situações em que você deseja invocar uma re-execução imediata do seu código. Em alguns casos, você pode querer fazer isso depois de fazer um pedido para verificar o status do pedido antes da próxima cotação ou atualizar. Embora seja usado com moderação, isso é possível ao chamar RefreshAll ():
Editado por Al Venosa.
Comentários desativados em atraso de alta precisão e tempo de intervalo.
16 de outubro de 2007.
Exploração do preenchimento para dados em tempo real.
Os dados de preenchimento podem ser feitos de várias maneiras, e diferentes métodos podem ser necessários para diferentes provedores de dados. O método mostrado abaixo foi desenvolvido para dados eSignal. Se você usar outro provedor de dados, talvez seja necessário modificar o código e o procedimento.
Ao preencher os dados, você deve confirmar que os dados são preenchidos corretamente e ter alguma indicação sobre a presença de furos de dados. Conforme apontado em Data Holes em Real-Time Trading, para poder detectar buracos, você precisa de uma matriz de dados perfeita para comparar os dados. Uma vez que a AmiBroker não possui uma matriz de dados, o método apresentado aqui usa o QQQQ como um ticker de referência. Ligue e defina Configurações do Backtester - & gt; Geral - & gt; Alinhe e alinhe todos os dados ao símbolo de referência - & gt; QQQQ. Para que todos os tickers sejam preenchidos, você também deve ativar a espera de preenchimento (apenas RT). Para acelerar os preenchimentos em tempo real, você pode querer exibir apenas um gráfico de preços simples, em vez de um código complexo. Refrescantes indicadores ou sistemas complexos retardarão o preenchimento. A seguinte Exploração irá preencher todos os tickers em sua Watchlist e reportar sobre o sucesso de # 8217;
11 de outubro de 2007.
Mantendo Seu Gráfico Justamente Justificado.
Na negociação em tempo real, é vital manter seu gráfico corretamente justificado, ou seja, garantir que a barra de preço mais à direita seja visível o tempo todo. Não fazer isso e olhar para a barra errada ao negociar dinheiro real pode invocar uma resposta de pânico pelo comerciante que resulta em fechar erroneamente uma posição ou pior, colocando uma ordem errada. Isso pode acontecer facilmente se você estiver executando vários computadores e nem sempre estiver monitorando o gráfico que está sendo negociado.
O código a seguir mostra como você pode justificar corretamente seu gráfico na inicialização do sistema ou na janela Param. É incluído um alerta visível que altera a cor do fundo do gráfico quando a última barra não está visível.
O alarme usa DateTime () para corrigir automaticamente as barras em branco na borda direita do seu gráfico. O código é mantido explícito e você poderá otimizar a velocidade.
Editado por Al Venosa.
Comentários desativados em manter seu gráfico justificado pela direita.
23 de setembro de 2007.
Medição dos tempos de execução AFL (v3)
Quando seu código aumenta em complexidade, ele começará a executar mais devagar, e você chegará a um ponto em que você deseja otimizar seu código para a velocidade de execução. Mesmo se você estiver disposto a comprar um computador mais rápido, raramente lhe dará uma maior vantagem de velocidade do que otimizar seu código.
Nota importante: O beta AmiBroker 5.01.1 lançado em 5/10/2007 oferece uma nova função de perfil que permite que você obtenha um tempo de desempenho preciso para todas as funções personalizadas do AmiBroker. Está disponível a partir do Editor AFL: Ferramentas -> Menu de verificação de código e perfil. Para usar esta nova ferramenta efetivamente, você deve converter seus módulos de código para chamadas de função, tanto quanto possível. Tente!
O primeiro requisito para analisar sua velocidade de execução do AFL é a capacidade de medir os tempos de execução. Isso é melhor feito usando o GetPerformanceCounter (), que dá a resolução de microssegundos. Você pode exibir o tempo de execução no título do gráfico ou registrá-los no DebugView. Para obter uma apreciação da rapidez com que a AFL executa, você pode querer aguardar algumas das suas declarações AFL mais usadas. Como Tomasz apontou em seu comentário para uma versão anterior desta postagem, isso pode ser feito usando um loop simples:
O resultado produzido no DebugView parece assim:
A saída no título parece assim:
A primeira leitura no Título deve ser ignorada à medida que inicializa o PerformanceCounter. Esta leitura é suprimida pelo comando DBViewClear no log DebugView. O método acima pode ser usado para determinar os tempos de execução de todas as funções AFL. Observe que no exemplo acima SetBarsRequired () é usado para processar todos os dados disponíveis. Esta seria a medida do pior caso. Comentando SetBarsRequired () fará seu código executar em Quick-AFL. Isso pode ser significativamente mais rápido do que executar todos os dados.
Ordem e tempo de execução de medição para painéis de janelas.
Quando você está executando fórmulas AFL em vários painéis ou janelas e experimenta um problema de temporização, o primeiro passo a seguir, antes de usar o método acima, é determinar qual painel usa muito tempo. Você pode ativar Ferramentas -> Preferências -> Miscelânea -> Exibir Cronograma do gráfico para ler o tempo de execução na parte inferior dos gráficos. Alternativamente, o código simples abaixo permite que você registre a ordem de execução e a hora das fórmulas em cada painel aberto para DebugView. Uma vez que a leitura do contador de desempenho AmiBroker é única para cada painel, o código abaixo não o usa. Neste caso, você terá que ativar Opções -> Mostrar milissegundos no DebugView. Isso lhe dará resolução de milissegundos, não micro-segundo, como com o contador de desempenho e é uma medida muito aproximada. Ele só deve ser usado para identificar a fórmula do problema. A ordem de execução dos painéis é revelada pela ordem em que as linhas aparecem no DebugView.
A atribuição Filename eo TraceChartID () devem ser colocados no topo do seu código, ou você pode adicioná-lo ao arquivo de inclusão padrão. A única linha usada para chamar essa função deve ser colocada no início e no fim do código em cada janela / painel. Isso é o que parece em DebugView:
Editado por Al Venosa.
21 de julho de 2007.
Atrasos em tempo real.
No mercado em tempo real, muitas situações surgem quando você quer atrasar a ação até que um critério específico seja cumprido. No AmiBroker, você pode basear seus atrasos de várias maneiras diferentes, sendo o único requisito que a variável de atraso aumenta ou diminui. Se a variável selecionada não voltar para o seu valor de tempo limite (destino), sua função de atraso nunca expirará. Neste caso, você teria que adicionar um código para lidar com essa condição. Algumas variáveis que você pode usar são:
& # 8211; Segundos decorridos (redrawaction).
& # 8211; Símbolo de tempo de dados em tempo real (TimeNum ()).
& # 8211; Volume (Mudança no volume).
& # 8211; Mudança de preço (Mudança de preço).
& # 8211; Atualização do gráfico (qualquer execução AFL).
Qual das variáveis acima que você usaria para o seu atraso depende dos requisitos do seu sistema de negociação. Pode haver momentos em que talvez seja necessário combinar vários métodos para obter os resultados necessários. Por exemplo, se um atraso fosse baseado no data-timestamp, pode não ser um tempo limite durante um período de abandono de dados ou um período sem negociação. Neste caso, você precisa fazer backup de seu atraso de data-timestamp com um atraso em tempo real (segundos).
Os atrasos desempenham um papel crítico no design do sistema em tempo real. Por exemplo, em sistemas em tempo real, os sinais podem ter uma vida curta. O sinal é mais forte quando desencadeia e que rapidamente decaça até que, talvez depois de algumas barras, tenha perdido toda importância. Deixar o preenchimento da ordem no momento em que perdeu significância é o jogo puro. Para evitar isso, você pode cancelar a ordem após um atraso, ou diminuir o tamanho da posição proporcional à deterioração percebida na força do sinal (talvez com base em barras decorrentes?)
Uma vez que em um sistema em tempo real, o lapso de tempo entre as execuções da AFL pode ser significativo, você deve colocar seus cálculos de preço LMT antes do código de pedido. Cálculo do preço LMT depois que o pedido foi colocado pós o posicionamento da ordem até a próxima execução AFL ocorrer, ou seja, quando a próxima consulta chegar; até então, o preço provavelmente mudou. Especialmente durante períodos de baixo volume, isso pode ser significativo. Quando esses atrasos seriam insignificantes nos sistemas EOD, eles poderiam fazer ou quebrar seu sistema em sistemas rápidos de negociação.
To ensure frequent AFL execution in the absence of quotes, you can place a RequestTimedRefresh(1) statement at the top of your code, where the variable ‘1’ refers to a 1-second refresh. This guarantees an AFL execution at least once per second.
If your code is lengthy and takes a significant amount of time to execute, you may have to check order status at several places in your code. If changed status demands immediate action, you can force an immediate AFL execution by calling the following function:
July 14, 2007.
Preventing Repeat Orders and Whipsaws.
When you are developing a Real-Time trading system, often the first problem you have to solve is to prevent repeat orders. Repeat orders can occur when a signal remains true over several bars or chart refreshes, and each new bar/refresh sends out a new order. This can result in unintentional pyramiding.
Another ordering problem can occur when your entry and exit prices are too close together with respect to price volatility. In this case, the price volatility can whipsaw you in and out of positions in rapid succession. When this happens, slippage and commissions will quickly erode any profits you may have had. Also, if your system cannot keep up with each signal, you may end up in an opposing trade.
A common mistake when attempting to prevent repeat orders is to wait for order confirmation from the TWS after each partial fill. The problem here is that confirmations from the TWS are always subject to significant delay, and they will often let several repeat orders slip through before the acknowledgment is received.
Another flawed method is to filter or smooth the price arrays. Although this may prevent repeat orders, the lag introduced by this technique will kill most systems.
There is no single best way to prevent repeat orders. Your solution will depend on your personal preferences and the principle of your trading system. Under certain conditions you may want to combine several of the methods shown below. The examples presented here are intended to make you aware of the problems involved and suggest some possible solutions. It is your responsibility to modify the code to suit your particular system’s requirements.
To test the demo codes below, you will need to have the TWS running and connected to the IB eDemo or your paper trading account. To keep the programs below as simple as possible, you have to reset the programs after changing the Transmit ParamToggle from Off to On.
Using OrderIDs to prevent repeat orders.
When your program calls the PlaceOrder() or ModifyOrder() function, the IBc returns a unique OrderID. The OrderID uniquely identifies the order you placed so that you can refer to it later to modify, cancel, or check order status. The OrderID only acknowledges that the order was placed; it does not mean that the order was transmitted to the market or was filled.
If an OrderID has been received, this means that the order was placed. You can prevent order repeats by checking whether the OrderID has a value. Then, if you only place orders when the OrderID is empty, you cannot place repeat orders. The first example below lets you explore this procedure.
After an order has been filled or cancelled, you may eventually want to transmit a new order. In this case, you will have to define a rule for clearing the OrderID. This rule can be based on order status, a contrary signal, a time delay, the start of a new bar, or any number of things. Note that after you have cleared an OrderID, you can no longer modify or cancel the order it referred to. Hence, you should only clear an OrderID if you are sure that the OrderID is no longer needed, i. e., the order was confirmed cancelled, filled, or rejected.
The method below demonstrates how to use the OrderID, and because it still allows you to enter and exit (whipsaw) a position within milliseconds, it is only a first step to preventing repeats and whipsaws. To run this demo, Insert the code into a chart pane. When you open the Param window you will see these options:
The Chart Title shows IBc connection, OrderID, and Position status. Note that while Interactive Brokers calls all the messages ‘error’ messages, many are just harmless notifications. For more details on these error messages see API Error Messages.
When you click the Buy button, the Title will display the OrderID for the order placed, Order Status, and the position size if the order was filled. If you watch closely when you place an order, you may see order status change, for example from PreSubmitted to Filled :
In this demo you clear the OrderIDs manually. In a real system it would be cleared when your system is ready to allow the next order to go out.
Clearing OrderIDs at the Start of a New Bar.
In this example the OrderIDs are automatically cleared at the start of a new bar. This limits each type of trade (Buy, Sell, short, or Cover) to one per bar. If you want to place a new order while an order is pending, you may either cancel it first or modify the pending order.
Since the start of a new bar can only be detected when its first quote arrives, it is impossible to get a fill at this time. The earliest time an order can be filled is on the second quote of the bar. How long this takes depends on market volume and whether you use eSignal (trades) or IB data (snapshots). Since the Opening quote can occur at any time during the bar interval, it may take from zero to the full bar interval before the OrderIDs are cleared. To prevent this delay, you can clear the orders with reference to your system’s clock. However, this requires that your system is perfectly synchronized with the market-time (see next example).
The best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next, open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
The chart background will flash Green when a Buy order is placed, Red when a Sell order is placed, and White when a NewBar is started. You can test blocking of repeat orders by manually placing orders in rapid succession. The example code below will only place one Buy and/or Sell order during each bar-period (between White flashes). This method does allow you to take quick profits when both your entry and exit price are hit within one bar period. However you can do this only once per bar.
Clearing OrderIDs after a Delay.
This example maintains a delay between same-type orders. It uses a delay-timer for each type of trade and clears the OrderIDs when the delay times out.
If you set the delay to the bar-interval and if your system clock were synchronized with the market , then this method would give similar results to the NewBar method discussed earlier. However, this method is better since it enables you to place your LMT orders before the Open of the bar, thus giving you a one-quote timing advantage. This may not sound like much, but in fast trading, especially during moderate trading volume, this improves your chances of getting LMT fills.
Again, the best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next, open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
Experiment with the parameter options and observe that you cannot place a same-type order before the delay has timed out (see Chart Title).
If your system trades LMT orders, you can design your orders to alternate between Long and Short without any limitations.
This method is well suited for reversal systems and high speed trading.
If your limit prices are set properly, this method will allow a fast sequence of reversal trades that can be very profitable. Systems like this may make several trades per minute, sometimes for several minutes, during high volatility.
In the following example, Order Status is checked, and an opposite order is only allowed to pass if the previous order has been filled. Note that this demo does not work if the Transmit ParamToggle is turned Off because under that condition no orders are transmitted to the market and can thus never be filled.
Again, the best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
Editado por Al Venosa.
Comments Off on Preventing Repeat Orders and Whipsaws.
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 2011 (1) setembro de 2011 (1) agosto de 2011 (1) julho de 2011 (1) abril de 2011 (2) março de 2011 (6) fevereiro de 2011 (2) janeiro de 2011 (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.357 seconds.
- definir / limpar / substituir padrões para as opções do painel de gráfico.
chartShowDates, chartLogarithmic, chartShowArrows, chartWrapTitle (4.75 ou superior), chartHideQuoteMarker (v5.06). chartHideQuoteMarker - oculta a linha do seletor de cotações em cada painel, o mesmo que o diálogo Parâmetro -> Axes & Grid -> Vert. marcador de referência: Mostrar / Ocultar, chartDisableYAxisCursor (novo em 5.80) - desativa alterar o ponteiro do mouse para a seta para cima / para baixo ao passar acima do eixo Y, chartDisableTooltips (novo em 5.80) - desativa a exibição de dicas de ferramentas (dicas de dados).
gridFlags - (para uso interno do AmiBroker - não o use em sua própria codificação, pois esse parâmetro será eventualmente removido). Os valores permitidos são: chartGridDiv100, chartGridPercent, chartGridDiv1000, chartGridMargins chartGridMiddle, chartGrid0, chartGrid30, chartGrid70, chartGrid10, chartGrid90, chartGrid50, chartGrid100 , chartGrid20, chartGrid80, chartGrid1 ymin, ymax - (novo em 5.07), esses parâmetros especificam valores mínimos e máximos do eixo Y para escalabilidade personalizada. Se você especificar quaisquer valores que atendam a condição ymin // para marcar "Mostrar setas" por padrão em um novo uso de gráfico.
SetChartOptions (0, chartShowArrows);
Exemplo 2 (funciona apenas com a versão 4.75 ou superior):
SetChartOptions (2, chartWrapTitle);
Title = "isto é uma prova de envolvimento automático do texto do título que é muito longo para caber em uma única linha, por isso esta fórmula de exemplo usa texto muito longo. Espero que você esteja gostando da amostra & quot; ;
Você pode postar um gráfico da Amibroker para negociação de opções.
Gráficos não disponíveis em tópicos / posts antigos.
Teste minha habilidade - publique qualquer gráfico e verifique minhas habilidades de tomada de decisão de compra / venda.
Publique o seu aplicativo Charting para Android.
Qualquer um pode publicar os pls da AFL deste gráfico.
Qualquer um pode postar o afl para o quadro a seguir?
Compartilhe esta página.
Por agentes de ações populares.
Rs 899 Unlimited Equity.
Rs 499 Unlimited Curr.
ou Rs 15 por Comércio.
Menor taxa de transação.
Chamada mais baixa e amp; Taxa de comércio.
Menor cargo de selo.
Operações gratuitas de entrega de capital.
Flat Rs 20 por comércio.
Investimento do Fundo Mútuo Direto.
Reembolso de corretagem de 100% se em 60 dias você obteve lucro líquido.
Iniciante, investidor experiente, comerciante ativo ou HNI. Obtenha soluções personalizadas.
Rs 0 taxa de abertura de conta na negociação on-line + Demat Acct.
Base de Conhecimento dos Usuários.
9 de fevereiro de 2011.
Coletando e Plotting Ticks v2.
O programa abaixo mostra como você pode coletar dados baseados em tiques e exibi-lo em seu próprio painel.
Nota: Ocorreu um erro na versão anterior corrigida, v2 apenas coleta os tiques se o volume total para o dia mudar. Sinta-se à vontade para reportar quaisquer outros problemas (na lista principal ou em privado, por favor).
O exemplo mostra o preço Last, Bid e Ask. Você pode repetir as quatro linhas que traçam cada preço com a frequência desejada para adicionar outros tipos de dados baseados em tiques. Um gráfico típico parece assim:
Comentários desativados na coleta e plantação de tiques v2.
18 de fevereiro de 2008.
Leitura / Backup do Relatório de Execução Exportada TWS.
Certifique-se de configurar o TWS de acordo com as instruções fornecidas em Configurar seu TWS antes de testar este código. O código apresentado aqui lê o relatório de execução, converte-o para um formato. csv, fecha-o, faz backup para posterior utilização e, opcionalmente, exibe-o no título do gráfico. O código não faz nada de importante, além de exibir as informações no Título. A idéia é mostrar como ler o arquivo para que você possa extrair os preços de execução real, usá-los nos cálculos e traçá-los no seu gráfico. As opções Param são auto-explicativas:
O nome usado para o relatório de execução gerado pelo TWS não é datado. Por exemplo, se você configurar o TWS para exportar execuções sob o nome Simulated. Trades, esse mesmo nome será usado em dias sucessivos. Se o TWS encontrar um tradelist do dia anterior, ele simplesmente substitui-lo. Para evitar a perda deste arquivo legível AFL, é importante fazer backup do tradelist no final do dia. O formato do relatório de execução exportado pelo TWS parece assim:
O formato. csv do arquivo de backup produzido pelo código abaixo pode ser importado diretamente para o Excel e parece assim (observe que os pontos e vírgulas foram substituídos por vírgulas):
No Excel, o arquivo ficará assim depois de ativar Text to columns:
Lembre-se de que o intervalo mínimo de atualização que o TWS exporta o relatório de execução é aproximadamente de um minuto. Isso significa que levará algum tempo para que seus negócios apareçam na lista.
Antes de abordar a função de backup principal, há algumas funções auxiliares que você precisará. Embora estes estejam disponíveis em outros lugares neste site, eles são repetidos abaixo para sua conveniência. Para evitar conflitos entre variáveis estáticas usadas em diferentes programas, você deve digitar seus nomes com os gráficos; consulte Keying Static Variables para obter mais informações sobre isso. O DateNumToStr () converte DateNumbers em uma cadeia de data padrão.
O TWSBackupTradeList (TWSInputPath) listado abaixo lê o tradutor de TWS, extrai a data, converte-o para o formato. csv, o salva em um local diferente e, opcionalmente, exibe ambos os tradelists no título do gráfico. Para testar esta função, aplique-a para um novo indicador, abra a janela Param, configure os parâmetros e clique em BACKUP. O arquivo de backup é salvo no caminho definido pela variável TradebackupFolder. Se a função encontrar o relatório de execução e a sua exibição estiver ativada na janela Param, isso deve se parecer com o Título (apenas algumas linhas mostradas):
E, quando exibido, o arquivo de backup deve ser o seguinte:
Editado por Al Venosa.
Comentários desativados na leitura / cópia de segurança do Relatório de Execução Exportada TWS.
Cronograma do período da barra em tempo real.
Ao negociar em tempo real, muitas vezes você precisa saber quando um novo período começa e quanto tempo falta antes do término do período. O código abaixo lhe dará o tempo restante para a próxima barra, o tempo decorrido desde o início da barra e a segunda contagem desde a mudança de data. Os valores de temporização se ajustarão automaticamente ao intervalo de gráfico selecionado. Você pode usar as variáveis no código do seu sistema para programar diversos eventos.
Este código é mostrado em uma configuração de demonstração, e você terá que adaptá-lo aos seus requisitos pessoais. Para testar, basta aplicar o código a uma janela Indicador. Para um teste rápido, selecione o intervalo de tempo de um minuto.
Para verificação, o tempo é exibido no título do gráfico:
Editado por Al Venosa.
Comentários desativados no cronograma do período de barras em tempo real.
28 de dezembro de 2007.
Cronograma do período de barras em tempo real.
Na negociação em tempo real, muitas vezes é necessário saber quando um novo período começa e quanto tempo deixa antes do término do período. O código abaixo fornece esta informação. Certifique-se de sincronizar o relógio do seu sistema.
Para o teste e o tempo de verificação do código é exibido no título do gráfico:
Comentários desativados no tempo em tempo real do período da barra.
10 de novembro de 2007.
Retardo de alta precisão e tempo de intervalo.
Antes de continuar com esta publicação, você deve ler atentamente o tópico da Ajuda do AmiBroker para o getPerformanceCounter ().
O tempo de medição é um aspecto importante de todos os sistemas de negociação intradiária em tempo real. Tarefas típicas que exigem tempo de alta resolução incluem: Limitar a taxa de mensagem para Interactive Brokers (IB) para 50 / seg (API Error 100). Inserindo pequenos atrasos antes de pesquisar o status do IB, para permitir atrasos na Internet. O portfólio de balcão (entrelaçamento) negocia para espalhar a ação. Medindo e otimizando o tempo de execução do AFL. Modificando ordens após um pequeno atraso (para garantir preenchimentos). Execução periódica de tarefas, por exemplo, varredura de lista de observação, atualização de exibição e status, cálculos baseados em variáveis de mudança lenta, etc. Eventos de carimbo de tempo, por exemplo, colocação de pedidos. Cotações de coleta / pré-processamento. Superar gráficos de vida em gráficos mais rápidos e mais fáceis de gerenciar gráficos de 1 minuto.
A maioria dessas tarefas pode ser realizada usando apenas três funções de temporização personalizadas: GetElapsedTime (): uma função que retorna o tempo decorrido desde a reinicialização. SetDelay (): Uma função que retorna o tempo restante para alcançar um tempo futuro. GetDelayTrigger (): uma função que retorna um gatilho quando um atraso expira.
Esta publicação fornece funções de exemplo em um aplicativo de demonstração. Para permitir o uso de muitos temporizadores, cada função requer que você forneça um TimerName, que será usado para recuperar as informações do temporizador. As variáveis estáticas são globais e podem ser lidas de qualquer lugar; Isso significa que você deve ter cuidado para não fazer referência cruzada aos temporizadores usando o mesmo TimerName em diferentes painéis ou janelas. Ao executar várias cópias do mesmo código, você precisará digitar TimerNames. Para saber mais sobre como fazer isso, consulte Keying Static Variables na categoria Time-Time AFL Programming.
Os temporizadores abaixo são implementados usando o getPerformanceCounter (). Esta função retorna a quantidade de tempo decorrido desde o início do computador. Tomasz explicou recentemente o seguinte: & # 8220; O contador de alta freqüência subjacente funciona o tempo todo desde o início do computador. O que & # 8216; reset & # 8217; A bandeira realmente faz é armazenar o último valor, então a próxima vez que você lê, ele fica subtraído do último valor, dando a você a diferença. Se o reset for falso, o último valor é definido como zero, e você obtém o número original de & # 8216; tiques do relógio & # 8217; desde o início do computador & # 8220 ;.
Os temporizadores nesta publicação fazem sua própria amostragem do contador de alta freqüência subjacente e o argumento getPerformanceCounter () Reset sempre é definido como False.
O getPerformanceCounter () retorna valores com resolução de microssegundo; no entanto, a precisão prática é severamente limitada por interrupções do sistema operacional do computador. Não espere muito melhor do que uma precisão absoluta de 50 milisegundos. Além de projetar seu próprio hardware comercial dedicado (para substituir o PC), não existe muita coisa que possa ser feita sobre isso. Se você é corajoso, experimente aumentar a prioridade do programa na janela do Gerenciador de Tarefas.
As atualizações de gráficos são muitas vezes iniciadas por uma cotação que chega, mas também podem ser iniciadas com cliques do mouse, dicas de ferramentas e várias operações de gráfico. Isso significa que, quando a atividade de mercado é baixa e as coisas não estão acontecendo o mais rápido que você gostaria, você pode forçar execuções extra de AFL clicando em seu gráfico. Você pode verificar isso executando o código abaixo e, ao clicar rapidamente no gráfico, observe que as contagens do temporizador exibidas serão atualizadas com mais rapidez.
Você pode garantir uma atualização de gráfico de um segundo, adicionando um RequestTimedRefresh (1) ao seu código. Se a frequência dos dados que chegam é lenta, o seu código AFL pode ser executado de forma esporádica. Como o seu código deve ser executado para ler seus temporizadores, a resolução dos seus temporizadores será limitada pela taxa de atualização do gráfico. Se o seu gráfico atualizar uma vez por segundo, a resolução do tempo será de um segundo!
Normalmente, a maior parte do código AFL em uma janela Indicator é executada quando seu gráfico é atualizado; no entanto, para obter vantagens de velocidade, você pode executar seções não críticas (como informações da conta e Status do sistema) do seu código menos freqüentemente usando um temporizador. Você também pode executar pequenas seções de código com mais freqüência, colocando-os dentro de um loop bem controlado. Se você fizer isso, certifique-se de limitar o tempo máximo que seu código pode gastar dentro do loop para um segundo ou menos.
Para sistemas de negociação rápidos, a frequência das execuções AFL (atualizações de gráfico) pode ser lenta e isso pode dificultar a obtenção de preenchimentos LMT. Não há como ter um programa que requer 50 milissegundos por passe para executar 20 vezes por segundo.
Considerando o intervalo entre as execuções AFL, é importante planejar o layout do seu código para que todos os eventos sejam tratados na ordem mais eficiente. Se você não for, a transmissão do seu pedido pode ser atrasada até um segundo completo. Há situações em que você deseja invocar uma re-execução imediata do seu código. Em alguns casos, você pode querer fazer isso depois de fazer um pedido para verificar o status do pedido antes da próxima cotação ou atualizar. Embora seja usado com moderação, isso é possível ao chamar RefreshAll ():
Editado por Al Venosa.
Comentários desativados em atraso de alta precisão e tempo de intervalo.
16 de outubro de 2007.
Exploração do preenchimento para dados em tempo real.
Os dados de preenchimento podem ser feitos de várias maneiras, e diferentes métodos podem ser necessários para diferentes provedores de dados. O método mostrado abaixo foi desenvolvido para dados eSignal. Se você usar outro provedor de dados, talvez seja necessário modificar o código e o procedimento.
Ao preencher os dados, você deve confirmar que os dados são preenchidos corretamente e ter alguma indicação sobre a presença de furos de dados. Conforme apontado em Data Holes em Real-Time Trading, para poder detectar buracos, você precisa de uma matriz de dados perfeita para comparar os dados. Uma vez que a AmiBroker não possui uma matriz de dados, o método apresentado aqui usa o QQQQ como um ticker de referência. Ligue e defina Configurações do Backtester - & gt; Geral - & gt; Alinhe e alinhe todos os dados ao símbolo de referência - & gt; QQQQ. Para que todos os tickers sejam preenchidos, você também deve ativar a espera de preenchimento (apenas RT). Para acelerar os preenchimentos em tempo real, você pode querer exibir apenas um gráfico de preços simples, em vez de um código complexo. Refrescantes indicadores ou sistemas complexos retardarão o preenchimento. A seguinte Exploração irá preencher todos os tickers em sua Watchlist e reportar sobre o sucesso de # 8217;
11 de outubro de 2007.
Mantendo Seu Gráfico Justamente Justificado.
Na negociação em tempo real, é vital manter seu gráfico corretamente justificado, ou seja, garantir que a barra de preço mais à direita seja visível o tempo todo. Não fazer isso e olhar para a barra errada ao negociar dinheiro real pode invocar uma resposta de pânico pelo comerciante que resulta em fechar erroneamente uma posição ou pior, colocando uma ordem errada. Isso pode acontecer facilmente se você estiver executando vários computadores e nem sempre estiver monitorando o gráfico que está sendo negociado.
O código a seguir mostra como você pode justificar corretamente seu gráfico na inicialização do sistema ou na janela Param. É incluído um alerta visível que altera a cor do fundo do gráfico quando a última barra não está visível.
O alarme usa DateTime () para corrigir automaticamente as barras em branco na borda direita do seu gráfico. O código é mantido explícito e você poderá otimizar a velocidade.
Editado por Al Venosa.
Comentários desativados em manter seu gráfico justificado pela direita.
23 de setembro de 2007.
Medição dos tempos de execução AFL (v3)
Quando seu código aumenta em complexidade, ele começará a executar mais devagar, e você chegará a um ponto em que você deseja otimizar seu código para a velocidade de execução. Mesmo se você estiver disposto a comprar um computador mais rápido, raramente lhe dará uma maior vantagem de velocidade do que otimizar seu código.
Nota importante: O beta AmiBroker 5.01.1 lançado em 5/10/2007 oferece uma nova função de perfil que permite que você obtenha um tempo de desempenho preciso para todas as funções personalizadas do AmiBroker. Está disponível a partir do Editor AFL: Ferramentas -> Menu de verificação de código e perfil. Para usar esta nova ferramenta efetivamente, você deve converter seus módulos de código para chamadas de função, tanto quanto possível. Tente!
O primeiro requisito para analisar sua velocidade de execução do AFL é a capacidade de medir os tempos de execução. Isso é melhor feito usando o GetPerformanceCounter (), que dá a resolução de microssegundos. Você pode exibir o tempo de execução no título do gráfico ou registrá-los no DebugView. Para obter uma apreciação da rapidez com que a AFL executa, você pode querer aguardar algumas das suas declarações AFL mais usadas. Como Tomasz apontou em seu comentário para uma versão anterior desta postagem, isso pode ser feito usando um loop simples:
O resultado produzido no DebugView parece assim:
A saída no título parece assim:
A primeira leitura no Título deve ser ignorada à medida que inicializa o PerformanceCounter. Esta leitura é suprimida pelo comando DBViewClear no log DebugView. O método acima pode ser usado para determinar os tempos de execução de todas as funções AFL. Observe que no exemplo acima SetBarsRequired () é usado para processar todos os dados disponíveis. Esta seria a medida do pior caso. Comentando SetBarsRequired () fará seu código executar em Quick-AFL. Isso pode ser significativamente mais rápido do que executar todos os dados.
Ordem e tempo de execução de medição para painéis de janelas.
Quando você está executando fórmulas AFL em vários painéis ou janelas e experimenta um problema de temporização, o primeiro passo a seguir, antes de usar o método acima, é determinar qual painel usa muito tempo. Você pode ativar Ferramentas -> Preferências -> Miscelânea -> Exibir Cronograma do gráfico para ler o tempo de execução na parte inferior dos gráficos. Alternativamente, o código simples abaixo permite que você registre a ordem de execução e a hora das fórmulas em cada painel aberto para DebugView. Uma vez que a leitura do contador de desempenho AmiBroker é única para cada painel, o código abaixo não o usa. Neste caso, você terá que ativar Opções -> Mostrar milissegundos no DebugView. Isso lhe dará resolução de milissegundos, não micro-segundo, como com o contador de desempenho e é uma medida muito aproximada. Ele só deve ser usado para identificar a fórmula do problema. A ordem de execução dos painéis é revelada pela ordem em que as linhas aparecem no DebugView.
A atribuição Filename eo TraceChartID () devem ser colocados no topo do seu código, ou você pode adicioná-lo ao arquivo de inclusão padrão. A única linha usada para chamar essa função deve ser colocada no início e no fim do código em cada janela / painel. Isso é o que parece em DebugView:
Editado por Al Venosa.
21 de julho de 2007.
Atrasos em tempo real.
No mercado em tempo real, muitas situações surgem quando você quer atrasar a ação até que um critério específico seja cumprido. No AmiBroker, você pode basear seus atrasos de várias maneiras diferentes, sendo o único requisito que a variável de atraso aumenta ou diminui. Se a variável selecionada não voltar para o seu valor de tempo limite (destino), sua função de atraso nunca expirará. Neste caso, você teria que adicionar um código para lidar com essa condição. Algumas variáveis que você pode usar são:
& # 8211; Segundos decorridos (redrawaction).
& # 8211; Símbolo de tempo de dados em tempo real (TimeNum ()).
& # 8211; Volume (Mudança no volume).
& # 8211; Mudança de preço (Mudança de preço).
& # 8211; Atualização do gráfico (qualquer execução AFL).
Qual das variáveis acima que você usaria para o seu atraso depende dos requisitos do seu sistema de negociação. Pode haver momentos em que talvez seja necessário combinar vários métodos para obter os resultados necessários. Por exemplo, se um atraso fosse baseado no data-timestamp, pode não ser um tempo limite durante um período de abandono de dados ou um período sem negociação. Neste caso, você precisa fazer backup de seu atraso de data-timestamp com um atraso em tempo real (segundos).
Os atrasos desempenham um papel crítico no design do sistema em tempo real. Por exemplo, em sistemas em tempo real, os sinais podem ter uma vida curta. O sinal é mais forte quando desencadeia e que rapidamente decaça até que, talvez depois de algumas barras, tenha perdido toda importância. Deixar o preenchimento da ordem no momento em que perdeu significância é o jogo puro. Para evitar isso, você pode cancelar a ordem após um atraso, ou diminuir o tamanho da posição proporcional à deterioração percebida na força do sinal (talvez com base em barras decorrentes?)
Uma vez que em um sistema em tempo real, o lapso de tempo entre as execuções da AFL pode ser significativo, você deve colocar seus cálculos de preço LMT antes do código de pedido. Cálculo do preço LMT depois que o pedido foi colocado pós o posicionamento da ordem até a próxima execução AFL ocorrer, ou seja, quando a próxima consulta chegar; até então, o preço provavelmente mudou. Especialmente durante períodos de baixo volume, isso pode ser significativo. Quando esses atrasos seriam insignificantes nos sistemas EOD, eles poderiam fazer ou quebrar seu sistema em sistemas rápidos de negociação.
To ensure frequent AFL execution in the absence of quotes, you can place a RequestTimedRefresh(1) statement at the top of your code, where the variable ‘1’ refers to a 1-second refresh. This guarantees an AFL execution at least once per second.
If your code is lengthy and takes a significant amount of time to execute, you may have to check order status at several places in your code. If changed status demands immediate action, you can force an immediate AFL execution by calling the following function:
July 14, 2007.
Preventing Repeat Orders and Whipsaws.
When you are developing a Real-Time trading system, often the first problem you have to solve is to prevent repeat orders. Repeat orders can occur when a signal remains true over several bars or chart refreshes, and each new bar/refresh sends out a new order. This can result in unintentional pyramiding.
Another ordering problem can occur when your entry and exit prices are too close together with respect to price volatility. In this case, the price volatility can whipsaw you in and out of positions in rapid succession. When this happens, slippage and commissions will quickly erode any profits you may have had. Also, if your system cannot keep up with each signal, you may end up in an opposing trade.
A common mistake when attempting to prevent repeat orders is to wait for order confirmation from the TWS after each partial fill. The problem here is that confirmations from the TWS are always subject to significant delay, and they will often let several repeat orders slip through before the acknowledgment is received.
Another flawed method is to filter or smooth the price arrays. Although this may prevent repeat orders, the lag introduced by this technique will kill most systems.
There is no single best way to prevent repeat orders. Your solution will depend on your personal preferences and the principle of your trading system. Under certain conditions you may want to combine several of the methods shown below. The examples presented here are intended to make you aware of the problems involved and suggest some possible solutions. It is your responsibility to modify the code to suit your particular system’s requirements.
To test the demo codes below, you will need to have the TWS running and connected to the IB eDemo or your paper trading account. To keep the programs below as simple as possible, you have to reset the programs after changing the Transmit ParamToggle from Off to On.
Using OrderIDs to prevent repeat orders.
When your program calls the PlaceOrder() or ModifyOrder() function, the IBc returns a unique OrderID. The OrderID uniquely identifies the order you placed so that you can refer to it later to modify, cancel, or check order status. The OrderID only acknowledges that the order was placed; it does not mean that the order was transmitted to the market or was filled.
If an OrderID has been received, this means that the order was placed. You can prevent order repeats by checking whether the OrderID has a value. Then, if you only place orders when the OrderID is empty, you cannot place repeat orders. The first example below lets you explore this procedure.
After an order has been filled or cancelled, you may eventually want to transmit a new order. In this case, you will have to define a rule for clearing the OrderID. This rule can be based on order status, a contrary signal, a time delay, the start of a new bar, or any number of things. Note that after you have cleared an OrderID, you can no longer modify or cancel the order it referred to. Hence, you should only clear an OrderID if you are sure that the OrderID is no longer needed, i. e., the order was confirmed cancelled, filled, or rejected.
The method below demonstrates how to use the OrderID, and because it still allows you to enter and exit (whipsaw) a position within milliseconds, it is only a first step to preventing repeats and whipsaws. To run this demo, Insert the code into a chart pane. When you open the Param window you will see these options:
The Chart Title shows IBc connection, OrderID, and Position status. Note that while Interactive Brokers calls all the messages ‘error’ messages, many are just harmless notifications. For more details on these error messages see API Error Messages.
When you click the Buy button, the Title will display the OrderID for the order placed, Order Status, and the position size if the order was filled. If you watch closely when you place an order, you may see order status change, for example from PreSubmitted to Filled :
In this demo you clear the OrderIDs manually. In a real system it would be cleared when your system is ready to allow the next order to go out.
Clearing OrderIDs at the Start of a New Bar.
In this example the OrderIDs are automatically cleared at the start of a new bar. This limits each type of trade (Buy, Sell, short, or Cover) to one per bar. If you want to place a new order while an order is pending, you may either cancel it first or modify the pending order.
Since the start of a new bar can only be detected when its first quote arrives, it is impossible to get a fill at this time. The earliest time an order can be filled is on the second quote of the bar. How long this takes depends on market volume and whether you use eSignal (trades) or IB data (snapshots). Since the Opening quote can occur at any time during the bar interval, it may take from zero to the full bar interval before the OrderIDs are cleared. To prevent this delay, you can clear the orders with reference to your system’s clock. However, this requires that your system is perfectly synchronized with the market-time (see next example).
The best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next, open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
The chart background will flash Green when a Buy order is placed, Red when a Sell order is placed, and White when a NewBar is started. You can test blocking of repeat orders by manually placing orders in rapid succession. The example code below will only place one Buy and/or Sell order during each bar-period (between White flashes). This method does allow you to take quick profits when both your entry and exit price are hit within one bar period. However you can do this only once per bar.
Clearing OrderIDs after a Delay.
This example maintains a delay between same-type orders. It uses a delay-timer for each type of trade and clears the OrderIDs when the delay times out.
If you set the delay to the bar-interval and if your system clock were synchronized with the market , then this method would give similar results to the NewBar method discussed earlier. However, this method is better since it enables you to place your LMT orders before the Open of the bar, thus giving you a one-quote timing advantage. This may not sound like much, but in fast trading, especially during moderate trading volume, this improves your chances of getting LMT fills.
Again, the best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next, open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
Experiment with the parameter options and observe that you cannot place a same-type order before the delay has timed out (see Chart Title).
If your system trades LMT orders, you can design your orders to alternate between Long and Short without any limitations.
This method is well suited for reversal systems and high speed trading.
If your limit prices are set properly, this method will allow a fast sequence of reversal trades that can be very profitable. Systems like this may make several trades per minute, sometimes for several minutes, during high volatility.
In the following example, Order Status is checked, and an opposite order is only allowed to pass if the previous order has been filled. Note that this demo does not work if the Transmit ParamToggle is turned Off because under that condition no orders are transmitted to the market and can thus never be filled.
Again, the best way to test this example is to use a 1-minute database and set your chart to the 5-minute timeframe. Next open the Bar-Replay tool, select a range, and set the Step Interval to 1 minute and the Step Rate to 1/Sec.
Editado por Al Venosa.
Comments Off on Preventing Repeat Orders and Whipsaws.
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 2011 (1) setembro de 2011 (1) agosto de 2011 (1) julho de 2011 (1) abril de 2011 (2) março de 2011 (6) fevereiro de 2011 (2) janeiro de 2011 (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.357 seconds.
Comments
Post a Comment