Conteúdo do artigo
- Evidências e escopo
- Ilustração
- Processo
- Um evento extremo tem um tempo de ocorrência e um tempo de confirmação.
- Uma definição determinística com um critério de desempate explícito.
- Exemplos numéricos e casos que devem falhar
- Transformando âncoras em uma hipótese de negociação distinta
- Os recursos de volume pertencem a registros de data e hora específicos.
- Verifique a exatidão do evento antes de avaliar os retornos.
- Erros comuns
- Lista prática de verificação
- Perguntas frequentes
- Fontes de pesquisa
Evidências e escopo
As fontes corroboram a terminologia de extremos locais e o perigo de se representar informações retroativamente. O desempate, o tratamento de eventos e o experimento de negociação descritos abaixo são propostas de pesquisa. Nenhum teste retrospectivo de rentabilidade foi realizado para esta implementação.
Fluxo de trabalho prático
- Validar barrasAceitar uma janela completa de observações fechadas.
- Recue r barras a partir da atualAvalie o candidato i=t−r.
- Compare os dois lados.Aplicar a convenção de platô registrado.
- Registre a confirmaçãoSalve a ocorrência e a confirmação separadamente.
- Passe para a estratégiaPermitir que apenas informações subsequentes iniciem as negociações.
Um evento extremo tem um tempo de ocorrência e um tempo de confirmação.
Na barra i, uma nova máxima é apenas uma possibilidade. Com uma janela à direita de r=3, mais três barras devem fechar antes que o detector possa determinar se suas máximas permaneceram abaixo dela. Armazene occurred_at=i e confirmed_at=i+3. Um gráfico pode desenhar o marcador em i para facilitar a leitura, mas uma ordem usando esse evento não pode existir antes da confirmação e do atraso de processamento de dados relevante.
O TradingView descreve a geometria de pivô bilateral ([1]) e alerta que plotar um pivô no passado pode representar erroneamente quando ele se tornou conhecido ([2]). O SciPy (find_peaks) usa uma convenção diferente para platôs planos ([3]). Consequentemente, comparar a imagem final não é suficiente ao comparar implementações: suas âncoras escolhidas e os registros de data e hora disponíveis podem diferir.
Um pivô confirmado continua sendo uma observação histórica, mesmo que o preço rompa seu nível depois. Tratar cada rompimento posterior como prova de erro do pivô confunde a definição de extremo local com uma previsão de resistência permanente. Armazene as observações separadamente das hipóteses sobre seu uso futuro.
Uma definição determinística com um critério de desempate explícito.
A linha de base proposta usa l=r=2 e escolhe o ponto mais à direita entre os máximos iguais. H[i] deve ser maior ou igual a todos os máximos à esquerda e estritamente maior que todos os máximos à direita. Inverta as desigualdades para os mínimos. Esses parâmetros e regras de desempate são configurações experimentais, e não valores ótimos ou uma reprodução exata de uma biblioteca específica.
Exige-se l+r+1 barras válidas com timestamps únicos e ordenados e um calendário de negociação conhecido. Se a janela cruzar dados ausentes, registre o motivo e ignore a confirmação. Preencher um intervalo ausente com uma barra de negociação plana inventada pode alterar tanto um platô quanto seu atraso de confirmação. Um fechamento noturno programado é diferente de uma barra ausente sem explicação.
Emita cada evento uma única vez, usando um identificador contendo instrumento, período, versão do detector, carimbo de data/hora da ocorrência e tipo. Se as condições de máxima e mínima forem atendidas em uma barra externa, publique uma observação ambígua. Um mecanismo de padrões subsequente não deve inventar a ordem em que essa barra atingiu sua máxima e mínima.
on_closed_bar(t):
i = t - r
if i < l or window_has_missing_bar(i-l, t): return
high_ok = H[i] >= max(H[i-l:i]) and H[i] > max(H[i+1:t+1])
low_ok = L[i] <= min(L[i-l:i]) and L[i] < min(L[i+1:t+1])
if high_ok and low_ok: emit_ambiguous(i, confirmed_at=t)
elif high_ok: emit_once('HIGH', i, H[i], confirmed_at=t)
elif low_ok: emit_once('LOW', i, L[i], confirmed_at=t)
Exemplos numéricos e casos que devem falhar
Os máximos sintéticos 100, 102, 105, 104 e 103 identificam 105 no índice 2. Com l=r=2, o evento só estará disponível após o fechamento do índice 4. Para barras horárias com fechamento entre 09:00 e 13:00, o extremo ocorreu em 11:00 e a confirmação ocorreu em 13:00. Uma ordem baseada nessa confirmação só poderá ser submetida posteriormente.
Substitua o último valor máximo por 106 e o candidato em 105 falha. Nenhum pivô publicado precisa ser excluído porque nunca foi confirmado. Em 100, 102, 105, 105, 104, 103, o segundo 105 é selecionado pela regra proposta mais à direita. Desigualdades estritas em ambos os lados rejeitariam o platô, produzindo um detector diferente que deve ter uma versão diferente.
Uma barra externa com H=108 e L=95 pode ultrapassar as máximas vizinhas enquanto fica abaixo das mínimas vizinhas. OHLC não permite determinar se 108 ou 95 veio primeiro. Mantenha ambos os fatos ou um indicador de ambiguidade, mas não os trate como duas etapas ordenadas em uma sequência de ombro-cabeça-ombro. Um teste útil compara a mesma barra OHLC com dois possíveis caminhos intrabarra e verifica se o detector de barra nunca reivindica informações indisponíveis em sua entrada.
Transformando âncoras em uma hipótese de negociação distinta
O detector não envia ordens. Um experimento proposto compra apenas após um fechamento posterior ultrapassar uma máxima de pivô confirmada mais um buffer, com buffer=max(2 ticks,0.1×ATR from before the trigger bar). O ATR dessa expressão usa dados anteriores à barra de gatilho. Entrar na próxima abertura executável e manter uma ordem buy-stop pendente são modelos distintos; escolha um antes de medir o desempenho.
Uma mínima de pivô já confirmada pode definir o stop estrutural, enquanto uma validade fixa de K barras limita por quanto tempo a máxima continua como nível candidato. Não registre um rompimento supostamente ocorrido antes de a referência necessária estar disponível. Se outro detector ou um atraso nos dados mostrar que o nível já foi ultrapassado, rejeite o setup desatualizado ou defina uma estratégia de entrada tardia separada.
Mantenha o fluxo de dados brutos imutável. Uma representação alternada de valores altos e baixos é uma transformação subsequente: dois valores altos consecutivos podem exigir fusão ou substituição de candidatos, mas essas operações devem ser versionadas e registradas com data e hora. Um padrão previamente publicado não pode adquirir silenciosamente uma âncora melhor a partir de dados posteriores. Registre explicitamente a invalidação, expiração ou criação de um candidato substituto.
Os testes de execução devem incluir um gap entre sinal e execução, falta de ativos disponíveis para aluguel na venda a descoberto de estratégias simétricas e um stop ultrapassado antes da abertura da barra seguinte. Um evento válido do detector pode resultar em nenhuma operação ou em uma operação sem viabilidade econômica; o relatório deve distinguir esses resultados.
Os recursos de volume pertencem a registros de data e hora específicos.
Mantenha o volume em occurred_at e o volume em confirmed_at em colunas separadas. O primeiro descreve a atividade de negociação no extremo; o segundo descreve a atividade durante a confirmação subsequente. Um recurso que utiliza as próximas três barras está disponível na confirmação, não retroativamente na barra de pivô. Seu registro de data e hora deve seguir a entrada mais recente que utiliza.
Uma ablação proposta compara o setup baseado só em preço com RVOL no gatilho posterior: volume atual dividido pela mediana das 20 barras anteriores, com 1.5 como limiar experimental. Para ações intraday, comparar o mesmo horário de sessão costuma ser mais bem definido do que misturar abertura e meio do dia. O volume de ticks de FX mede atualizações específicas do provedor, não necessariamente contratos negociados.
Teste se o volume adiciona informações dentro de grupos de volatilidade e horário comparáveis. Caso contrário, um filtro de volume pode simplesmente selecionar barras largas com custos de execução mais altos. Registre também as oportunidades rejeitadas: avaliar apenas as negociações executadas pode ocultar o fato de que o filtro removeu a maioria das oportunidades ou alterou substancialmente a exposição.
Verifique a exatidão do evento antes de avaliar os retornos.
Reproduza cada prefixo dos dados e compare os eventos publicados até seu final. Acrescentar 100 barras não pode mudar o identificador, preço, tipo nem timestamp de confirmação de um evento antigo. Compare registros, não capturas de tela. Inclua casos de teste para platôs, barras externas, intervalos ausentes, mudanças no tick e preços negativos quando o instrumento permitir.
Meça os pivôs por cada 1,000 barras, o atraso de confirmação, a distância entre referências e a proporção de padrões posteriores que já são inválidos quando sua última referência se torna conhecida. Esses diagnósticos explicam como mudanças no detector alteram as oportunidades antes de introduzir estatísticas de lucro.
Compare l=r=2 com 3 e 5 em dados de desenvolvimento e congele a seleção antes do teste final. Teste também janelas assimétricas como configurações registradas separadamente. Âncoras visualmente mais atraentes não estabelecem uma expectativa líquida maior. A avaliação final de negociação deve incluir spread, comissões, gaps, execução de stop, dimensionamento de posição e o custo de oportunidade do atraso na confirmação.
Erros comuns
Entrando exatamente em um extremo marcado retrospectivamente
Um marcador retroprojetado é usado como um registro de data e hora do pedido. A reprodução do prefixo expõe as informações indisponíveis.
Confundir pontos de pivô locais com pontos de pivô de sessão
Os extremos locais e as fórmulas P, R e S baseadas em sessões são ferramentas diferentes com entradas diferentes.
Escolher a escala após visualizar os resultados
Cada par l/r representa um ensaio de pesquisa. Mantenha as variantes que falharam, bem como a configuração selecionada.
Lista de verificação antes de usar este método
Marque cada item após verificá-lo nos seus dados. O progresso fica salvo neste navegador; isso não certifica que a estratégia seja lucrativa.
Perguntas frequentes
Definir r=0 elimina o atraso?
Ele pode criar um detector de extremos apenas para o passado, mas não há confirmação de reversão para o lado direito. É um sinal diferente e precisa de avaliação separada.
O preço pode romper um pivô confirmado?
Sim. O extremo histórico permanece corretamente identificado; uma quebra de resistência posterior não apaga a observação.
Fontes de pesquisa
Cada fonte sustenta a definição ou evidência descrita ao lado. O pseudocódigo, os exemplos sintéticos e os parâmetros propostos exigem validação separada.
- Auto trendlinesTradingView. Leia a definição de pivô de dois lados; exemplos comerciais não são considerados como evidência de lucratividade. Verificado em: .
- Pine Script: RepaintingTradingView. Leia as seções sobre plotagem no passado e dados fluidos e incompletos. Verificado em: .
- scipy.signal.find_peaksSciPy. Leia sobre o comportamento de platô e dados faltantes; esta é uma especificação API, não evidência financeira. Verificado em: .
Métodos relacionados
Nota de risco
Este conteúdo apoia a educação e o planejamento de pesquisas, não constitui aconselhamento financeiro. O Backtest é uma simulação histórica, não garante desempenho futuro e não executa operações reais. Os métodos desta biblioteca não são necessariamente recursos disponíveis no aplicativo. Consulte a metodologia e a central de aprendizado.
Valide as regras antes de arriscar capital real
Verifique o suporte do aplicativo, os dados e cada operação simulada; detectores avançados podem exigir uma implementação própria.
Baixe o Backtest na App Store