Ticaret Sistemleri Birliği. Çalışmaya devam ediyoruz. - sayfa 192
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Onlara neden izin verilmiyor? TP takibinin tam olarak bu koşullar altında fiyatı “yakalayacağı” ortaya çıkarsa, hangi işlev tam olarak günlük 0,8 aralık kaybıyla bir işlemin kapatılmasına izin vermez?
Rezervasyon yaptım.
Bu, günlük 0,8'lik bir kayıptan sonra - 6 işlemden sonra, yeni bir zirve için çok uzun süre beklememiz nedeniyle alım satımdan çekilme olması gerektiği anlamına geliyordu.
Zorsun... :-)
Aynı yerde, sohbetten sonra, Hisse Senedi ve yukarısı ile bir uçuş mümkün!!!?!!!
Birleştirme başlatıcıları yok oluyorsa, o zaman - evet. Tabii ki - siz daha iyi bilirsiniz ... Daha fazla gözlemliyoruz ...
Mevcut.
Ancak iki yıl üst üste böyle olmadı. Ve "kalkış zirvesini" bekleyeceğiz ??? Elbette mümkün, ama bence "aşağı inme" olasılığı daha yüksek.
Rezervasyon yaptım.
Bu, günlük 0,8'lik bir kayıptan sonra - 6 işlemden sonra, yeni bir zirve için çok uzun süre beklememiz nedeniyle alım satımdan çekilme olması gerektiği anlamına geliyordu.
Bu kadar.
643642 örneğini ele alalım. Optimizasyon sırasında önemli bir kaybı olmadı (aralığın 0,6'sından büyük bir kayıp olmadı).
Alım satım sırasında, kolayca 0,6'dan fazla bir kayıp meydana gelebilir (bu, gerçek keneler üzerinde çalışırken görülebilir). Menzilin 0,6'sından fazla bir kayıp olması durumunda, TS'yi geri kazanma şansından mahrum bıraktığınız ortaya çıktı. Ve bu, yine gerçek keneler üzerinde çalışırken görülebilen mantıklı değil. Bu kayıp, sistemin çalışmayı durdurduğu anlamına gelmez, sadece OHLC'de modellenmemiştir. TS'nin önemli bir kayıp alır almaz, maksimumun güncellenmemesi nedeniyle müzayededen otomatik olarak çekileceği ortaya çıktı.
BENİM NACİZANE FİKRİME GÖRE. aracın bir yerde ezilmesini ve bir kayıp sonrası toparlanmasını bir şekilde ayırmak gerekir. Örneğin, n-ticaret için ortalama karlılık kriterini getirerek.
Gerçek keneler üzerinde optimizasyondan sonra kontrol etmenin TS davranışının gizli yönlerini anlamak için faydalı olabileceğine hâlâ katılmıyor musunuz?
Bu kadar.
643642 örneğini ele alalım. Optimizasyon sırasında önemli bir kaybı olmadı (aralığın 0,6'sından büyük bir kayıp olmadı).
Alım satım sırasında, kolayca 0,6'dan fazla bir kayıp meydana gelebilir (bu, gerçek keneler üzerinde çalışırken görülebilir). Menzilin 0,6'sından fazla bir kayıp olması durumunda, TS'yi geri kazanma şansından mahrum bıraktığınız ortaya çıktı. Ve bu, yine gerçek keneler üzerinde çalışırken görülebilen mantıklı değil. Bu kayıp, sistemin çalışmayı durdurduğu anlamına gelmez, sadece OHLC'de modellenmemiştir. TS'nin önemli bir kayıp alır almaz, maksimumun güncellenmemesi nedeniyle müzayededen otomatik olarak çekileceği ortaya çıktı.
Tam olarak modellenmemiş olduğu için sistemin ticaretten kaldırılması gerekir.
Ticaretten çekilme sebebinin özü: sistem tarihte olduğundan farklı davranıyor. Ve bunun neden olduğu önemli değil - ya test sırasında bir şeyi hesaba katmadık ya da piyasa değişti ya da algoritmanın kendisinde bir hata yapıldı.
Sistemin ticaretten çekilmesine neden olan kayıp tesadüfi ise, bir gün içinde sistem yeniden optimize edilecek ve yeniden optimizasyon sonuçları kesinlikle gerçek ticaret sonuçlarından daha iyi olacak ve hemen başlayacaktır. öncekiyle aynı sonucu göstermek için. Ayrıca, bölüm bir rol oynamaz, rapor için istatistik toplayan komut dosyası tüm bölümler için aynı anda toplar, ancak elbette yalnızca Yüksek Bölümden araçlar Zirveye çıkar, çünkü Bölümden gelen araçlar en kısa sürede Orta veya Alt Bölüm, Yüksek Bölüm'ün kaliteli ticaretini göstermeye başlar - hemen ona aktarılır.
Yani, sen, Eduard, bu TS senin için çok değerliyse, o zaman kaybettiğin maksimum 10 işlemdir. Bunun bir "altı" olduğu göz önüne alındığında, işlemlerinin her biri çok küçüktür. Peki, yeniden optimizasyondan sonra araç hemen Üst Bölüme girdiğinde ilgilenenlere haber vermeyi unutmamaya çalışacağım.
Şu anda Üst Bölümde 90 araç işlem görüyor.
BENİM NACİZANE FİKRİME GÖRE. aracın bir yerde ezilmesini ve bir kayıp sonrası toparlanmasını bir şekilde ayırmak gerekir. Örneğin, n-ticaret için ortalama karlılık kriterini getirerek.
O bölünmedi mi?
Bak, tam iki yıldır sistemin nasıl çalıştığını kontrol ediyoruz. Ve en uzun iyileşme dönemini alıyoruz. Gerçek ticarette TS'nin iyileşmesi daha uzun sürerse, bu TS'nin istendiği gibi çalışmadığının açık bir işaretidir (tekrar ediyorum, bunun nedeni bizim için önemli değil).
Gerçek keneler üzerinde optimizasyondan sonra kontrol etmenin TS davranışının gizli yönlerini anlamak için faydalı olabileceğine hâlâ katılmıyor musunuz?
Konuyu anlamadım. Olanlar için, bir daha asla olmayacak.
Ancak, kimse bunu kendiniz yapmanıza engel değil. Herhangi bir kısıtlama olmaksızın herhangi bir araç, herhangi bir kayıt kodu olmadan test cihazında çalışır.
Günlük bu kod hakkında ne diyor? Geçersiz???
Kontrol ettim ve her şey çalışıyor gibi görünüyor ...
Konunun normal kodda olmadığını önermeye cüret ediyorum.buraya koydum
burada uçar
reg koduna yemin ediyor
Hesap: 2599118
Büyü: 542041
Kayıt Kodu: 3265001878
koymak
kene gelişiyle - uçtu ...
işte günlük
Roman, sihir üzerine yemin ediyor. 542041'in yapı tarihi 06/12/2019 Yürütülebilir modülünüz Haziran'dır. Tahminimce, bu yürütülebilir dosya oluşturulduğunda 542041 henüz mevcut değildi.
Daha yeni bir modül alın, çalışması gerekir.
Konuyu anlamadım. Olanlar için, bir daha asla olmayacak.
Peki, o zaman geçmişi optimize etmenin anlamı nedir?
Teknik olarak mümkün olsaydı (zaman maliyetleri açısından), genellikle her şeyi yalnızca gerçek keneler üzerinde optimize ederdim.