İdeal mekanik ticaret sistemi. - sayfa 4
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
Buraya kadar her şey bana çok daha kolay görünüyor. Minimum ayarlarla basit, saf bir sistemle başlamanız gerekir. Ve buna gerçek zamanlı olarak bir parametre değişikliği bloğu ekleyin...
Bu kadar, az kaldı :) Uyarlanabilir parametreleri hesaplamak için hangi verileri kullanacağımıza karar vermemiz gerekiyor. Ne önereceğimi bile bilmiyorum :(
Bu konuda herhangi bir fikri olan var mı?
Aşağıdaki araç modelini önererek başlayabilirim:
Basit bir Uzman Danışman alıyoruz ve ona bir "test" bloğu yazıyoruz (görevi - günde bir kez, örneğin 01:00 GMT'de, TS'yi aylık geçmişe göre ayarlamayı içerecektir).
xeon, test cihazı en azından sürekli çalışır hale getirilebilir. Tabii ki, mql4'te değil, yüksek düzeyde optimize edilmiş C'de yazılması gerekecek. Ne yazık ki, tüm bunlarda çok ciddi bir tuzak var. Yani sistemin değerlendirme ve optimizasyon dönemi. Onlar. Performansını değerlendirmek ne kadar sürer? Gerçek ticaret hakkı için rekabet eden iki stratejimiz olduğunu varsayalım. Başarılı akım ve en kötü yedekleme. Örneğin, bir saat içinde mevcut strateji sızdırılırken, yedek strateji tam tersine başarılı oldu. Soru, stratejileri değiştirmek mi, değiştirmemek mi? Sonuçta bu, hem yeni bir trendin başlangıcı (trend/daire ile karıştırılmamalıdır!) hem de bir kaza olabilir. Onlar. böyle bir test cihazının kendisinin en az bir (ve önemli !!!) ayarlanabilir parametreye sahip olacağı ortaya çıktı - değerlendirme ve optimizasyon süresi. Böyle bir yaklaşımın imkansızlığı hakkında ne dediğimi anlamıyorum. Bütün bunların zorlukları ve sisli yerleri olduğunu söylüyorum.
Yine de basit bir şey deneyelim.
Problem: Aylık geçmişi günde bir kez çalıştıran ve stop loss parametresi için en uygun sayıyı ayarlayan bir fonksiyon yazmak mümkün müdür?
VE EN ÖNEMLİ OLAN: Bu fonksiyonla test cihazını kontrol etmek mümkün müdür? Test cihazı hiç çalışacak mı? Test modunda her gün yeni bir gün için durma parametresini değiştirmesi gerektiği ortaya çıktı? Mümkün mü? Bu sorunu çözerseniz, gerisi daha önce de söylendiği gibi buzlanmadır.
xeon, test cihazı en azından sürekli çalışır hale getirilebilir. Tabii ki, mql4'te değil, yüksek düzeyde optimize edilmiş C'de yazılması gerekecek. Ne yazık ki, tüm bunlarda çok ciddi bir tuzak var. Yani sistemin değerlendirme ve optimizasyon dönemi. Onlar. Performansını değerlendirmek ne kadar sürer? Gerçek ticaret hakkı için rekabet eden iki stratejimiz olduğunu varsayalım. Başarılı akım ve en kötü yedekleme. Örneğin, bir saat içinde mevcut strateji sızdırılırken, yedek strateji tam tersine başarılı oldu. Soru, stratejileri değiştirmek mi, değiştirmemek mi? Sonuçta bu, hem yeni bir trendin başlangıcı (trend/daire ile karıştırılmamalıdır!) hem de bir kaza olabilir. Onlar. böyle bir test cihazının kendisinin en az bir (ve önemli !!!) ayarlanabilir parametreye sahip olacağı ortaya çıktı - değerlendirme ve optimizasyon süresi. Böyle bir yaklaşımın imkansızlığı hakkında ne dediğimi anlamayın. Bütün bunların zorlukları ve sisli yerleri olduğunu söylüyorum.
Yine de basit bir şey deneyelim.
Problem: Aylık geçmişi günde bir kez çalıştıran ve stop loss parametresi için en uygun sayıyı ayarlayan bir fonksiyon yazmak mümkün müdür?
Ve EN ÖNEMLİ: Bu fonksiyonla test cihazını kontrol etmek mümkün müdür? Test cihazı hiç çalışacak mı? Test modunda her gün yeni bir gün için durma parametresini değiştirmesi gerektiği ortaya çıktı? Mümkün mü? Bu sorunu çözerseniz, gerisi daha önce de söylendiği gibi buzlanmadır.
Bildiğim kadarıyla mql'de böyle bir tester fonksiyonu yazmak mümkün ama bu iş benim için kolay değil çünkü "amatör programcı"yım ve bunu yapmak için zamana ihtiyacım var.
Kendinden ayarlı göstergeler çıkmaz sokaktır. Fikrimi doğrulamaya çalışacağım.
Bu tür birkaç gösterge geliştirdim, ancak farklı DC'lerden gelen fiyat tekliflerinin değişkenliğine duyarlı oldukları ortaya çıktı. Yani, bu göstergeler bir DC'nin verileri üzerinde mükemmel şekilde çalışır ve diğerinin verileri üzerinde hiç çalışmaz. En kötüsü, Ulusal Meclis'in verileri üzerinde çalışmak. DC'deki fiyatların ortalama hareketi aynıdır, ancak oynaklık farklıdır, bu da göstergeyi karıştırır. Örneğin, aynı fiyat aralığındaki standart göstergelerde bile, bir DC'de farklılık varken diğerinde değil.
Araştırmam, oynaklığın kendi kendini ayarlayan bir göstergede dikkate alınması gereken önde gelen faktör olduğunu göstermiştir. Bununla birlikte, sonuç olarak, gösterge, farklı DC'lerdeki alıntıları filtreleme yöntemine ve bu yöntemdeki değişikliklere (DC'nin bildirmediği) bağımlı hale gelir.
Burada ayrıca, sabit (doğrusal) olduğu ve kesikli olmadığı için (Renat'ın sürekli bahsettiği) kendi kendine ayarlamayı "kabalaştırmanın" imkansız olduğu gerçeğiyle de karşılaştım.
Oynaklık sorunundan kurtulmanın tek yolunun göstergelerin ve alıntıların mutlak değerlerini dikkate almayı reddetmek olduğuna inanıyorum. Onlar. MTS'de bir karar vermek için, şu ya da bu biçimdeki değerlerin oranı kullanılmalıdır ve bu esasen örüntü tanımadır.
O!
Kendinden ayarlı göstergeler çıkmaz sokaktır. Fikrimi doğrulamaya çalışacağım.
Bu tür birkaç gösterge geliştirdim, ancak farklı DC'lerden gelen fiyat tekliflerinin değişkenliğine duyarlı oldukları ortaya çıktı. Yani, bu göstergeler bir DC'nin verileri üzerinde mükemmel şekilde çalışır ve diğerinin verileri üzerinde hiç çalışmaz. En kötüsü, Ulusal Meclis'in verileri üzerinde çalışmak. DC'deki fiyatların ortalama hareketi aynıdır, ancak oynaklık farklıdır, bu da göstergeyi karıştırır. Örneğin, aynı fiyat aralığındaki standart göstergelerde bile, bir DC'de farklılık varken diğerinde değil.
Araştırmam, oynaklığın kendi kendini ayarlayan bir göstergede dikkate alınması gereken önde gelen faktör olduğunu göstermiştir. Bununla birlikte, sonuç olarak, gösterge, farklı DC'lerdeki alıntıları filtreleme yöntemine ve bu yöntemdeki değişikliklere (DC'nin bildirmediği) bağımlı hale gelir.
Burada ayrıca, sabit (doğrusal) olduğu ve kesikli olmadığı için (Renat'ın sürekli bahsettiği) kendi kendine ayarlamayı "kabalaştırmanın" imkansız olduğu gerçeğiyle de karşılaştım.
Oynaklık sorunundan kurtulmanın tek yolunun göstergelerin ve alıntıların mutlak değerlerini dikkate almayı reddetmek olduğuna inanıyorum. Onlar. MTS'de bir karar vermek için, şu ya da bu biçimdeki değerlerin oranı kullanılmalıdır ve bu esasen örüntü tanımadır.
Herhangi bir sistem için önemli olan fiyat değerleri değil, değişim oranıdır (bazen sadece bir işaret).
Bazen fiyat hızlandırma kullanılır (öncü gösterge olarak fiyata etki eden kuvvetin tahmini).
MTS ile kullanılan TÜM göstergeler aslında hızı değerlendirmek için tasarlanmıştır.
Farklı göstergeler, hızı değerlendirmek için yalnızca farklı SEÇENEKLERDİR.
1. TÜM osilatörler hızı, bazen ivmeyi (MACD gibi) değerlendirir.
2. TÜM hareketli ortalamalar ASLA kendi başlarına kullanılmaz,
sadece diğer hareketli ortalamalarla karşılaştırıldığında (fiyat, uzunluk = 1 olan hareketli bir ortalamadır).
Hareketli ortalamaların bu karşılaştırması (aslında farklarını sıfırla karşılaştırmak) bir osilatördür.
3. Fiyatı değil, fiyatın logaritmasını dikkate almak gerekir.
Logaritmalarda her şey daha basit ve daha doğru hale gelir.
Küçük fiyat değişiklikleri ile fiyat ile çalışmak ile logaritma arasında fark kalmayacak,
büyük fiyat değişiklikleriyle, fark önemli olacaktır.
Sana küçük bir ipucu verebilir miyim? :)
Herhangi bir sistem için önemli olan fiyat değerleri değil, değişim oranıdır (bazen sadece bir işaret).
Bazen fiyat hızlandırma kullanılır (öncü gösterge olarak fiyata etki eden kuvvetin tahmini).
MTS ile kullanılan TÜM göstergeler aslında hızı değerlendirmek için tasarlanmıştır.
Farklı göstergeler, hızı değerlendirmek için yalnızca farklı SEÇENEKLERDİR.
1. TÜM osilatörler hızı, bazen ivmeyi (MACD gibi) değerlendirir.
2. TÜM hareketli ortalamalar ASLA kendi başlarına kullanılmaz,
sadece diğer hareketli ortalamalarla karşılaştırıldığında (fiyat, uzunluk = 1 olan hareketli bir ortalamadır).
Hareketli ortalamaların bu karşılaştırması (aslında farklarını sıfırla karşılaştırmak) bir osilatördür.
3. Fiyatı değil, fiyatın logaritmasını dikkate almak gerekir.
Logaritmalarda her şey daha basit ve daha doğru hale gelir.
Küçük fiyat değişiklikleri ile fiyat ile çalışmak ile logaritma arasında fark kalmayacak,
büyük fiyat değişiklikleriyle, fark önemli olacaktır.
ve belki de kodun yazılmasında yer alabilir mi? :-), programlama deneyiminizle işler çok daha hızlı ilerleyecek!