Mais um passo.
Complete a verificação de segurança para acessar o código comercial.
Por que eu tenho que completar um CAPTCHA?
Concluir o CAPTCHA prova que você é humano e dá acesso temporário à propriedade da web.
O que posso fazer para evitar isso no futuro?
Se você estiver em uma conexão pessoal, como em casa, você pode executar uma verificação antivírus em seu dispositivo para se certificar de que não está infectado com malware.
Se você estiver em um escritório ou rede compartilhada, você pode pedir ao administrador da rede para executar uma varredura na rede procurando dispositivos mal configurados ou infectados.
Cloudflare Ray ID: 3e34cbfa155a5a0e & bull; Seu IP: 78.109.24.111 & bull; Performance & amp; segurança por Cloudflare.
Mais um passo.
Complete a verificação de segurança para acessar o código comercial.
Por que eu tenho que completar um CAPTCHA?
Concluir o CAPTCHA prova que você é humano e dá acesso temporário à propriedade da web.
O que posso fazer para evitar isso no futuro?
Se você estiver em uma conexão pessoal, como em casa, você pode executar uma verificação antivírus em seu dispositivo para se certificar de que não está infectado com malware.
Se você estiver em um escritório ou rede compartilhada, você pode pedir ao administrador da rede para executar uma varredura na rede procurando dispositivos mal configurados ou infectados.
Outra maneira de evitar esta página no futuro é usar o Passo de Privacidade. Confira a extensão do navegador na Loja de Complementos do Firefox.
Cloudflare Ray ID: 3e34cbfa27b65a14 & bull; Seu IP: 78.109.24.111 & bull; Performance & amp; segurança por Cloudflare.
Estratégias.
Uma estratégia é um estudo que pode enviar, modificar e cancelar pedidos (para comprar / vender). As estratégias permitem que você execute backtesting (emulação de negociação de estratégia em dados históricos) e forwardtesting (emulação de negociação de estratégia em dados em tempo real) de acordo com seus algoritmos pré-modificados.
Uma estratégia escrita no idioma Pine Script tem todas as mesmas capacidades que um indicador Pine. Quando você escreve um código de estratégia, ele deve começar com a palavra-chave "estratégia", não "estudar". Estratégias não apenas traçam algo, mas também colocam, modificam e cancelam pedidos. Eles têm acesso a informações de desempenho de estratégia essenciais através de palavras-chave específicas. A mesma informação está disponível para você na guia "Strategy Tester". Uma vez que uma estratégia é calculada em dados históricos, você pode ver enchimentos de ordem hipotéticos.
Um exemplo de estratégia simples.
Assim que o script for compilado e aplicado a um gráfico, você pode ver marcas de pedidos preenchidas e como seu saldo estava mudando durante o teste de retorno (curva de equidade). É uma estratégia mais simples que compra e vende em cada barra.
A estratégia de primeira linha ("teste") indica que o código pertence ao tipo de estratégia e seu nome é "teste". strategy. entry () é um comando para enviar pedidos "comprar" e "vender". plot (strategy. equity) traça a curva de equidade.
Como aplicar uma estratégia ao gráfico.
Para testar sua estratégia, aplique-a para o gráfico. Use o símbolo e os intervalos de tempo que deseja testar. Você pode usar uma estratégia interna dos "Indicadores & amp; Stratedies ", ou escreva o seu próprio no Pine Editor.
Nota: Ao usar tipos de gráfico não padronizados (Renko, Kagi, Line Break, Ponto e Figura, Heikin Ashi, Gráficos de Distribuição) como base para a estratégia, você precisa perceber que o resultado será diferente. As ordens serão executadas aos preços deste gráfico (por exemplo, para Heikin Ashi, levará os preços Heikin Ashi (os médios) e não os preços reais do mercado). Portanto, recomendamos que você use o tipo de gráfico padrão para estratégias.
Backtesting e forwardtesting.
As estratégias TradingView são calculadas em todos os dados históricos disponíveis no gráfico e continuam o cálculo quando os dados em tempo real chegam.
Tanto durante o cálculo histórico e em tempo real, o código é calculado na barra fecha por padrão.
Se isso for encaminhado, o código calcula em cada tico em tempo real. Para ativar isso, marque a opção "Recalcular em cada toque" nas configurações ou faça-o no próprio script: estratégia (. Calc_on_every_tick = true,.).
Você pode definir a estratégia para executar cálculos adicionais depois de um pedido ser preenchido. Para isso, você precisa marcar "Recalcular após pedido preenchido" nas configurações ou fazê-lo no próprio script: estratégia (..., calc_on_order_fills = true,.).
Emulador de corretores.
Existe um emulador de corretores no TradingView para estratégias de teste. Ao contrário do comércio real, o emulador preenche apenas os preços dos gráficos, por isso um pedido pode ser preenchido somente no próximo teste no teste a seguir e na barra seguinte no backtesting (ou posterior) após a estratégia ser calculada.
Conforme mencionado acima, a estratégia de backtesting é calculada no fechamento do bar. A seguinte lógica é usada para emular preenchimentos de pedidos:
Se o preço de abertura do bar estiver mais próximo do preço mais alto do mesmo bar, o emulador do corretor assume que o preço intrabar estava se movendo desta forma: Abrir → Alto → Baixo → Fechar. Se o preço de abertura do bar estiver mais próximo do preço mais baixo do mesmo bar, o emulador do corretor assume que o preço intrabar estava se movendo desta forma: Abrir → Baixo → Alto → Fechar. O emulador de corretores assume que não havia lacunas dentro da barra, o que significa que todos os preços intrabar estão disponíveis para a execução da ordem. Se a opção "Recalcular On Every Tick" nas propriedades da estratégia estiver ativada (ou a estratégia (. Calc_on_every_tick = true,.) É especificada no script), o código ainda é calculado apenas no fim da barra, seguindo a lógica acima.
Aqui está a estratégia que demonstra como as ordens são preenchidas pelo emulador do corretor:
Este código é calculado uma vez por barra por padrão, em seu fechamento, no entanto, há um cálculo adicional assim que um pedido é preenchido. É por isso que você pode ver 4 ordens preenchidas em cada barra: 2 pedidos em aberto, 1 ordem em alta e 1 ordem em baixo. Isso é uma prova de atraso. Se fosse em tempo real, as ordens seriam executadas em cada novo tiquetaque.
Também é possível emular a fila de pedidos. A configuração é chamada de "Verificar preço para ordens limite" e pode ser encontrada em propriedades de estratégia ou definir no próprio script: estratégia (. Backtest_fill_limits_assumption = X,.). O valor especificado = número de pontos / pips (movimentos de preço mínimo), valor padrão = 0. Uma ordem de limite é preenchida se o preço atual for melhor (maior para ordens de venda, menor para ordens de compra) para o número especificado de pontos / pips. O preço de execução ainda corresponde ao preço da ordem limite.
backtest_fill_limits_assumption = 1. Movimento do preço mínimo = 0,25.
Um pedido de limite de compra é colocado no preço 12,50.
O preço atual é 12,50.
O pedido não pode ser preenchido a preço atual apenas porque backtest_fill_limits_assumption = 1. Para preencher a ordem, o preço deve se tornar 0.25 * 1 menor. A ordem é colocada na fila.
Suponha que o próximo tiquete com preço 12,00. Este preço é 2 pontos mais baixo, o que significa que a condição "backtest_fill_limits_assumption = 1" está satisfeita, portanto, a ordem deve ser preenchida. O pedido é preenchido às 12h50 (preço original do pedido), mesmo que o preço não esteja mais disponível.
Comandos de colocação de pedidos.
Todas as palavras-chave projetadas para estratégias começam com o prefixo "estratégia". Os seguintes comandos são usados para fazer pedidos: strategy. entry, strategy. order e strategy. exit:
strategy. entry - este comando coloca apenas ordens de entrada. É afetado pela configuração piramidal (nas propriedades da estratégia) e pela palavra-chave strategy. risk. allow_entry_in. Se houver uma posição de mercado aberto quando uma ordem de direção oposta for gerada, o número de contratos / partes / lotes / unidades será aumentado pelo número de contratos atualmente abertos (script equivalente: strategy. position_size + quantity). Como resultado, o tamanho da posição de mercado para abrir será igual ao tamanho da ordem, especificado no comando strategy. entry. strategy. order - este comando coloca as ordens de entrada e saída. Não é afetado pela configuração piramidal e pela palavra-chave strategy. risk. allow_entry_in. Ele permite que você crie construções complexas de entrada e saída quando as capacidades da strategy. entry e do strategy. exit não são suficientes. strategy. exit - este comando permite que você saia de uma posição de mercado por meio de uma ordem ou de uma estratégia de pedido de saída múltipla (stop loss, profit target, trailing stop). Todas essas ordens fazem parte do mesmo grupo strategy. oca. reduce. Uma ordem de saída não pode ser colocada se não houver uma posição de mercado aberto ou não haja uma ordem de entrada ativa (uma ordem de saída é vinculada à identificação de uma ordem de entrada). Não é possível sair de uma posição com uma ordem de mercado usando o comando strategy. exit. Para este objetivo, os seguintes comandos devem ser usados: strategy. close ou strategy. close_all. Se o número de contratos / partes / lotes / unidades especificadas para o strategy. exit for inferior ao tamanho da posição aberta atual, a saída será parcial. Não é possível sair da mesma ordem de entrada mais de 1 vez usando a mesma ordem de saída (ID), que permite que você crie estratégias de saída com múltiplos níveis. No caso, quando uma posição de mercado foi formada por várias ordens de entrada (pyramiding habilitado), cada ordem de saída é vinculada a cada ordem de entrada individualmente.
A estratégia acima invoca constantemente a posição de mercado de +4 para -6, para frente e para trás, o que é mostrado por sua trama.
Esta estratégia demonstra o caso, quando a posição do mercado nunca é fechada, porque usa a ordem de saída para fechar a posição do mercado apenas parcialmente e não pode ser usada mais de uma vez. Se você dobrar a linha para sair, a estratégia fechará completamente a posição do mercado.
Este código gera 2 níveis de parênteses (2 pegue ordens de lucro e 2 ordens de perda de parada). Ambos os níveis são ativados ao mesmo tempo: primeiro nível para sair de 2 contratos e o segundo para sair de todo o resto.
As primeiras ordens de lucro e stop loss (nível 1) estão em um grupo OCA. As outras ordens (nível 2) estão em outro grupo OCA. Isso significa que assim que um pedido do nível 1 é preenchido, as ordens do nível 2 não são canceladas, ficam ativas.
Cada comando que faz um pedido possui ID (valor da string) - identificador de pedido exclusivo. Se um pedido com o mesmo ID já estiver colocado (mas ainda não preenchido), o comando atual modifica a ordem existente. Se a modificação não for possível (conversão de compra para venda), a ordem antiga é cancelada, a nova ordem é colocada. strategy. entry e strategy. order funcionam com os mesmos IDs (eles podem modificar a mesma ordem de entrada). strategy. exit funciona com outras IDs de pedido (é possível ter uma ordem de entrada e uma ordem de saída com a mesma ID).
Para cancelar uma ordem específica (por sua ID), o comando strategy. cancel (string id) deve ser usado. Para cancelar todas as ordens pendentes, o comando strategy. cancel_all () deve ser usado. As ordens de estratégia são colocadas assim que suas condições são satisfeitas e o comando é chamado de código. O emulador de corretor não executa as ordens antes do próximo cheque depois que o código foi calculado, enquanto na negociação real com corretor real, um pedido pode ser preenchido mais cedo. Isso significa que, se uma ordem de mercado for gerada no final da barra atual, ela será preenchida na próxima barra aberta.
Se este código é aplicado a um gráfico, todos os pedidos são preenchidos em aberto de cada barra.
As condições para a colocação da ordem (quando, pyramiding, strategy. risk) são verificadas quando o script é calculado. Se todas as condições forem satisfeitas, a ordem será colocada. Se alguma condição não for satisfeita, a ordem não será colocada. É importante cancelar pedidos de preços (ordens limite, parada e parada-limite).
Exemplo (para MSFT 1D):
Mesmo que a pirâmide esteja desativada, essas duas ordens são preenchidas em backtesting, porque quando elas são geradas não há uma posição aberta de mercado longo. Ambas as ordens são colocadas e quando o preço satisfaz a execução da ordem, ambos são executados. Recomenda-se colocar as ordens em 1 grupo OCA por meio de strategy. oca. cancel. neste caso, apenas uma ordem é preenchida e a outra é cancelada. Aqui está o código modificado:
Se, por algum motivo, as condições de colocação de pedidos não forem cumpridas ao executar o comando, a ordem de entrada não será colocada. Por exemplo, se as configurações de pirâmide estiverem configuradas para 2, a posição existente já contém duas entradas e a estratégia tenta colocar uma terceira, ela não será colocada. As condições de entrada são avaliadas no estágio de geração da ordem e não na fase de execução. Portanto, se você enviar duas entradas de tipo de preço com piramide desabilitado, uma vez que uma delas é executada, a outra não será cancelada automaticamente. Para evitar problemas, recomendamos usar grupos OCA-Cancelar para entradas, então, quando uma ordem de entrada é preenchida, os outros são cancelados.
O mesmo é válido para as saídas do tipo de preço - as ordens serão colocadas uma vez que suas condições sejam atendidas (ou seja, é preenchida uma ordem de entrada com o id respectivo).
Se você aplicar este exemplo a um gráfico, você pode ver que a ordem de saída foi preenchida, apesar do fato de ter sido gerado apenas uma vez antes do pedido de entrada a ser fechado. No entanto, a próxima entrada não foi fechada antes do final do cálculo, já que o comando de saída já foi acionado.
Posição de mercado de fechamento.
Apesar de ser possível sair de uma entrada específica no código, quando os pedidos são mostrados na guia Lista de Trades no StrategyTester, todos eles estão vinculados de acordo com a regra FIFO (primeiro dentro, primeiro fora). Se uma ID de pedido de entrada não for especificada para uma ordem de saída no código, a ordem de saída encerra a primeira ordem de entrada que abriu a posição de mercado. Vamos estudar o seguinte exemplo:
O código indicado acima coloca 2 ordens sequencialmente: "Buy1" a preço de mercado e "Buy2" a um preço 10% maior (ordem de parada). O pedido de saída é colocado somente depois que os pedidos de entrada foram preenchidos. Se você aplicar o código a um gráfico, você verá que cada pedido de entrada é fechado pela ordem de saída, embora não especifiquemos a identificação da ordem de entrada para fechar nesta linha: strategy. exit ("bracket", loss = 10, profit = 10, quando = strategy. position_size == 15)
Ele abre 5 contratos de posição longa com a ordem "Buy1". Estende a posição comprada comprando mais 10 contratos com preço 10% maior com a ordem "Buy2". A ordem de saída (strategy. close) para vender 10 contratos (saída de "Buy2") é preenchida.
Se você der uma olhada no enredo, você pode ver esse preço médio de entrada = preço de execução "Buy2" e nossa estratégia fechou exatamente essa ordem de entrada, enquanto na guia TradeList podemos ver que fechou o primeiro pedido "Buy1" e meio do segundo "Buy2". Isso significa que, independentemente da ordem de entrada que você especificar para a sua estratégia fechar, o emulador do corretor ainda fechará o primeiro (de acordo com a regra FIFO). Funciona da mesma maneira quando se troca com o intermediário intermediário.
Grupos OCA.
É possível colocar pedidos em 2 grupos OCA diferentes no Pine Script:
strategy. oca. cancel - assim que um pedido do grupo é preenchido (mesmo parcialmente) ou cancelado, os outros pedidos do mesmo grupo são cancelados. Deve ter em mente que, se os preços das ordens forem iguais ou forem próximos, mais de 1 ordem do mesmo grupo pode ser preenchida. Este tipo de grupo OCA está disponível somente para pedidos de entrada porque todas as ordens de saída são colocadas em strategy. oca. reduce.
Você pode pensar que esta é uma estratégia inversa, uma vez que a pirâmide não é permitida, mas, de fato, ambas as ordens serão preenchidas porque são de ordem do mercado, o que significa que elas serão executadas imediatamente ao preço atual. A segunda ordem não é cancelada porque ambos são preenchidos quase no mesmo momento e o sistema não tem tempo para processar o preenchimento da primeira ordem e cancelar o segundo antes de ser executado. O mesmo aconteceria se estes fossem pedidos de preços com preços iguais ou similares. A estratégia coloca todos os pedidos (que são permitidos de acordo com a posição do mercado, etc.).
A estratégia coloca todos os pedidos que não contradizem as regras (na nossa posição, a posição do mercado é plana, portanto, qualquer pedido de entrada pode ser preenchido). Em cada cálculo do tiquetaque, primeiro todos os pedidos com as condições satisfeitas são executados e somente as ordens do grupo onde um pedido foi executado são canceladas.
strategy. oca. reduce - este tipo de grupo permite que vários pedidos dentro do grupo sejam preenchidos. À medida que uma das ordens dentro do grupo começa a ser preenchida, o tamanho de outras ordens é reduzido pelo valor dos contratos preenchidos. É muito útil para as estratégias de saída. Uma vez que o preço atinja a sua ordem de lucro e está sendo preenchido, a perda de stop não é cancelada, mas seu valor é reduzido pelo valor dos contratos preenchidos, protegendo assim o restante da posição aberta. strategy. oca. none - a ordem é colocada fora do grupo (valor padrão para os comandos strategy. order e strategy. entry).
Todo grupo tem seu id exclusivo (da mesma forma que os pedidos). Se dois grupos tiverem o mesmo id, mas tipo diferente, eles serão considerados grupos diferentes. Exemplo:
"Comprar" e "Vender" serão colocados em diferentes grupos, pois seu tipo é diferente. "Ordem" estará fora de qualquer grupo, pois seu tipo está definido para strategy. oca. none. Além disso, "Buy" será colocado no grupo de saída, pois as saídas são sempre colocadas no grupo de tipo strategy. oca. reduce_size.
Gerenciamento de riscos.
Não é fácil criar uma estratégia lucrativa universal. Normalmente, estratégias são criadas para certos padrões de mercado e podem produzir perdas incontroláveis quando aplicadas a outros dados. Portanto, interromper a negociação automática no tempo, as coisas ficam ruins é um problema sério. Existe um grupo especial de comandos de estratégia para gerenciar riscos. Todos começam com o prefixo strategy. risk. *.
Você pode combinar qualquer número de riscos em qualquer combinação dentro de uma estratégia. Todo comando de categoria de risco é calculado em cada marca, bem como em todos os eventos de execução de pedidos independentemente da configuração da estratégia calc_on_order_fills. Não há como desativar qualquer regra de risco no tempo de execução do script. Independentemente de onde no script a regra de risco estiver localizada, ela sempre será aplicada a menos que a linha com a regra seja excluída e o script seja recompilado.
Se no próximo cálculo qualquer das regras for acionada, nenhuma ordem será enviada. Portanto, se uma estratégia tiver várias regras do mesmo tipo com diferentes parâmetros, ela irá parar de calcular quando a regra com os parâmetros mais rigorosos é desencadeada. Quando uma estratégia é interrompida, todas as ordens não executadas são canceladas e, em seguida, uma ordem de mercado é enviada para fechar a posição se não for plana.
Além disso, vale lembrar que ao usar resoluções superiores a 1 dia, a barra inteira é considerada 1 dia para as regras que começam com o prefixo "strategy. risk. max_intraday_"
A posição será fechada e a negociação será interrompida até o final de cada sessão de negociação após duas ordens serem executadas nesta sessão à medida que a segunda regra é desencadeada anteriormente e é válida até o final da sessão de negociação.
Deve lembrar-se que a regra strategy. risk. allow_entry_in é aplicada somente nas entradas para que seja possível entrar em uma troca usando o comando strategy. order, pois este comando não é um comando de entrada per se. Além disso, quando a regra strategy. risk. allow_entry_in está ativa, as entradas em um "comércio proibido" tornam-se as saídas em vez das negociações reversas.
Exemplo (MSFT 1D):
Como as entradas curtas são proibidas pelas regras de risco, em vez de transações reversas, as negociações de saída longa serão feitas.
As estratégias TradingView podem operar na moeda diferente da moeda do instrumento. NetProfit e OpenProfit são recalculados na moeda da conta. A moeda da conta é definida nas propriedades da estratégia - a lista suspensa Moeda básica ou no script através da palavra-chave estratégia (. Currency = currency. *,.). Ao mesmo tempo, os valores do relatório de desempenho são calculados na moeda selecionada.
O lucro comercial (aberto ou fechado) é calculado com base no lucro na moeda do instrumento multiplicado pela taxa cruzada no fechamento do dia de negociação anterior à barra onde a estratégia é calculada.
Exemplo: trocamos EURUSD, D e selecionamos EUR como moeda da estratégia. Nossa estratégia compra e sai da posição usando 1 lucro de ponto ou stopLoss.
Depois de adicionar esta estratégia ao gráfico, podemos ver que as linhas do gráfico estão em correspondência. Isso demonstra que a taxa para calcular o lucro para cada comércio foi baseada no fechamento do dia anterior.
Ao negociar em resoluções intra-dia, a taxa cruzada no encerramento do dia de negociação anterior ao bar onde a estratégia é calculada será usada e não será alterada durante todo o período de negociação.
Ao negociar em deliberações superiores a 1 dia, será utilizada a taxa cruzada no encerramento do dia de negociação anterior ao encerramento do bar, onde a estratégia será calculada. Digamos que trocamos em um gráfico semanal, então a taxa de cruzamento no fechamento da sessão de quinta-feira sempre será usada para calcular os lucros.
Em tempo real, a taxa de fechamento da sessão de ontem é usada.
Estratégias.
Uma estratégia é um estudo que pode enviar, modificar e cancelar pedidos (para comprar / vender). As estratégias permitem que você execute backtesting (emulação de negociação de estratégia em dados históricos) e forwardtesting (emulação de negociação de estratégia em dados em tempo real) de acordo com seus algoritmos pré-modificados.
Uma estratégia escrita no idioma Pine Script tem todas as mesmas capacidades que um indicador Pine. Quando você escreve um código de estratégia, ele deve começar com a palavra-chave "estratégia", não "estudar". Estratégias não apenas traçam algo, mas também colocam, modificam e cancelam pedidos. Eles têm acesso a informações de desempenho de estratégia essenciais através de palavras-chave específicas. A mesma informação está disponível para você na guia "Strategy Tester". Uma vez que uma estratégia é calculada em dados históricos, você pode ver enchimentos de ordem hipotéticos.
Um exemplo de estratégia simples.
Assim que o script for compilado e aplicado a um gráfico, você pode ver marcas de pedidos preenchidas e como seu saldo estava mudando durante o teste de retorno (curva de equidade). É uma estratégia mais simples que compra e vende em cada barra.
A estratégia de primeira linha ("teste") indica que o código pertence ao tipo de estratégia e seu nome é "teste". strategy. entry () é um comando para enviar pedidos "comprar" e "vender". plot (strategy. equity) traça a curva de equidade.
Como aplicar uma estratégia ao gráfico.
Para testar sua estratégia, aplique-a para o gráfico. Use o símbolo e os intervalos de tempo que deseja testar. Você pode usar uma estratégia interna dos "Indicadores & amp; Stratedies ", ou escreva o seu próprio no Pine Editor.
Nota: Ao usar tipos de gráfico não padronizados (Renko, Kagi, Line Break, Ponto e Figura, Heikin Ashi, Gráficos de Distribuição) como base para a estratégia, você precisa perceber que o resultado será diferente. As ordens serão executadas aos preços deste gráfico (por exemplo, para Heikin Ashi, levará os preços Heikin Ashi (os médios) e não os preços reais do mercado). Portanto, recomendamos que você use o tipo de gráfico padrão para estratégias.
Backtesting e forwardtesting.
As estratégias TradingView são calculadas em todos os dados históricos disponíveis no gráfico e continuam o cálculo quando os dados em tempo real chegam.
Tanto durante o cálculo histórico e em tempo real, o código é calculado na barra fecha por padrão.
Se isso for encaminhado, o código calcula em cada tico em tempo real. Para ativar isso, marque a opção "Recalcular em cada toque" nas configurações ou faça-o no próprio script: estratégia (. Calc_on_every_tick = true,.).
Você pode definir a estratégia para executar cálculos adicionais depois de um pedido ser preenchido. Para isso, você precisa marcar "Recalcular após pedido preenchido" nas configurações ou fazê-lo no próprio script: estratégia (..., calc_on_order_fills = true,.).
Emulador de corretores.
Existe um emulador de corretores no TradingView para estratégias de teste. Ao contrário do comércio real, o emulador preenche apenas os preços dos gráficos, por isso um pedido pode ser preenchido somente no próximo teste no teste a seguir e na barra seguinte no backtesting (ou posterior) após a estratégia ser calculada.
Conforme mencionado acima, a estratégia de backtesting é calculada no fechamento do bar. A seguinte lógica é usada para emular preenchimentos de pedidos:
Se o preço de abertura do bar estiver mais próximo do preço mais alto do mesmo bar, o emulador do corretor assume que o preço intrabar estava se movendo desta forma: Abrir → Alto → Baixo → Fechar. Se o preço de abertura do bar estiver mais próximo do preço mais baixo do mesmo bar, o emulador do corretor assume que o preço intrabar estava se movendo desta forma: Abrir → Baixo → Alto → Fechar. O emulador de corretores assume que não havia lacunas dentro da barra, o que significa que todos os preços intrabar estão disponíveis para a execução da ordem. Se a opção "Recalcular On Every Tick" nas propriedades da estratégia estiver ativada (ou a estratégia (. Calc_on_every_tick = true,.) É especificada no script), o código ainda é calculado apenas no fim da barra, seguindo a lógica acima.
Aqui está a estratégia que demonstra como as ordens são preenchidas pelo emulador do corretor:
Este código é calculado uma vez por barra por padrão, em seu fechamento, no entanto, há um cálculo adicional assim que um pedido é preenchido. É por isso que você pode ver 4 ordens preenchidas em cada barra: 2 pedidos em aberto, 1 ordem em alta e 1 ordem em baixo. Isso é uma prova de atraso. Se fosse em tempo real, as ordens seriam executadas em cada novo tiquetaque.
Também é possível emular a fila de pedidos. A configuração é chamada de "Verificar preço para ordens limite" e pode ser encontrada em propriedades de estratégia ou definir no próprio script: estratégia (. Backtest_fill_limits_assumption = X,.). O valor especificado = número de pontos / pips (movimentos de preço mínimo), valor padrão = 0. Uma ordem de limite é preenchida se o preço atual for melhor (maior para ordens de venda, menor para ordens de compra) para o número especificado de pontos / pips. O preço de execução ainda corresponde ao preço da ordem limite.
backtest_fill_limits_assumption = 1. Movimento do preço mínimo = 0,25.
Um pedido de limite de compra é colocado no preço 12,50.
O preço atual é 12,50.
O pedido não pode ser preenchido a preço atual apenas porque backtest_fill_limits_assumption = 1. Para preencher a ordem, o preço deve se tornar 0.25 * 1 menor. A ordem é colocada na fila.
Suponha que o próximo tiquete com preço 12,00. Este preço é 2 pontos mais baixo, o que significa que a condição "backtest_fill_limits_assumption = 1" está satisfeita, portanto, a ordem deve ser preenchida. O pedido é preenchido às 12h50 (preço original do pedido), mesmo que o preço não esteja mais disponível.
Comandos de colocação de pedidos.
Todas as palavras-chave projetadas para estratégias começam com o prefixo "estratégia". Os seguintes comandos são usados para fazer pedidos: strategy. entry, strategy. order e strategy. exit:
strategy. entry - este comando coloca apenas ordens de entrada. É afetado pela configuração piramidal (nas propriedades da estratégia) e pela palavra-chave strategy. risk. allow_entry_in. Se houver uma posição de mercado aberto quando uma ordem de direção oposta for gerada, o número de contratos / partes / lotes / unidades será aumentado pelo número de contratos atualmente abertos (script equivalente: strategy. position_size + quantity). Como resultado, o tamanho da posição de mercado para abrir será igual ao tamanho da ordem, especificado no comando strategy. entry. strategy. order - este comando coloca as ordens de entrada e saída. Não é afetado pela configuração piramidal e pela palavra-chave strategy. risk. allow_entry_in. Ele permite que você crie construções complexas de entrada e saída quando as capacidades da strategy. entry e do strategy. exit não são suficientes. strategy. exit - este comando permite que você saia de uma posição de mercado por meio de uma ordem ou de uma estratégia de pedido de saída múltipla (stop loss, profit target, trailing stop). Todas essas ordens fazem parte do mesmo grupo strategy. oca. reduce. Uma ordem de saída não pode ser colocada se não houver uma posição de mercado aberto ou não haja uma ordem de entrada ativa (uma ordem de saída é vinculada à identificação de uma ordem de entrada). Não é possível sair de uma posição com uma ordem de mercado usando o comando strategy. exit. Para este objetivo, os seguintes comandos devem ser usados: strategy. close ou strategy. close_all. Se o número de contratos / partes / lotes / unidades especificadas para o strategy. exit for inferior ao tamanho da posição aberta atual, a saída será parcial. Não é possível sair da mesma ordem de entrada mais de 1 vez usando a mesma ordem de saída (ID), que permite que você crie estratégias de saída com múltiplos níveis. No caso, quando uma posição de mercado foi formada por várias ordens de entrada (pyramiding habilitado), cada ordem de saída é vinculada a cada ordem de entrada individualmente.
A estratégia acima invoca constantemente a posição de mercado de +4 para -6, para frente e para trás, o que é mostrado por sua trama.
Esta estratégia demonstra o caso, quando a posição do mercado nunca é fechada, porque usa a ordem de saída para fechar a posição do mercado apenas parcialmente e não pode ser usada mais de uma vez. Se você dobrar a linha para sair, a estratégia fechará completamente a posição do mercado.
Este código gera 2 níveis de parênteses (2 pegue ordens de lucro e 2 ordens de perda de parada). Ambos os níveis são ativados ao mesmo tempo: primeiro nível para sair de 2 contratos e o segundo para sair de todo o resto.
As primeiras ordens de lucro e stop loss (nível 1) estão em um grupo OCA. As outras ordens (nível 2) estão em outro grupo OCA. Isso significa que assim que um pedido do nível 1 é preenchido, as ordens do nível 2 não são canceladas, ficam ativas.
Cada comando que faz um pedido possui ID (valor da string) - identificador de pedido exclusivo. Se um pedido com o mesmo ID já estiver colocado (mas ainda não preenchido), o comando atual modifica a ordem existente. Se a modificação não for possível (conversão de compra para venda), a ordem antiga é cancelada, a nova ordem é colocada. strategy. entry e strategy. order funcionam com os mesmos IDs (eles podem modificar a mesma ordem de entrada). strategy. exit funciona com outras IDs de pedido (é possível ter uma ordem de entrada e uma ordem de saída com a mesma ID).
Para cancelar uma ordem específica (por sua ID), o comando strategy. cancel (string id) deve ser usado. Para cancelar todas as ordens pendentes, o comando strategy. cancel_all () deve ser usado. As ordens de estratégia são colocadas assim que suas condições são satisfeitas e o comando é chamado de código. O emulador de corretor não executa as ordens antes do próximo cheque depois que o código foi calculado, enquanto na negociação real com corretor real, um pedido pode ser preenchido mais cedo. Isso significa que, se uma ordem de mercado for gerada no final da barra atual, ela será preenchida na próxima barra aberta.
Se este código é aplicado a um gráfico, todos os pedidos são preenchidos em aberto de cada barra.
As condições para a colocação da ordem (quando, pyramiding, strategy. risk) são verificadas quando o script é calculado. Se todas as condições forem satisfeitas, a ordem será colocada. Se alguma condição não for satisfeita, a ordem não será colocada. É importante cancelar pedidos de preços (ordens limite, parada e parada-limite).
Exemplo (para MSFT 1D):
Mesmo que a pirâmide esteja desativada, essas duas ordens são preenchidas em backtesting, porque quando elas são geradas não há uma posição aberta de mercado longo. Ambas as ordens são colocadas e quando o preço satisfaz a execução da ordem, ambos são executados. Recomenda-se colocar as ordens em 1 grupo OCA por meio de strategy. oca. cancel. neste caso, apenas uma ordem é preenchida e a outra é cancelada. Aqui está o código modificado:
Se, por algum motivo, as condições de colocação de pedidos não forem cumpridas ao executar o comando, a ordem de entrada não será colocada. Por exemplo, se as configurações de pirâmide estiverem configuradas para 2, a posição existente já contém duas entradas e a estratégia tenta colocar uma terceira, ela não será colocada. As condições de entrada são avaliadas no estágio de geração da ordem e não na fase de execução. Portanto, se você enviar duas entradas de tipo de preço com piramide desabilitado, uma vez que uma delas é executada, a outra não será cancelada automaticamente. Para evitar problemas, recomendamos usar grupos OCA-Cancelar para entradas, então, quando uma ordem de entrada é preenchida, os outros são cancelados.
O mesmo é válido para as saídas do tipo de preço - as ordens serão colocadas uma vez que suas condições sejam atendidas (ou seja, é preenchida uma ordem de entrada com o id respectivo).
Se você aplicar este exemplo a um gráfico, você pode ver que a ordem de saída foi preenchida, apesar do fato de ter sido gerado apenas uma vez antes do pedido de entrada a ser fechado. No entanto, a próxima entrada não foi fechada antes do final do cálculo, já que o comando de saída já foi acionado.
Posição de mercado de fechamento.
Apesar de ser possível sair de uma entrada específica no código, quando os pedidos são mostrados na guia Lista de Trades no StrategyTester, todos eles estão vinculados de acordo com a regra FIFO (primeiro dentro, primeiro fora). Se uma ID de pedido de entrada não for especificada para uma ordem de saída no código, a ordem de saída encerra a primeira ordem de entrada que abriu a posição de mercado. Vamos estudar o seguinte exemplo:
O código indicado acima coloca 2 ordens sequencialmente: "Buy1" a preço de mercado e "Buy2" a um preço 10% maior (ordem de parada). O pedido de saída é colocado somente depois que os pedidos de entrada foram preenchidos. If you apply the code to a chart, you will see that each entry order is closed by exit order, though we did not specify entry order ID to close in this line: strategy. exit("bracket", loss=10, profit=10, when=strategy. position_size == 15)
It opens 5 contracts long position with the order “Buy1”. It extends the long position by purchasing 10 more contracts at 10% higher price with the order “Buy2”. The exit order (strategy. close) to sell 10 contracts (exit from “Buy2”) is filled.
If you take a look at the plot, you can see that average entry price = “Buy2” execution price and our strategy closed exactly this entry order, while on the TradeList tab we can see that it closed the first "Buy1" order and half of the second “Buy2”. It means that the no matter what entry order you specify for your strategy to close, the broker emulator will still close the the first one (according to FIFO rule). It works the same way when trading with through broker.
OCA groups.
It is possible to put orders in 2 different OCA groups in Pine Script:
strategy. oca. cancel - as soon as an order from group is filled (even partially) or cancelled, the other orders from the same group get cancelled. One should keep in mind that if order prices are the same or they are close, more than 1 order of the same group may be filled. This OCA group type is available only for entry orders because all exit orders are placed in strategy. oca. reduce .
You may think that this is a reverse strategy since pyramiding is not allowed, but in fact both order will get filled because they are market order, what means they are to be executed immediately at current price. The second order doesn’t get cancelled because both are filled almost at the same moment and the system doesn’t have time to process first order fill and cancel the second one before it gets executed. The same would happen if these were price orders with same or similar prices. Strategy places all orders (which are allowed according to market position, etc).
The strategy places all orders that do not contradict the rules (in our case market position is flat, therefore any entry order can be filled). At each tick calculation, firstly all orders with the satisfied conditions are executed and only then the orders from the group where an order was executed are cancelled.
strategy. oca. reduce - this group type allows multiple orders within the group to be filled. As one of the orders within the group starts to be filled, the size of other orders is reduced by the filled contracts amount. It is very useful for the exit strategies. Once the price touches your take-profit order and it is being filled, the stop-loss is not cancelled but its amount is reduced by the filled contracts amount, thus protecting the rest of the open position. strategy. oca. none - the order is placed outside of the group (default value for the strategy. order and strategy. entry commands).
Every group has its own unique id (the same way as the orders have). If two groups have the same id, but different type, they will be considered different groups. Exemplo:
“Buy” and “Sell” will be placed in different groups as their type is different. “Order” will be outside of any group as its type is set to strategy. oca. none . Moreover, “Buy” will be placed in the exit group as exits are always placed in the strategy. oca. reduce_size type group.
Gerenciamento de riscos.
It is not easy to create a universal profitable strategy. Usually, strategies are created for certain market patterns and can produce uncontrollable losses when applied to other data. Therefore stopping auto trading in time should things go bad is a serious issue. There is a special group of strategy commands to manage risks. They all start with the strategy. risk.* prefix.
You can combine any number of risks in any combination within one strategy. Every risk category command is calculated at every tick as well as at every order execution event regardless of the calc_on_order_fills strategy setting. There is no way to disable any risk rule in runtime from script. Regardless of where in the script the risk rule is located it will always be applied unless the line with the rule is deleted and the script is recompiled.
If on the next calculation any of the rules is triggered, no orders will be sent. Therefore if a strategy has several rules of the same type with different parameters, it will stop calculating when the rule with the most strict parameters is triggered. When a strategy is stopped all unexecuted orders are cancelled and then a market order is sent to close the position if it is not flat.
Furthermore, it is worth remembering that when using resolutions higher than 1 day, the whole bar is considered to be 1 day for the rules starting with prefix “ strategy. risk. max_intraday_ ”
The position will be closed and trading will be stopped until the end of every trading session after two orders are executed within this session as the second rule is triggered earlier and is valid until the end of the trading session.
One should remember that the strategy. risk. allow_entry_in rule is applied to entries only so it will be possible to enter in a trade using the strategy. order command as this command is not an entry command per se. Moreover, when the strategy. risk. allow_entry_in rule is active, entries in a “prohibited trade” become exits instead of reverse trades.
Example (MSFT 1D):
As short entries are prohibited by the risk rules, instead of reverse trades long exit trades will be made.
TradingView strategies can operate in the currency different from the instrument currency. NetProfit and OpenProfit are recalculated in the account currency. Account currency is set in the strategy properties - the Base Currency drop-down list or in the script via the strategy(. currency=currency.*, . ) keyword. At the same time, performance report values are calculated in the selected currency.
Trade profit (open or closed) is calculated based on the profit in the instrument currency multiplied by the cross-rate on the Close of the trading day previous to the bar where the strategy is calculated.
Example: we trade EURUSD, D and have selected EUR as the strategy currency. Our strategy buys and exits the position using 1 point profitTarget or stopLoss.
After adding this strategy to the chart we can see that the plot lines are matching. This demonstrates that the rate to calculate the profit for every trade was based on the close of the previous day.
When trading on intra-day resolutions the cross-rate on the close of the trading day previous to the bar where the strategy is calculated will be used and it will not be changed during whole trading session.
When trading on resolutions higher than 1 day the cross-rate on the close of the trading day previous to the close of the bar where the strategy is calculated will be used. Let’s say we trade on a weekly chart, then the cross rate on Thursday’s session close will always be used to calculate the profits.
In real-time the yesterday’s session close rate is used.
Estratégias.
A strategy is a study that can send, modify and cancel orders (to buy/sell). Strategies allow you to perform backtesting (emulation of strategy trading on historical data) and forwardtesting (emulation of strategy trading on real-time data) according to your precoded algorithms.
A strategy written in Pine Script language has all the same capabilities as a Pine indicator. When you write a strategy code, it should start with the keyword “ strategy ”, not “ study ”. Strategies not only plot something, but also place, modify and cancel orders. They have access to essential strategy performance information through specific keywords. The same information is available for you on the “Strategy Tester” tab. Once a strategy is calculated on historical data, you can see hypothetical order fills.
A simple strategy example.
As soon as the script is compiled and applied to a chart, you can see filled order marks on it and how your balance was changing during backtesting (equity curve). It is a simplest strategy that buys and sells on every bar.
The first line strategy(“test”) states the code belongs to strategy type and its name is “test”. strategy. entry() is a command to send “buy” and “sell” orders. plot(strategy. equity) plots the equity curve.
How to apply a strategy to the chart.
To test your strategy, apply it to the chart. Use the symbol and time intervals that you want to test. You can use a built-in strategy from the “Indicators & Stratedies” dialog box, or write your own in Pine Editor.
Note: When using non-standard (Renko, Kagi, Line Break, Point and Figure, Heikin Ashi, Spread Charts) types of chart as a basis for strategy, you need to realize that the result will be different. The orders will be executed at the prices of this chart (e. g.for Heikin Ashi it’ll take Heikin Ashi prices (the average ones) not the real market prices). Therefore we highly recommend you to use standard chart type for strategies.
Backtesting and forwardtesting.
On TradingView strategies are calculated on all available historical data on the chart and automatically continue calculation when real-time data comes in.
Both during historical and real-time calculation, code is calculated on bar closes by default.
If this is forwardtesting, code calculates on every tick in real-time. To enable this, check off the option “Recalculate On Every Tick” in settings or do it in script itself: strategy(. calc_on_every_tick=true, . ) .
You can set the strategy to perform additional calculation after an order is filled. For this you need to check off “Recalculate After Order filled” in settings or do it in script itself: strategy(…, calc_on_order_fills=true, . ) .
Broker emulator.
There is a broker emulator on TradingView for testing strategies. Unlike real trading, the emulator fills orders only at chart prices, that is why an order can be filled only on next tick in forwardtesting and on next bar in backtesting (or later) after strategy calculated.
As stated above, in backtesting strategy is calculated on bar’s close. The following logic is used to emulate order fills:
If opening price of bar is closer to highest price of the same bar, the broker emulator assumes that intrabar price was moving this way: Open → High → Low → Close. If opening price of bar is closer to lowest price of the same bar, the broker emulator assumes that intrabar price was moving this way: Open → Low → High → Close. Broker emulator assumes that there were no gaps inside bar, meaning all intrabar prices are available for order execution. If the option “Recalculate On Every Tick” in strategy properties is enabled (or strategy(. calc_on_every_tick=true, . ) is specified in script), code is still calculated only on bar’s close, following the above logic.
Here is the strategy demonstrating how orders are filled by the broker emulator:
This code is calculated once per bar by default, on its close, however there is an additional calculation as soon as an order is filled. That is why you can see 4 filled orders on every bar: 2 orders on open, 1 order on high and 1 order on low. This is backtesting. If it were in real-time, orders would be executed on every new tick.
It is also possible to emulate order queue. The setting is called “Verify Price For Limit Orders” and can be found in strategy properties or set in script itself: strategy(. backtest_fill_limits_assumption=X, . ) . The specified value = number of points/pips (minimum price movements), default value = 0. A limit order is filled if current price is better (higher for sell orders, lower for buy orders) for the specified number of points/pips. The execution price still matches the limit order price.
backtest_fill_limits_assumption = 1. Minimum price movement = 0.25.
A buy limit order is placed at price 12.50.
Current price is 12.50.
The order cannot be filled at current price only because backtest_fill_limits_assumption = 1. To fill the order the price must become 0.25*1 lower. The order is put in queue.
Assume that the next tick comes at price 12.00. This price is 2 points lower, what means the condition “backtest_fill_limits_assumption = 1” is satisfied, so the order should be filled. The order is filled at 12.50 (original order price), even if the price is not available anymore.
Order placement commands.
All keywords that are designed for strategies start with “ strategy .” prefix. The following commands are used for placing orders: strategy. entry , strategy. order and strategy. exit :
strategy. entry — this command places only entry orders. It is affected by pyramiding setting (in strategy properties) and by strategy. risk. allow_entry_in keyword. If there is an open market position when an opposite direction order is generated, the number of contracts/shares/lots/units will be increased by the number of currently open contracts (script equivalent: strategy. position_size + quantity ). As the result, the size of market position to open will be equal to order size, specified in the command strategy. entry . strategy. order — this command places both entry and exit orders. It is not affected by pyramiding setting and by strategy. risk. allow_entry_in keyword. It allows you to create complex enter and exit order constructions when capabilities of the strategy. entry and strategy. exit are not enough. strategy. exit — this command allows you to exit a market position by an order or or form multiple exit order strategy (stop loss, profit target, trailing stop). All such orders are part of the same strategy. oca. reduce group. An exit order cannot be placed if there is no open market position or there is no active entry order (an exit order is bound to ID of an entry order). It is not possible to exit a position with a market order using the command strategy. exit . For this goal the following commands should be used: strategy. close or strategy. close_all . If number of contracts/shares/lots/units specified for the strategy. exit is less than the size of current open position, the exit will be partial. It is not possible to exit from the same entry order more than 1 time using the same exit order (ID), that allows you to create exit strategies with multiple levels. In case, when a market position was formed by multiple entry orders (pyramiding enabled), each exit orders is bound to each entry order individually.
The above strategy constantly reverses market position from +4 to -6, back and forth, what is shown by its plot.
This strategy demonstrates the case, when market position is never closed, because it uses exit order to close market position only partially and it cannot be used more than once. If you double the line for exiting, the strategy will close market position completely.
This code generates 2 levels of brackets (2 take profit orders and 2 stop loss orders). Both levels are activated at the same time: first level to exit 2 contracts and the second one to exit all the rest.
The first take profit and stop loss orders (level 1) are in one OCA group. The other orders (level 2) are in another OCA group. It means that as soon as an order from level 1 is filled, the orders from level 2 are not cancelled, they stay active.
Every command placing an order has ID (string value) — unique order identifier. If an order with same ID is already placed (but not yet filled), current command modifies the existing order. If modification is not possible (conversion from buy to sell), the old order is cancelled, the new order is placed. strategy. entry and strategy. order work with the same IDs (they can modify the same entry order). strategy. exit works with other order IDs (it is possible to have an entry order and an exit order with the same ID).
To cancel a specific order (by its ID) the command strategy. cancel(string id) should be used. To cancel all pending orders the command strategy. cancel_all() should be used. Strategy orders are placed as soon as their conditions are satisfied and command is called in code. Broker emulator doesn’t execute orders before next tick comes after the code was calculated, while in real trading with real broker, an order can be filled sooner. It means that if a market order is generated at close of current bar, it is filled at open oif next bar.
If this code is applied to a chart, all orders are filled at open of every bar.
Conditions for order placement ( when , pyramiding , strategy. risk ) are checked when script is calculated. If all conditions are satisfied, the order is placed. If any condition is not satisfied, the order is not placed. It is important to cancel price orders (limit, stop and stop-limit orders).
Example (for MSFT 1D):
Even though pyramiding is disabled, these both orders are filled in backtesting, because when they are generated there is no open long market position. Both orders are placed and when price satisfies order execution, they both get executed. It is recommended to to put the orders in 1 OCA group by means of strategy. oca. cancel . in this case only one order is filled and the other one is cancelled. Here is the modified code:
If, for some reason, order placing conditions are not met when executing the command, the entry order will not be placed. For example, if pyramiding settings are set to 2, existing position already contains two entries and the strategy tries to place a third one, it will not be placed. Entry conditions are evaluated at the order generation stage and not at the execution stage. Therefore, if you submit two price type entries with pyramiding disabled, once one of them is executed the other will not be cancelled automatically. To avoid issues we recommend using OCA-Cancel groups for entries so when one entry order is filled the others are cancelled.
The same is true for price type exits - orders will be placed once their conditions are met (i. e. an entry order with the respective id is filled).
If you apply this example to a chart, you can see that the exit order has been filled despite the fact that it had been generated only once before the entry order to be closed was placed. However, the next entry was not closed before the end of the calculation as the exit command has already been triggered.
Closing market position.
Despite it is possible to exit from a specific entry in code, when orders are shown in the List of Trades on StrategyTester tab, they all are linked according FIFO (first in, first out) rule. If an entry order ID is not specified for an exit order in code, the exit order closes the first entry order that opened market position. Let’s study the following example:
The code given above places 2 orders sequentially: “Buy1” at market price and “Buy2” at 10% higher price (stop order). Exit order is placed only after entry orders have been filled. If you apply the code to a chart, you will see that each entry order is closed by exit order, though we did not specify entry order ID to close in this line: strategy. exit("bracket", loss=10, profit=10, when=strategy. position_size == 15)
It opens 5 contracts long position with the order “Buy1”. It extends the long position by purchasing 10 more contracts at 10% higher price with the order “Buy2”. The exit order (strategy. close) to sell 10 contracts (exit from “Buy2”) is filled.
If you take a look at the plot, you can see that average entry price = “Buy2” execution price and our strategy closed exactly this entry order, while on the TradeList tab we can see that it closed the first "Buy1" order and half of the second “Buy2”. It means that the no matter what entry order you specify for your strategy to close, the broker emulator will still close the the first one (according to FIFO rule). It works the same way when trading with through broker.
OCA groups.
It is possible to put orders in 2 different OCA groups in Pine Script:
strategy. oca. cancel - as soon as an order from group is filled (even partially) or cancelled, the other orders from the same group get cancelled. One should keep in mind that if order prices are the same or they are close, more than 1 order of the same group may be filled. This OCA group type is available only for entry orders because all exit orders are placed in strategy. oca. reduce .
You may think that this is a reverse strategy since pyramiding is not allowed, but in fact both order will get filled because they are market order, what means they are to be executed immediately at current price. The second order doesn’t get cancelled because both are filled almost at the same moment and the system doesn’t have time to process first order fill and cancel the second one before it gets executed. The same would happen if these were price orders with same or similar prices. Strategy places all orders (which are allowed according to market position, etc).
The strategy places all orders that do not contradict the rules (in our case market position is flat, therefore any entry order can be filled). At each tick calculation, firstly all orders with the satisfied conditions are executed and only then the orders from the group where an order was executed are cancelled.
strategy. oca. reduce - this group type allows multiple orders within the group to be filled. As one of the orders within the group starts to be filled, the size of other orders is reduced by the filled contracts amount. It is very useful for the exit strategies. Once the price touches your take-profit order and it is being filled, the stop-loss is not cancelled but its amount is reduced by the filled contracts amount, thus protecting the rest of the open position. strategy. oca. none - the order is placed outside of the group (default value for the strategy. order and strategy. entry commands).
Every group has its own unique id (the same way as the orders have). If two groups have the same id, but different type, they will be considered different groups. Exemplo:
“Buy” and “Sell” will be placed in different groups as their type is different. “Order” will be outside of any group as its type is set to strategy. oca. none . Moreover, “Buy” will be placed in the exit group as exits are always placed in the strategy. oca. reduce_size type group.
Gerenciamento de riscos.
It is not easy to create a universal profitable strategy. Usually, strategies are created for certain market patterns and can produce uncontrollable losses when applied to other data. Therefore stopping auto trading in time should things go bad is a serious issue. There is a special group of strategy commands to manage risks. They all start with the strategy. risk.* prefix.
You can combine any number of risks in any combination within one strategy. Every risk category command is calculated at every tick as well as at every order execution event regardless of the calc_on_order_fills strategy setting. There is no way to disable any risk rule in runtime from script. Regardless of where in the script the risk rule is located it will always be applied unless the line with the rule is deleted and the script is recompiled.
If on the next calculation any of the rules is triggered, no orders will be sent. Therefore if a strategy has several rules of the same type with different parameters, it will stop calculating when the rule with the most strict parameters is triggered. When a strategy is stopped all unexecuted orders are cancelled and then a market order is sent to close the position if it is not flat.
Furthermore, it is worth remembering that when using resolutions higher than 1 day, the whole bar is considered to be 1 day for the rules starting with prefix “ strategy. risk. max_intraday_ ”
The position will be closed and trading will be stopped until the end of every trading session after two orders are executed within this session as the second rule is triggered earlier and is valid until the end of the trading session.
One should remember that the strategy. risk. allow_entry_in rule is applied to entries only so it will be possible to enter in a trade using the strategy. order command as this command is not an entry command per se. Moreover, when the strategy. risk. allow_entry_in rule is active, entries in a “prohibited trade” become exits instead of reverse trades.
Example (MSFT 1D):
As short entries are prohibited by the risk rules, instead of reverse trades long exit trades will be made.
TradingView strategies can operate in the currency different from the instrument currency. NetProfit and OpenProfit are recalculated in the account currency. Account currency is set in the strategy properties - the Base Currency drop-down list or in the script via the strategy(. currency=currency.*, . ) keyword. At the same time, performance report values are calculated in the selected currency.
Trade profit (open or closed) is calculated based on the profit in the instrument currency multiplied by the cross-rate on the Close of the trading day previous to the bar where the strategy is calculated.
Example: we trade EURUSD, D and have selected EUR as the strategy currency. Our strategy buys and exits the position using 1 point profitTarget or stopLoss.
After adding this strategy to the chart we can see that the plot lines are matching. This demonstrates that the rate to calculate the profit for every trade was based on the close of the previous day.
When trading on intra-day resolutions the cross-rate on the close of the trading day previous to the bar where the strategy is calculated will be used and it will not be changed during whole trading session.
When trading on resolutions higher than 1 day the cross-rate on the close of the trading day previous to the close of the bar where the strategy is calculated will be used. Let’s say we trade on a weekly chart, then the cross rate on Thursday’s session close will always be used to calculate the profits.
In real-time the yesterday’s session close rate is used.
Комментариев нет:
Отправить комментарий