Lite martingale uzmanı - iyi sonuçlar verir (uzman kodu ektedir) - sayfa 11

 

Aslında daha düşünceli yaklaşırsanız martingale iyi bir şeydir. Kendime benzer bir sistem yaptım, ama biraz farklı.

Bir geri çekilme yakaladığımız için, örneğin ortalama günlük hareketin (ilk ticareti açmak için) %80-100'ü kadar olan yeterli uzunlukta keskin bir NON-RETROL hareketi aramamız gerekiyor. Üstelik bu hareket bir gün içinde gerçekleşmelidir. Ardından, ilk hareketin en az %23'ü kadar bir geri dönüş neredeyse kaçınılmaz olacaktır (minimum fibo seviyesi ... ancak trend boyunca %38 deneyebilirsiniz). Eh, hareket bize karşı devam ederse, o zaman hacimleri kademeli olarak arttırırız (tercihen bazı önemli seviyelerde) ve her zaman artan dalgaya karşı karları %23 seviyesine taşırız. Onlar. sonraki her çekimin uzunluğu yavaş yavaş artar. Buna göre, her yeni işlem için hesaplanan kar hedefinin salınımın uzunluğuyla orantılı olarak artması için hacimlerin doğru hesaplanması gerekir.

Sadece ana özellik, ilk hareketin pratik olarak geri tepmesiz olması gerektiğidir (herhangi bir noktasındaki geri dönüşler, önceki hareketin %20'sini geçmemelidir), bu kontrol edilmelidir.

Elbette bir trendin varlığını ve gücünü de hesaba katmalıyız. Benim için, böyle bir sistemi kar / düşüş oranı açısından test etmenin en kabul edilebilir sonuçları, trendle %23 ve trende karşı %15 hesaplanan hedefle elde edildi.

 
fedor :


İlk başta iyi olan şey şimdi bir felaket.
Hem birinci hem de ikinci durumda, düşüş trendinde bir dizi alım yaptık. Ve burada ve orada, son sipariş öncekileri kapatmadı, büyük olasılıkla, çünkü ichimoku satın alma emrini verdi. Ancak ilk durumda, eğilim yükseldi ve ikincisinde döndü.
Programlamada güçlü değilim ve henüz cevabı bulamadım: nasıl doğru yapılır. Sart'a soru: hata nerede

Sebebi anladığım kadarıyla sekizinci sıra (Order_7) tetiklendiğinde son onuncu limit emrinin (Order_9) açılmamasıdır. Bu, test cihazı günlüğündeki hata 130 (yanlış durdurma) ile kanıtlanır ve sonuç olarak, daha önce açılmış siparişlerde herhangi bir değişiklik yapılmaz (yeni TP ve SL ayarlama). Bu nedenle, fiyat TP ile tersine döndüğünde, yalnızca sekizinci emir (Order_7) kapanır ve emirlerin geri kalanı kapanır - şanslı olarak, yani, yedinci limit emrini açarken daha önce belirlenen TP veya SL ile (Order_6). ), fiyatın nereye gittiğine bağlı olarak.

Bu şekilde ortaya çıkıyor çünkü SL seviyesini ayarlamak için bir sonraki limit emrini açarken, tabiri caizse, emir dizisinden bir sonraki emrin parametreleri, yani bu durumda, onuncu limit emrini açmak için kullanılır. (Order_9), basitçe var olmayan Order_10_Level değişkenine ihtiyacınız var.

_OrderStopLoss [i] = _OrderOpenPrice[i] - TradeCycleDirectin * OrderLevel[i+1] * Puan;

Bence diziyi 11'e veya daha fazlasına çıkarıp Order_10_Level ve Order_10_Lots değişkenlerini ekleyerek durum düzeltilebilir, vb... Gerçi bu prensipte "aksaklığı" ortadan kaldırmaz. Sadece "daha iyi zamanlara" ertelendi... :) Uzun süreli düşük geri tepme eğilimi konusu hala açık.

Not: Ticarette yeniyim ve programlama benim için daha çok bir hobi. Bu nedenle, bir şey yanlışsa beni düzeltin.

Samimi olarak. Evgeny.

 
jinn2000 :

Not: Ticarette yeniyim ve programlama benim için daha çok bir hobi. Bu nedenle, bir şey yanlışsa beni düzeltin.

İlk önce, gereksiz metni tırnaklardan nasıl çıkaracağınızı öğrenin...
 

Bir hata yaptı. Order_7'yi kapattıktan sonra tabiri caizse "şanssız" olması durumunda, sonraki emirler açılmaya devam eder ve zaten açık olan emirler değiştirilir. Böylece tüm sipariş partisi, Order_6'nın açılışında ayarlanan SL'ye göre değil, çok daha büyük bir kayıpla kapatılacaktır. Yine de bu, konunun özünü değiştirmez.

Samimi olarak. Evgeny.

 
komposter :
cin2000 :

Not: Ticarette yeniyim ve programlama benim için daha çok bir hobi. Bu nedenle, bir şey yanlışsa beni düzeltin.

İlk önce, gereksiz metni tırnaklardan nasıl çıkaracağınızı öğrenin...

Tavsiye için teşekkürler. Gelecek için öğrenin.
 
Soru şu ki, neden bir sürü Order__..._Level ve Order__..._Lots değişkeniyle uğraşıyorsunuz?
Bu değerler programda belirli bir algoritmaya göre hesaplanmalı ve öyle alınmamalıdır.
 
Meat :
Soru şu ki, neden bir sürü Order__..._Level ve Order__..._Lots değişkeniyle uğraşıyorsunuz?
Bu değerler programda belirli bir algoritmaya göre hesaplanmalı ve öyle alınmamalıdır.
Elbette, ama hangi algoritmaya göre? Bu algoritmayı bilseydim, tam da bunu yapardım. Belki bir fikir ve aynı zamanda belki de düşük geri tepme trendleriyle mücadele fikrini atacaksınız.
 
Sart :
Elbette, ama hangi algoritmaya göre? Bu algoritmayı bilseydim, tam da bunu yapardım.

Order__..._Level değişkenlerinin toplam değerinin, belirli bir enstrümanın geçmişindeki kısa düzeltme periyotlarının genliği ile orantılı olması arzu edilir. Doğru, ne kadar çok sigorta yaparsanız, danışmanın karlılığı o kadar düşük olur.

 
Sart :
Belki bir fikir, ... ve düşük geri tepme trendleriyle mücadele etme fikrini atarsınız.
Bu, piyasa yapıcılar içindir - tüm ortalama MTS'leri periyodik olarak öldüren trendler çizerler :)
 
jinn2000 :

Order__..._Level değişkenlerinin toplam değerinin, belirli bir enstrümanın geçmişindeki kısa düzeltme periyotlarının genliği ile orantılı olması arzu edilir. Doğru, ne kadar çok sigorta yaparsanız, danışmanın karlılığı o kadar düşük olur.


Ancak bu "kısa düzeltme dönemlerinin" hem genliği hem de süresi çok istikrarsızdır :) Ve iyi bir sigorta ile (%100'e yakın), ortalama teknolojiler yıllık ortalama %10'luk bir kâr verir. Neredeyse bir bankada olduğu gibi, ancak risk hala daha fazla :)