Dijital Filtrelere Dayalı Ticaret Stratejileri - sayfa 33

 
SIMBA:
Sonuçlarınızı paylaşmak ister misiniz?..Ve veri, virgül, vb. konularını doğru şekilde ayarlamanın yolu... Bunu yapabilmek ve paylaşmak bizim için de heyecan verici olacak.

Tabi ki...

Tarih virgül ayarlarımı aynen ND'nin yaptığı gibi kopyaladım....

Daha sonra robertinno'nun verilerini yükledim... ve aldığım şey bu (eke bakın)...

Farklı veriler kullandığını tahmin ediyorum... ve excel'de roc'un "nasıl yapılacağına" dair bir örnek yayınladı.... ...

cl

Dosyalar:
 

ND,

İŞE YARADI!!!! Sağ ol, kanka!!!

Newdigital'in söylediklerini yapın ve tekrar deneyin. Resminize bakarak içe aktardığınız verilerle ilgili büyük bir sorununuz var.

Kendiniz görün, mumlarınızda tamamen bir tutarsızlık var.

Yo Linuxser,

Tavsiyen için teşekkürler. Mumların bu şekilde görünmesinin nedeni, içe aktarılan verilerde bir şeylerin yanlış olması değil, aslında OHLC mumları olmamasıdır. ROC verileridir (yanılmıyorsam). Robertinno tarafından bize getirilen farklı bir SA yöntemi, sözde daha doğru bir çıktı veriyor çünkü finansal piyasalar olan durağan olmayan zaman serilerine karşı olağan gerçekçi olmayan durağan analize dayanıyor (yanılıyorsam biri beni düzeltin). İŞTE sorun buradan çıktı. Farklı türde bir veriydi ve farklı tarih biçimine sahip bir bilgisayardan (robertinno'nun) geliyordu, bu nedenle farklı varsayılan tarih biçimine sahip olmayanlar yükleme sorunlarıyla karşılaşıyordu ve bunun farklı bir veri türü olduğunu düşünüyorduk. Vay!

bayılırım........

Herkesin beyin fırtınası ve ekip çalışması sayesinde bunu aştık.

iyi koy... :-)

 
newdigital:
Ben sadece deneyimimi anlattım.

Verileri Metatrader olmayan bir yazılıma aktarmak için bir araç kullandığımızda (esignal kullanmak yerine ForexClub aracıyla ücretsiz olarak asctrend yazılımına vb.) bu nedenle şu sorunu yaşayabiliriz: Windows tarih ve sayıların ayarları. Ve bu yazılımın nerede oluşturulduğuna ve sahip olduğunuz Windows'a bağlıdır.

