ideal filtre - sayfa 6

Orman incelemeleri için teşekkürler. Maalesef mql 4 bilmiyorum, mql 5 ile hemen çalışmaya başladım ama indikatör koduna bakarsanız eminim 4 altında rahatlıkla uygulayabilirsiniz orda herşey çok basit.

PS 1.01 sürümünde, göstergenin tık tık yeniden çizilmesini devre dışı bırakmak için bir öznitelik eklenmiştir, böylece yalnızca çubuk bittiğinde çizilir.

Eh, bu kadar, ben tatmin olduğum bir şeyi karıştırdım, en azından bir pazorchik hissetmiyorum. Genel olarak, görünümden memnun olsam da, şimdi trendden düze ve tam tersine geçişlerde doğru bir şekilde mikslemek için volatilite ve trend/flat filtresini kuracağım ve güzel bir uyarlama yapacağım, çirkinlik değil. klasik AMA.

İlgilenenler için ekte 1.12. ZZ ve renk bununla ilgili değildi, çünkü bu hala sadece ilk aşama, uyarlanabilirliği niteliksel olarak nasıl çamurlayacağımı bulduğumda, bitmiş olanı göndereceğim.

İlk seçenek daha iyidir (kod tabanındadır). Bunda zaten remix yaptınız ... IMHO

Sadece okuyun, şube bir zevktir! Başta topikstarter olmak üzere tüm katılımcılara çok teşekkür ederiz. Kendim filtrelerle hiç ilgilenmedim ama sanırım bu konu üzerinde biraz sesli düşünmek iyi gelecek.

Burada, filtrenin kalitesinin nicel bir özelliğini arama sorunu tekrar tekrar ortaya çıktı. Gerçekten de hangisi daha iyi, JJMA veya EMA ve ne kadar? Belirli bir miktarda filtre gecikmesi var, nasıl ölçülür ve ne işe yarar? Genel olarak, bu tür sorular mantıklarında normaldir.

Tabii ki, filtre kırılmaları üzerine inşa edilmiş ZigZag dizlerinin toplamı aracılığıyla basit bir yöntemi de dile getirdiler. Her şey neredeyse iyi, ama tam olarak değil.

Değerli yazarlar, filtre karşılaştırma yöntemleriniz olduğundan, bu karşılaştırmalar için grafik, tablo veya diğer teknik verileri sağlayabilir misiniz? Ayrıca, ZigZag'leri toplarsanız, her dizden yayılma değerini çıkaralım. Filtrenin periyoduna bağlı olarak nicel özelliklerin bir grafiğini oluşturun. Farklı filtrelerin ortaya çıkan grafiklerini üst üste koyun ve her ikisinin de artılarını ve eksilerini değerlendirin.

Ve yine, peki, neden bu kadar güçlü bir şekilde genelliyorsunuz: tüm zamanlar için bir filtre? Filtrenizin akşamları zarif davrandığını ve diğer zamanlarda çok yanlış olduğunu hayal edin. Vay, bu filtre harika! Ancak hastanedeki ortalama sıcaklığın yaklaşması nedeniyle bunu reddedeceksiniz.

Tamam, düşünceler akıyor, mektuplar yetmiyor. Ayrıca daha genel bir yaklaşım sunuyorum - Araştırma yöntemlerinden biri :

Ve bir acil istek daha, CVR'deki farklılıkları göz önünde bulundurun. Örneğin, filtreniz EURUSD'de saçmalık gösterebilir ve GBPJPY'de harika olabilir. Bu tür farklılıklar gözlemlenirse, EURUSDvsGBPJPY konusuna girmek mantıklıdır. Genel olarak, kazılacak çok yer var.

Teşekkür ederim! Filtrenin verimliliğini hesaplamak için algoritmayı anlamak ve resmileştirmek için, bu konudaki mantığın amacı budur, filtrenin kendisi önemsizdir, farklı pazarlar için farklı filtrelerin etkinliği ve bunun üzerinde kümelenme yapacak olan kriterdir. farklı piyasa duyarlılıkları için keskinleştirilmiş farklı TS'ler arasındaki geçiş noktasını şu veya bu zamanda hesaplamanıza izin verir. Plan bu.

Toplayıcıdaki yayılmayı hesaba katmayı çoktan düşündüm, bu zaten belirli bir DC'yi ve alıntılarını dikkate alarak ek bir zil ve ıslık, sistemin her bir unsurunun orta derecede özerk olması için sorunları sürekli olarak çözmeye çalışıyorum, bu yüzden tabiri caizse, her bir unsurun “net katkısını” anlamanın ve ardından kümülatif etkiyi analiz etmenin mümkün olduğunu.

Ama hala çok zayıf bir programcıyım ve kodlama hızı iç karartıcı, sürekli dizinin ötesine geçmekle ve yeni bir gösterge hesaplama arabelleği kaydetmediğim için sürekli mücadele ediyorum. Dolayısıyla teknik arızalara ve aracın mimarisini düşünmemeye harcadığım zamanın %99,9'unu bu üzücü ama görünüşe göre kaçınılmaz.

Lütfen, sakıncası yoksa , dizinin dışında ters çevirmeyi hariç tutmak için herhangi biri tarafından hangi yöntemlerin veya buluşsal yöntemlerin kullanıldığını söyleyin? Çünkü hangi döngüden, hangi elemente göre düşünmek bana göre koşer değil. Örneğin, geçersiz değerlerin ve döngü dışındaki çağrıların ihlal etmemesi mümkün mü? mantık? Diyelim ki 0'a bölme hata vermiyor, ancak örneğin, 1000 gibi büyük bir değer kabul edilebilir ve dizinin ötesine erişim, dizinin erişim noktasına en yakın olan kenarından bir öğe mi veriyor?

