Optimizasyon sonuçlarının otomatik seçimi için kriterler. - sayfa 6

 
Figar0 >> :

Onlar. Doğru anladıysam sonucu değil, işlemlerin kalitesini nasıl değerlendireceğim, işlemler sisteme dahil olanlarla ne kadar örtüşüyor?

Bunu kafanda çevirmelisin.

Genel olarak, evet. Ana şey, işlemlerin resminin mümkün olduğunca görünür olmasıdır. Filtre, tehlikeli işlemlerin geçmesine izin verse bile, onları bir şekilde işaretlemek ve tetikleme şansının ne olduğunu görmek gerekir. Filtre, ana sinyalin yarıçapına daha yakın tetikleme olasılığı ile riskleri ortadan kaldırırsa, gelecekte böyle bir filtre değiştirilecektir. Ve kârlı olanların büyük bir kısmını yerse kötü olur. Açmak için sinyalin en yakın yarıçapındaki her şeyi açmak ve onu tutmaya çalışmak daha kolaydır. Ana şey, yarıçapı açıkça tanımlamaktır.

 

TS iyi kârlıysa, olası tüm anlaşmalar açılır ve sadece bir düşüş resmi bozarsa, o zaman bu hastalığın da bir tedavisi var...

Ana şey, tüm işlemlerin gözünüzün önünde olmasıdır ...

 
Bu arada konu hakkındaki düşüncelerim bunlar...
 

Saygı duyuyoruz, saygı duyuyoruz...


Söylemeyi unuttum, verdiğim formül ancak orantılı olarak artan bir parti ile uygulanabilir.

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

Beğendim. Astronomik zamanla işlem yapıyoruz, saatle değil. Anlaşma sayısıyla orantılı olarak zaman içinde inşa edilmiş bir Uzman Danışman, en hafif tabirle "pek değil" olacak olsa da neredeyse mükemmel bir düz çizgi gösterebilir: tüm kârların yarısı başlangıçta, ilk 100 işlemde ve ilk 100 işlemde elde edildi ve ilk yıl ve ikinci yarı için - son 100'de, ancak zaten beş yıldır (aynı eğimle düz, çünkü yaklaşık aynı sayıda başarılı işlem var). Resmileştirme hakkında, sistemin göreli kârının zaman diliminin kendisine bağımlılığı gibi bir şey hakkında düşünelim.

Elbette tek bir optimizasyon kriteri yoktur ve olamaz. Eh, resmi olarak, bu birkaç düzine heterojen kriterden oluşabilir, ama bunun faydası nedir?

 
Mathemat >> :


Elbette tek bir kriter yoktur ve olamaz. Eh, resmi olarak, bu birkaç düzine heterojen kriterden oluşabilir, ama bunun faydası nedir?

Mathemat, fikrinizi alabilir miyim - parametrelere hangi eşik uygulanmalı: işlem sayısı, matematiksel beklenti ve örneğin entegre bir gösterge kullanarak filtrelemeye başlamadan önce bir yıl boyunca optimizasyon ile karlılık? Örneğin, sonuçları süpürdükten sonra: işlemler < 50; beklenti < 50 ve karlılık < 2 ya rastgele başıboşlar ya da bir küme kalıyor, ama şimdi bir bulut demek moda oldu. Buluttan, makinenin % olarak daha fazla Kâr * Kâr / Düşüşe sahip olanı seçmesine izin verdim.

Yıl için optimizasyon yaparken işlem sayısı, beklenti ve karlılık ile ön tarama hakkında uzman görüşünüzü merak ediyorum.

 

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

Vita , normalde prensipte. Ön eleme - anlaşma sayısına göre, m.o. ve PF ve son eleme - "bulutluluk" ile birlikte oldukça iyi bir integral kriterine göre. Onlar. aslında, tüm prosedür yaklaşık beş farklı kritere göre filtrelemeyi içerir.

Ön tarama sayılarının kendileri (m.o., umarım, eski tam teşekküllü noktalarda, yani dört basamaklı?) oldukça mantıklıdır. Sonuçların istatistiksel güvenini artırmak için muhtemelen minimum işlem sayısını (örneğin 200'e kadar) artırırdım.

 

Bu arada, işte ilginç bir makale. Regresyon teorisini beğendim, uygulamaya değer ...

Kar * Kar / Düşüş % cinsinden . bu iyidir, ancak test süresinin kar göstergesini etkilememesi için, günlük kâr yüzdesi (bakiyeyle orantılı olarak büyüyen çok şey için) veya günlük kâr göstergesi ile değiştirmek daha iyidir ( sabit bir lot için). Birisi günlük yüzdeyi nasıl hesaplayacağını bilmiyorsa, formülü önereceğim:

Pr - günlük/ticaret başına yüzde

Days_Sdelki - gün veya işlem sayısı (hesaplama amacına, işlem yüzdesine veya günlük yüzdeye bağlı olarak)

Bal_begin - dönemin başındaki bakiye

Bal_end - dönem sonundaki bakiye

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

 

veya işte fonksiyon


double Percent(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);
başka dönüş (0);
}

 

Kullanışlı bir değişken ekledim ve formülümün yeni bir sürümünü test ediyorum:


PipBar - pip/bar (bu durumda tüm işlemler için pip toplamının kullanılan bar miktarına bölümü)

PF - karlılık (Kar Faktörü)

SdDay - günlük işlem sayısı

ProcDay - günlük kar yüzdesi (logaritmalı karmaşık formül)

MD - Maksimum Düşüş

SrD - Ortalama düşüş (her siparişin düşüşlerinin toplamının sipariş sayısına bölümü)


if(PF>3) Vigoda=2*SdDay+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)));
başka Vigoda=(PF-1)*Gündüz+(PipBar/10)+(10*(ProcDay/((MD+SrD)/10)));


şimdiye kadar bir test versiyonu, ancak göstergeler zaten memnun edici ...