Örneğin, Windows'um Rusça. Bu, bu Windows'ta (ve Rusça'da) 1.000'in bir olduğu anlamına gelir. Ve 1.000, eğer İngilizce Windows kullanıyorsanız, bindir. Ve bölücüler ile aynı durumlar. Avrupa ve Asya için de durum farklıdır.

Bu nedenle, bazı ücretsiz araçlar kullanarak (birçok ücretsiz araç vardır) bir yazılımdan diğerine forex verilerini dönüştürüyorsanız, bu araç çoğu zaman Windows ayarlarınıza göre yapacaktır.

Sadece Denetim Masası, Diller ve Standartlar'a gidin ve formatı değiştirin, anlayacaksınız.

En önemli şey ayırıcıdır: virgül veya noktalı virgül olabilir.

Örneğin:

1.9864 , 25.01.2006 (virgül varsa)

veya

1.9864 ; 25.01.2006 (noktalı virgül ise).

Veriler içe aktarıldığında, Windows'unuz bazı veriler arasındaki ayırıcı olarak virgülü anlayabilir ve bir hata alabilirsiniz.

Bu nedenle, Windows ayarlarınızda kontrol edin ve gerekirse değiştirin (ancak zaten doğru şekilde ayarlandığından amerikan Windows ile ilgili değildir). Ama bu DFG'nin yaratıcısının Rus olduğunu bildiğim için, olabilir, noktalı virgül yerine virgül programladı ve bu nedenle herhangi bir hatam yok (hata almadım ve Windows ayarlarındaki ayırıcım varsayılan olarak virgüldür).

ND,

İŞE YARADI!!!! Sağ ol, kanka!!!

Linux sunucusu:
Newdigital'in söylediklerini yapın ve tekrar deneyin. Resminize bakarak içe aktardığınız verilerle ilgili büyük bir sorununuz var.

Kendiniz görün, mumlarınızda tamamen bir tutarsızlık var.

Ey Linuxçu,

Tavsiyen için teşekkürler. Mumların bu şekilde görünmesinin nedeni, içe aktarılan verilerde bir şeylerin yanlış olması değil, aslında OHLC mumları olmamasıdır. ROC verileridir (yanılmıyorsam). Robertinno tarafından bize getirilen farklı bir SA yöntemi, sözde daha doğru bir çıktı veriyor çünkü finansal piyasalar olan durağan olmayan zaman serilerine karşı olağan gerçekçi olmayan durağan analize dayanıyor (yanılıyorsam biri beni düzeltin). İŞTE sorun buradan çıktı. Farklı türde bir veriydi ve farklı tarih biçimine sahip bir bilgisayardan (robertinno'nun) geliyordu, bu nedenle farklı varsayılan tarih biçimine sahip olmayanlar yükleme sorunlarıyla karşılaşıyordu ve bunun farklı bir veri türü olduğunu düşünüyorduk. Vay!

bayılırım........

Herkesin beyin fırtınası ve ekip çalışması sayesinde bunu aştık.

 

Eğri uydurma mı Yeniden Ayarlama mı?

Herkese selam,

Büyüleyici iplik. Harekete geçiren herkese teşekkürler. Sakıncası yoksa gurulara bir sorum var.

Soru: Peki ya eğri uydurma ve yeniden ayarlama ihtiyacı? Bana açık görünüyor ki, bu tür bir analiz, yöntemin bir parçası olarak kasıtlı olarak, son derece eğri uyumudur. Bana yapay zeka teknikleri hakkında okuduklarımdan bazılarını hatırlatıyor - sinir ağları, vb. Ayrıca sinirsel teknikleri başarılı bir şekilde kullanan günlük tüccarların, göstergelerin hassas olmaya devam etmesi için göstergelerini düzenli olarak yeniden optimize etmeleri veya yeniden ayarlamaları gerektiğini okudum. ve mevcut pazarla alaka düzeyi - bazıları her gün olduğu kadar sık.

Peki ya bu DF yöntemleri? Yeniden ayarlama (veya yeniden optimizasyon) gerekli mi? Ne sıklıkla? Ayrıca, 200-300 bar gibi daha kısa "öğrenme periyodu"nu kullanmak ile mevcut tüm barlar arasındaki farka ne dersiniz? FATL, SATL, vb. 200-300 çubuk kullanılarak oluşturulursa, gerçekten açıklayıcı olan ve dağılmaya başlamayan eğriler oluşturmaya devam etmek için filtrelerin ne sıklıkla yeniden ayarlanmasını önerirsiniz?

Kavramlar üzerinde hız kazandıktan sonra, yakında bu yöntemlerden bazılarını denemeye başlayacağım. Bazı temel fikirlerin manuel olarak geriye dönük testini yapmayı hayal ediyorum. Ancak, (bilinen) geçmiş verilere göre yüksek düzeyde optimize edilmiş göstergelere karşı geriye dönük test yapmanın ve ardından (bilinmeyen) geleceğin bu optimize sonucu tutmasını beklemenin gerçek olacağını düşünmüyorum. Filtreleri 200-300 barlık bir pencereye ayarlamanın, ardından bir sonraki, örneğin 100 bar'a karşı test etmenin, ardından 200-300 bar ayar penceresini 100 bar ileri adımlamanın, ardından sonraki 100 bara karşı test etmenin en iyisi olabileceğini düşünüyorum. , vb., oldukça gerçekçi koşullara karşı tam bir geriye dönük test oluşturmak için.

Herhangi bir tavsiye veya yorum?

En iyi,

Scott

 
turboscottomatic:
Herkese selam,

Büyüleyici iplik. Harekete geçiren herkese teşekkürler. Sakıncası yoksa gurulara bir sorum var.

Soru: Peki ya eğri uydurma ve yeniden ayarlama ihtiyacı? Bana açık görünüyor ki, bu tür bir analiz, yöntemin bir parçası olarak kasıtlı olarak, son derece eğri uyumudur. Bana yapay zeka teknikleri hakkında okuduklarımdan bazılarını hatırlatıyor - sinir ağları, vb. Ayrıca sinirsel teknikleri başarılı bir şekilde kullanan günlük tüccarların, göstergelerin hassas olmaya devam etmesi için göstergelerini düzenli olarak yeniden optimize etmeleri veya yeniden ayarlamaları gerektiğini okudum. ve mevcut pazarla alaka düzeyi - bazıları her gün olduğu kadar sık.

Peki ya bu DF yöntemleri? Yeniden ayarlama (veya yeniden optimizasyon) gerekli mi? Ne sıklıkla? Ayrıca, 200-300 bar gibi daha kısa "öğrenme periyodu"nu kullanmak ile mevcut tüm barlar arasındaki farka ne dersiniz? FATL, SATL, vb. 200-300 çubuk kullanılarak oluşturulursa, gerçekten açıklayıcı olan ve dağılmaya başlamayan eğriler oluşturmaya devam etmek için filtrelerin ne sıklıkla yeniden ayarlanmasını önerirsiniz?

Kavramlar üzerinde hız kazandıktan sonra, yakında bu yöntemlerden bazılarını denemeye başlayacağım. Bazı temel fikirlerin manuel olarak geriye dönük testini yapmayı hayal ediyorum. Ancak, (bilinen) geçmiş verilere göre yüksek düzeyde optimize edilmiş göstergelere karşı geriye dönük test yapmanın ve ardından (bilinmeyen) geleceğin bu optimize sonucu tutmasını beklemenin gerçek olacağını düşünmüyorum. Filtreleri 200-300 barlık bir pencereye ayarlamanın, ardından bir sonraki, örneğin 100 bar'a karşı test etmenin, ardından 200-300 bar ayar penceresini 100 bar ileri adımlamanın, ardından sonraki 100 bara karşı test etmenin en iyisi olabileceğini düşünüyorum. , vb., oldukça gerçekçi koşullara karşı tam bir geriye dönük test oluşturmak için.

Herhangi bir tavsiye veya yorum?

En iyi,

Scott

Scott,

Sadece kısa bir dakikam var, ama size yorumumu vermek istedim. "Yeniden ayarlama" açısından, aslında o kadar içine girmedik ama bu ortaya çıkmadığı anlamına gelmiyor. Benim .02'm (ve bu geçmişte SIMBA'nın tavsiyesiydi) SATL, FATL ( bu da STLM ve FTLM'ye yol açar) kullanırken mümkün olan en az miktarda çubuk kullanmaya çalışıyoruz. O zaman, belki her hafta, son 200 çubukla yeniden optimize edebileceğinizi düşünürdüm. Örneğin Cumartesi günü yeniden optimize edin ve gelecek hafta için katsayıları kullanın. Yarattığımız "döngüler" buna gerçekten dokunmadık. Tam geçmişi kullandığımızdan, sık sık yeniden optimize etmek zorunda kalmayacağınızı varsayıyorum. Yine de bu, asla zorunda kalmayacağınız anlamına gelmez.

Üzgünüm ama kaçmak zorundayım. Eminim başka biri bu konuda daha fazla yorum yapacaktır.

Teşekkürler,

cl

 

Teşekkürler

Teşekkürler cl - Giriş için teşekkür ederim. Burada tahtada okuduklarımdan ve orijinal makalelerden (Robert'ın sitesinde) öyle görünüyor ki bu teknikleri kullanan herkes sınırda çalışıyor ve deneme yanılma yoluyla çok fazla deney ve keşif yapması gerekecek. Klasik TA göstergelerinin çoğu gibi iyi bilinen (ve çok eskimiş) geçmişlere sahip yöntemlerle çalışmaktan ÇOK daha ilginç. Bu işe biraz kendim girmek için sabırsızlanıyorum. Ne yazık ki, önümüzdeki 3 hafta boyunca taşınıyorum ve bu öncelikli olacak, ancak bu benim için haç.....

en iyi,

Scott

 

sen barnix,

Bu biraz derin şeyler. Paten kaymaya gitmeden önce başımı ağrıtmaya çalışıyor olmalısın. çok komik! Paylaşım için teşekkürler kardeşim. Bir kaç soru sorabileceğim için yabancı olma

Şimdiye kadar anladığım kadarıyla, bu yöntem durağan olmayan verilerle çok iyi çalışıyor.

FEI (Herkesin Bilgisine)

SSA dosyasını içerme ve/veya kitaplık klasörüne ve #_FullSSA_normalize dosyasını gösterge klasörüne yerleştirmelisiniz.

 

Bu gece bu göstergeyle uğraşıyorum, VHands aracılığıyla çalıştırıyorum. Bu kesinlikle hafızada bir domuz. Sorum hesaplamadan kaynaklanıyor. Çizgi sürekli olarak kendini yeniden boyar ve yeniden hesaplar, bu nedenle geçmişte harika görünür. "Gecikme" harici bunu kontrol eder. "10", son 10 çubuğu yeniden hesaplıyor gibi görünüyor. "3" sayısı çok daha pürüzlüdür ve geçmişi 10'un yaptığı kadar yeniden boyamaz. Bu göstergenin hangi "gerçek zamanlı" uygulamalara sahip olacağından emin değilim. Bana birçok balıkçı göstergesini hatırlatıyor. Belki de yeniden boyamasını sağlayan bir kodlama hatası vardır? Sanmıyorum ama fark ettiğimi yazayım dedim...

En iyi,

cl

 

SSA'da:

Ben ve diğer birkaç üye, bu göstergenin "yeniden hesaplanmasını" deneyimledim. Birkaç kapalı çubuktan sonra değişebilir. Bunun bir hata olup olmadığından veya bu göstergenin Zigzag yani dinamik olması gerektiğinden emin değil. Durum ne olursa olsun, kullanan herkes, bunu yaparken dikkatli olmanızı tavsiye ederim.

Belki Barnix bu konuya biraz ışık tutacak kadar nazik olurdu. Amaçlanan şekilde kullanmıyor olabilirim. Eğer öyleyse, hemen sonuca vardığım için özür dilerim. Barnix, işine aşina olduğum birkaç yüksek vasıflı üyeden biri, bu yüzden bize kasıtlı olarak hatalı bir ürün vereceğinden ciddi olarak şüpheliyim. Umarım hala oradadır ve bu mesajı görür. Konuyla ilgili daha fazla tartışmayı sabırsızlıkla bekliyorum.

DF'lerde:

İlgilenenler için DFG yazılımının yaratıcısı Sergey Iljukhin tarafından kodlanmış bir gösterge var. DFG yazılımından fonksiyonları çağıran .DLL'leri içerir ve doğrudan MT4'te Low-Pass filtrelerin oluşturulmasına izin verir. DFG kullanmanın amacı daha sonra yalnızca spektral analiz için olur. Tüm süreç için DFG kullanmanın geleneksel yöntemine kıyasla canlı verilere karşı ince ayar yapmak ve test etmek çok daha kolay. Göstergeyi ve .DLL dosyalarını indirmek için bu bağlantıyı ziyaret edin.

Çok iyi bir gösterge IMHO. Programcılardan herhangi birinin optimize edilmiş FTLM ve STLM filtrelerinin oluşturulmasına izin veren benzer bir gösterge oluşturmak için bir proje üstlenmekle ilgilenip ilgilenmeyeceğini merak ediyorum. Bu, farklılığa uygun dijital filtreleri optimize etmek ve oluşturmak için daha kullanıcı dostu yöntemlerin ilerlemesini daha da ilerletecektir. Zaman serisi.

Ayrıca, bazı olası modlar, mevcut DigitalFilter.mq4 göstergesini, Fiyat Gümrükleri ve oluşturulabilecek filtre türlerinin tanımı ve parametrelerde karşılık gelen sayısal değere karşı indy'yi açma zorunluluğu gibi birkaç ekstra şey içerecek şekilde değiştirir. MetaEditor'da (Simba, CLahn ve kendim arasındaki araştırmalara dayanarak) inandığım diğer değişiklikler arasında onu bulmak veya ezberlemeye çalışmak, sağlam bir göstergeler seti üretecektir.

Bunlarla birlikte, doğrudan MT4'te otomatik olarak optimize edilmiş DF'lere bir adım daha yakınız. Jojo kısa süre önce Goertzel algoritmasını kullanarak MT4 için bir spektral analiz göstergesi oluşturdu. Ne yazık ki, Jojo o zamandan beri başlığa gönderilmedi, bu yüzden onu amacımıza nasıl doğru bir şekilde uygulayacağımızı bilmiyoruz. Şu anki haliyle, @ bir durgunluk noktasıyız. MT4 DF göstergeleri ile Goertzel SA göstergesi ile nasıl evleneceğimizi biliyorsak ve ne zaman... .

Her türlü geri bildirimi bekliyorum.