İdeal mekanik ticaret sistemi. - sayfa 5
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
Sana küçük bir ipucu verebilir miyim? :)
...
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 bir ipucu daha alabilirsin, yani. 3. noktayı daha ayrıntılı olarak açıklayın (fiyatın bu logaritması nasıl hesaplanır?)
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.
Ve filtreleme parametreleri yine DC'deki oynaklığa bağlı olacaktır... NA tırnakları için bir filtre yapacaksınız ve sonra DC filtrelerinizin filtrenizden daha fazla olduğu ortaya çıkıyor vb.
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.
Ve filtreleme parametreleri yine DC'deki oynaklığa bağlı olacaktır... NA tırnakları için bir filtre yapacaksınız ve sonra DC filtrelerinizin filtrenizden daha fazla olduğu ortaya çıkıyor vb.
Sonuç olarak, Expert Advisor farklı DC'lerde farklı şekilde çalışacak, ancak farklı şekillerde karlı bir şekilde çalışacaktır... bu nedenle, farklı DC'lerin oranlarındaki fark, pazarın ayrılmaz bir parçasıdır ve görevimizde özel bir rol oynamaz. Yani bazı parametrelere sahip bir ASMTS (otomatik kendini ayarlayan mekanik ticaret sistemi :)) varsa, bir DC'de karlı çalışır, sonra başka bir DC'de karlı olmayabilir.. Sadece başka bir DC'de yeniden yapılandırılır ve çalışır. tekrar karlı. :)
ArtemRG 21.11.2006 14:01 şunu yazdı:
Ve filtreleme parametreleri yine DC'deki oynaklığa bağlı olacaktır... Bir filtre yapacaksınız.
NS alıntı yapar ve ardından DC'nizin filtrenizden daha fazla filtre uyguladığı ortaya çıkar, vb.
Evet, filtrenin belirli bir DC ve hatta daha fazlası için - belirli bir döviz çifti için yapılandırılması gerekebilir.
Ancak görev, tam evrensellik koşulunu içermiyordu, görev çok daha mütevazı:
"Sorun: Aylık geçmişi günde bir kez çalıştıran ve zararı durdurma parametresi için en uygun sayıyı ayarlayan bir işlev 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.
Evrensel bir uyarlanabilir sistem oluşturmak için (mümkünse), yalnızca tek bir DC'nin "gürültünü" değil, çok sayıda parametreyi analiz etmek gerekli olacaktır. Ayrıca, oldukça fazla zaman ve önemli miktarda akıllı kafa alacaktır - sonuç olarak, önemli maliyetler. Ancak bu durumda, her şey çok daha mütevazı. Şu ana kadar Expert Advisor içerisine sadece bir parametreyi analiz edecek bir tester yazmak yeterli oldu.
Kod yazmaya katılın - özellikle bu konuda önemli bir deneyiminiz olduğu için!
Bu yaklaşımın lehine bir başka argüman, danışmanların tarihe ilk kez (uzun bir süre olmasa da) oldukça karlı ticaret yaptıkları varsayımıdır, bana öyle geliyor ki şampiyona bir örnek olabilir - başlangıçta orada çok daha karlı danışmanlardı (bana öyle geliyor ki bu sadece hikayeye uygun olmaları nedeniyle oldu)
İçinde test cihazı olan bir Uzman Danışman yazmadan önce, bu hipotezi manuel olarak test etmeyi deneyin. Son 10 ayın her biri için, önceki 6 ay için bir Uzman Danışmanı optimize edin ve sonucu rapor edin.
keşke herşey bu kadar basit olsaydı...
Bu yaklaşımın lehine bir başka argüman, danışmanların tarihe ilk kez (uzun bir süre olmasa da) oldukça karlı ticaret yaptıkları varsayımıdır, bana öyle geliyor ki şampiyona bir örnek olabilir - başlangıçta orada çok daha karlı danışmanlardı (bana öyle geliyor ki bu sadece hikayeye uygun olmaları nedeniyle oldu)
Tamamen katılıyorum.
Bu yaklaşımın lehine bir başka argüman, danışmanların tarihe ilk kez (uzun bir süre olmasa da) oldukça karlı ticaret yaptıkları varsayımıdır, bana öyle geliyor ki şampiyona bir örnek olabilir - başlangıçta orada çok daha karlı danışmanlardı (bana öyle geliyor ki bu sadece hikayeye uygun olmaları nedeniyle oldu)
İçinde test cihazı olan bir Uzman Danışman yazmadan önce, bu hipotezi manuel olarak test etmeyi deneyin. Son 10 ayın her biri için, önceki 6 ay için bir Uzman Danışmanı optimize edin ve sonucu rapor edin.
keşke herşey bu kadar basit olsaydı...
Kim alacak? (zaman kaybetmemek için)
Hemen söyleyeceğim ki, belirtilen prensibi henüz uygulayamadım, MQL'yi henüz yenemiyorum :).
fikir 4 saat için geliştirildi ve şu şekilde, önce iyi filtrelenmiş bir trend çizgisine ihtiyacınız var, ancak MA gibi geride kalmıyorsunuz, örneğin Vladimir Kravchuk'un FATL'sini alabilirsiniz, sonra türevi ve ikinci türevi hesaplanır, yani. hızlanma ve sarsıntı.
Hem ivmenin hem de sarsıntının sıfırdan büyük olması koşuluyla (yanlış sinyallerden bir tür delta eklemek de mümkündür), o zaman hem ivme hem de sarsıntı sıfırdan küçük olduğunda satın alırız.
sonra satarız.
Ancak aynı zamanda, onları filtrelemek için hala birçok yanlış sinyal olacak, bir koşul öneriyorum, seçilen trend çizgisi (örneğin, FATL) doğru yönde fraktaldan daha büyük, ancak daha küçük bir zaman diliminde .
Aynı zamanda, takip eden stop ile pozisyondan çıkış, pozisyona girişte stop loss, istenen zaman diliminde son gün için mumun gölgeleri ile birlikte ortalama büyüklüğüne eşittir.