Öyle ... yeni başlayanların düşünceleri, bunun muhtemelen cesur olmadığını, hatta bu yönde düşünmek utanç verici olduğunu anlıyorum))) Ama beni bağışlayın, ne yazık ki çok dikkatli değilim. Yapıları oluşturmak benim için onları uygulamaktan daha kolay, ancak her küçük şey için kodlama sipariş edersem, o zaman batarım. Küçük testler yine de kendiniz yapmak daha iyidir.

Basmakalıpları hiç kırmamak için yayılmadan bahsetti. Aslında yayılma yok. Sadece Bid and Ask VR var. Ayrıca ZigZag'lar da oluşturun, ancak yalnızca Bid ВР'da en üstte ve ВР'da Sor'da düşük. Daha sonra dizlerin miktarı " yüzen yayılma "yı hesaba katacaktır. Bu, göründüğü gibi, gerçekten sıkıcı değil. Ve bunu yapmamanın nerede mümkün olacağını süper doğru bir şekilde hesaplama arzusu değil. İşte temel bir nokta: oldukça doğru olsa da çok sık kırıklar - kötü çünkü. kârsız.

Ben de kötü bir programcıyım. Bu nedenle, MQL'de bu tür çalışmaların yapılmaması yönünde bir öneri vardır. MQL'yi yalnızca bir veri kaynağı ve basit bir görselleştirme olarak kullanın. Ve araştırma için bir mat alın. paket. Çok zaman ve emekten tasarruf edin.

Teklif ve Satış verileri FXOPEN ECN veya FXCM veya Dukascopy'den veya herhangi bir onay kaynağından alınabilir. Hız ve doğruluk arasında bir uzlaşma olarak yalnızca M1'i alın. Anladığım kadarıyla, neredeyse hiç kimse rahatsız olmayacak ve MQL çerçevesinde kalmaya devam edecek. Ama burada sadece kendinize cevap vermeniz, keşfetmeniz veya oynamanız gerekiyor.

Teşekkür ederim! Deneyeceğim))

Tavsiye için teşekkürler! Aslında geçmişe dönük olarak zaten takip ediyorum)) STATICTICA'yı sayısal araştırmalar için kullanıyorum ve Matlab , görselleştirmeler ve bazı süslü sideFX hesaplamaları için Houdini . Ancak yine de, tamamen özel bir şeyin vektörler (diziler) ve bileşenleriyle döngüler halindeki işlemler düzeyinde kodlanması gerekir. Bu nedenle, ister istemez, mt 5 için mql 5 ve büyük olasılıkla C# öğrenmeniz gerekecek.

Aşağıdaki nedenlerle benim için önem sırasına göre seçilen 5. oldu:

1) mql 5 analog C++

  Ve C++ günümüzün en gelişmiş programlama dilidir ve aşırı durumlarda bile pazarlama yetersizlikleri nedeniyle mt 5 kök salmazsa, o zaman en az acısız saf C++ kodlamasına geçmek mümkün olacaktır. Ve bu deneyim kaybolmayacak.

Tabii ki, OOP, havalı bir arabanın kaputunun altındaki güç gibi, yapısal olarak karmaşık projeleri uygulama yeteneğinden memnun olan C benzeri 4. modelin aksine. Prosedürel dilde, benim dikkatimi ve planladığım projelerin yapısal iç içe geçmesini göz önünde bulundurarak beyinden başlamak mümkün olacak.

2) Mt'nin 5. son sürümü mt .

  Mql'nin sonraki sürümlerinin de artılara dayalı olması ve mt 5'in borsalara terfi etmesi büyük bir mutlak artı ve DC'lerin kitlesel olarak 5'e geçmediği gerçeği, bence, bir geçici fenomen

Genel olarak, fikirleri uygulamak için mql 5 ve C# öğrenme ihtiyacı hissediyorum. Kodlayıcılara bazı fikirleri sipariş etme deneyimim zaten var, ancak yalnızca kabuğu sipariş etmenin mantıklı olduğu sonucuna vardım. Ve tahmin bloklarını ve MM'yi kendiniz yapın. Bu nedenle, yetkin bir şekilde görevler vermek ve projeleri doğru bir şekilde taklit etmek / yönlendirmek için en azından dil öğrenmeniz gerekecektir. Bu elbette şu anda sadece IMHO.

Açıkçası, garip bir vizyon. Dvr araştırması herhangi bir platform veya dil ile nasıl ilişkilidir? Sadece araştırma. Kağıt üzerinde mümkündür, C benzeri bir dilde ve haklı olarak belirttiğiniz gibi bazı matlarda mümkündür. paketler. Aynı zamanda, üçüncü taraf verilerini ve DLL'leri programlama ve içe aktarma yeteneğine sahiptirler. Araştırma ve ticaret tamamen farklı faaliyetlerdir.

Oynamak, değerli zamanınızı bir programlama dili aracılığıyla sıfırdan bir araştırma altyapısı oluşturmak için harcamaktır.

Tabii ki, tartışmayacağım ve ikna etmeyeceğim. Yine de araştırma konusunun dalda olduğunu düşündüm.