Critério para a seleção automática dos resultados de otimização. - página 6

 
Figar0 >>:

Т.е. если я правильно понял, как бы оценивать не результат, а качество сделок, насколько сделки отвечают тому, что заложено в систему?

Надо покрутить в голове.

Em geral, sim. O principal é poder ver uma imagem dos ofícios na medida do possível. Mesmo que o filtro perca negócios perigosos, você deve marcá-los de alguma forma e ver as chances de serem acionados. Se o filtro mover os riscos sobre a probabilidade de probabilidade de negócio desencadeando mais próximo do raio do sinal principal, então este filtro será instalado no futuro. E é ruim se ele come uma grande parte das rentáveis. É mais fácil abrir tudo o que está dentro do raio de abertura mais próximo do sinal e tentar mantê-lo. O principal é definir claramente o raio.

 

Se o TS é bem lucrativo, todas as possíveis negociações são abertas e só o drawdown estraga o quadro, então há uma cura para esta doença também...

O principal é ter todos os ofícios diante de seus olhos...

 
A propósito,aqui vai uma reflexão sobre o assunto...
 

Continue lendo, continue lendo...


Esqueci de lhes dizer, a fórmula que dei só é aplicável com um lote proporcionalmente crescente.

 
ivandurak >>:
А как же распределение результатов сделок . Львиная доля прибыли может быть и в начале исследуемого периода .

Eu gosto disso. Nós negociamos em tempo astronômico, não em tempo de carrapato. Um Expert Advisor construído em tempo proporcional ao número de negócios pode mostrar uma linha reta quase ideal, embora seja "não tão boa", para dizer de forma branda: metade do lucro é feito no início, nas primeiras 100 negociações e no primeiro ano, enquanto a outra metade é feita nas últimas 100, mas em cinco anos (também uma linha reta, com a mesma inclinação, pois há aproximadamente a mesma quantidade de negócios bem-sucedidos). Vamos pensar na formalização, algo como a dependência do lucro relativo do sistema em relação ao próprio intervalo de tempo.

É claro que não há e não pode haver um único critério de otimização. Bem, formalmente tal critério pode ser composto de algumas dezenas de vários critérios, mas para que serve?

 
Mathemat >>:


Единого критерия, конечно, нет и не может быть. Ну формально такой можно составить из пары десятков разнородных критериев, но какой от него толк?

Mathemat, posso pedir sua opinião - que limite deve ser estabelecido para os parâmetros: número de negócios, remuneração esperada e rentabilidade em, digamos, otimização por um ano antes de você se preocupar com a filtragem por índice integral? Por exemplo, após rejeitar os resultados: negociações < 50, pagamento esperado < 50 e rentabilidade < 2, não tenho nenhum problema em escolher entre milhares de resultados porque tenho fly-ins aleatórios ou cluster, mas agora é chamado de nuvem. Da nuvem, eu deixo a máquina escolher quem tem o maior Lucro * Rentabilidade / Drawdown em %.

Estou interessado em seu julgamento especializado sobre o número de negócios, pagamento esperado e lucratividade na otimização para o ano.

 

Vita писал(а) >> Я, к примеру, после отметания результатов: сделок < 50; матожидание < 50 и прибыльность < 2 не испытываю пробелемы выбора среди тысячи результатов, т.к. остаются либо случайные залетные, либо кластер, но нынче модно говорить облако. Из облака я для себя позволил автомату выбирать у кого больше Прибыль * Прибыльность / Просадка в %.

Vita, OK em princípio. A pré-seleção é pelo número de acordos, m.o.s. e PF, e a triagem final é por um critério integral bastante decente junto com a "nebulosidade". Ou seja, de fato, todo o procedimento envolve a filtragem por cerca de cinco critérios diferentes.

Os próprios números da pré-triagem (m.o., espera-se que nos antigos pontos completos, ou seja, em quatro dígitos?) são bastante lógicos. Eu provavelmente aumentaria o número mínimo de transações (digamos, para 200) para aumentar a validade estatística dos resultados.

 

A propósito,este artigo é interessante. Gosto da teoria da regressão, pode valer a pena implementar...

Lucro * Lucratividade / Drawdown em %. é bom, mas para o período de teste não afetar o índice de lucro é melhor substituir a porcentagem de lucro por dia (para um lote crescendo proporcionalmente ao saldo), ou índice de lucro por dia (para um lote fixo). Se você não sabe como calcular a porcentagem por dia, aqui está a fórmula:

Pr - porcentagem por dia/por dia de comércio

Dias_Sdelki - número de dias ou transações (dependendo da finalidade, porcentagem da transação ou porcentagem por dia)

Bal_begin - equilíbrio no início do período

Bal_end - equilíbrio no final do período

Pr=(MathExp(((1/Days_Sdelki)*(MathLog(Bal_end/Bal_begin))))-1)*100;

 

ou aqui está a função


double Procent(double Days_Sdelki,double Bal_begin,double Bal_end)
{
if(Days_Sdelki>1 && Bal_begin!=0) return((MathExp(((1/Days_Sdelki)*(MathLog(Bal_end/Bal_begin))))-1)*100);
else return(0);
}

 

Eu introduzi uma variável útil e estou testando uma nova versão da minha fórmula:


PipBar - Pips/Bars (soma das pipas para todos os ofícios dividida pela quantidade de barras utilizadas)

PF - Fator de lucro

SdDDay - número de negócios por dia

ProcDay - porcentagem de lucro por dia (fórmula complexa com logaritmos)

MD - Máximo drawdown

SrD - Média de saques (soma dos saques de cada pedido dividida pelo número de pedidos)


If(PF>3), Vigoda=2*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)));
else Vigoda=(PF-1)*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)));


É uma variante de teste até agora, mas já estou feliz com os resultados...