Criterio de selección automática de los resultados de la optimización. - página 6

Nuevo comentario
 
Figar0 >>:

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

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

En general, sí. Lo principal es poder ver una imagen de los oficios en la medida de lo posible. Incluso si el filtro pasa por alto las operaciones peligrosas, debería marcarlas de alguna manera y ver las posibilidades de que se activen. Si el filtro desplaza los riesgos sobre la probabilidad de activación del trato más cerca que el radio de la señal principal, entonces este filtro se establecerá en el futuro. Y es malo si se come una gran parte de los rentables. Es más fácil abrir todo lo que está dentro del radio de apertura más cercano a la señal y tratar de mantenerlo. Lo principal es definir claramente el radio.

 

Si el TS es bien rentable, se abren todas las operaciones posibles y sólo el drawdown estropea el panorama, entonces también hay una cura para esta enfermedad...

Lo principal es tener todos los oficios delante de los ojos...

 
Por cierto,aquí hay una reflexión sobre el tema...
 

Sigue leyendo, sigue leyendo...


Se me olvidó decirte que la fórmula que di sólo es aplicable con un lote proporcionalmente creciente.

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

Me gusta. Negociamos en tiempo astronómico, no en tiempo de tictac. Un Asesor Experto construido en tiempo proporcional al número de operaciones puede mostrar una línea recta casi ideal, aunque será "no tan buena", por decirlo suavemente: la mitad del beneficio se obtiene al principio, en las primeras 100 operaciones y en el primer año, mientras que la otra mitad se obtiene en las últimas 100, pero en cinco años (también una línea recta, con la misma pendiente, porque hay aproximadamente la misma cantidad de operaciones exitosas). Pensemos en la formalización, algo así como la dependencia de la ganancia relativa del sistema en el propio intervalo de tiempo.

Por supuesto, no hay ni puede haber un único criterio de optimización. Bueno, formalmente es posible hacer un criterio de este tipo a partir de un par de docenas de criterios diversos, pero ¿de qué sirve?

 
Mathemat >>:


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

Mathemat, ¿puedo pedirle su opinión - qué umbral debería establecerse para los parámetros: número de operaciones, pago esperado y rentabilidad en, digamos, la optimización durante un año antes de preocuparse por el filtrado por índice integral? Por ejemplo, después de rechazar los resultados: operaciones < 50, pago esperado < 50 y rentabilidad < 2, no tengo ningún problema para elegir entre miles de resultados porque tengo o bien volantes aleatorios o bien cluster, pero ahora se llama nube. Desde la nube, dejo que la máquina elija quién tiene el mayor Beneficio * Rentabilidad / Drawdown en %.

Estoy interesado en su opinión de experto sobre el número de acuerdos, el pago esperado y la rentabilidad durante la optimización para el año.

 

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

Vita, en principio está bien. La preselección es por el número de tratos, m.o.s. y PF, y la selección final es por un criterio integral bastante decente junto con la "nubosidad". De hecho, todo el procedimiento consiste en filtrar por unos cinco criterios diferentes.

Las propias cifras de la preselección (m.o., espero que en los antiguos puntos completos, es decir, a cuatro dígitos...) son bastante lógicas. Probablemente aumentaría el número mínimo de transacciones (por ejemplo, a 200) para aumentar la validez estadística de los resultados.

 

Por cierto,este artículo es interesante. Me gusta la teoría de la regresión, puede valer la pena implementarla...

Beneficio * Rentabilidad / Drawdown en %. está bien, pero para que el periodo de prueba no afecte al índice de beneficio es mejor sustituir el porcentaje de beneficio por día (para un lote que crece proporcionalmente al saldo), o el índice de beneficio por día (para un lote fijo). Si no sabes cómo calcular el porcentaje por día, aquí tienes la fórmula:

Pr - porcentaje por día/por operación

Days_Sdelki - número de días o transacciones (según el propósito, el porcentaje de la transacción o el porcentaje por día)

Bal_begin - saldo al principio del periodo

Bal_end - saldo al final del periodo

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

 

o aquí está la función


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);
}

 

He introducido una variable útil y estoy probando una nueva versión de mi fórmula:


PipBar - Pips/Bars (suma de pips para todas las operaciones dividida por la cantidad de barras utilizadas)

PF - Factor de beneficio

SdDay - número de ofertas por día

ProcDay - porcentaje de beneficio por día (fórmula compleja con logaritmos)

MD - Reducción máxima

SrD - Drawdown medio (suma de los drawdowns de cada orden dividida por el número de órdenes)


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


De momento es una variante de prueba, pero ya estoy contento con los resultados...

12345678910
Nuevo comentario