Elliot Dalga Teorisine dayalı ticaret stratejisi - sayfa 291
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
Ve bu durumda, deneyin koşulları, bu sonuçları stat varlığının teyidi olarak görmemize izin vermiyor. Faydalar.
TAMAM.
"SL<MO" MO nedir?
Ve başka bir soru, en azından kısaca SL nasıl optimize edilir? Harici bir parametre olarak atayın, yani. tüm işlemler için bir SL?
Tek bir düşünce var - deneyin koşullarından değil, bu sonuçlardan hüküm vermek zor.
Yeni sonuçlar daha da az açıklayıcı. İstatistik yok!
21 aylık testten 10'u fazla kaldı.
Sisteminizin yanlış olmadığını iddia etmiyorsunuz. Öyleyse 20'de dur ve ne olduğunu gör. En azından istatistik olacak.
Ve burada yazdıklarımızı bir ticaret danışmanının eleştirisi olarak görmeyin. Ve genel olarak bir eleştiri olarak.
Bu arada, tüm kenelere geçiş, MO'da 38'den 23'e bir düşüşe neden oldu. Bu iyi bir sonuç.
Aynı göstergeleri karşılaştırmak da ilginç olurdu, ancak her iki durumda da durur.
MO - mat. galibiyet beklentisi.
SL'yi optimize etmek çok kolaydır. Harici bir parametre olarak çıktısını alın ve limitler ve bir adım ayarlayarak test cihazında optimize edin. Doğal olarak, EA kodunda, fiyat alış için SL'nin altına düştüğünde ve satış için tersi olduğunda bir anlaşmayı kapatmak için bir koşul eklemeniz gerekir.
Sergey, yazdıklarım eleştiri değil. Önceki yazımı okuyun.
Tek bir düşünce var - deneyin koşullarından değil, bu sonuçlardan hüküm vermek zor.
Yeni sonuçlar daha da az açıklayıcı. İstatistik yok!
21 aylık testten 10'u fazla kaldı.
Yuri, hiç karıştırmadım, kırılmadım ve her şey tamamen normal. :o)))) MathCAD'de 10 ay oturmak yok, çünkü orada bu tür işlemlerin yapılmasına izin vermeyen, başka nedenlerle bir kod var. Model açısından bakıldığında, 10 aylık kuluçka süresi bir hata değildir. Model için “korkunç” bir şey olmadı - fiyat kanalda oturuyordu (kenardan sarkıyordu). Bu arada, bu gibi durumlar nedeniyle yörüngenin kendisini tahmin etmeye başladım.
Sisteminizin yanlış olmadığını iddia etmiyorsunuz. Öyleyse 20'de dur ve ne olduğunu gör. En azından istatistik olacak.
Henüz bariz hatalar bulamamış olmama rağmen rol yapmıyorum - kanalın ömrü boyunca fiyat hesaplanan seviyeyi geçiyor. Ama elbette er ya da geç ortaya çıkacaklar, burada bir yanılsama yok, elbette modelde zayıf noktalar var.
Planımdan sapabilir ve duraklamalar uygulayabilirim. Hala tavsiyenizi bekliyorum, çünkü şimdi MT'ye, hesap makinesindeki bir Neandertal gibi bakıyorum. Matkad'da her şey basittir - formüller oldukları gibidir. :hakkında)
Planımdan sapabilir ve duraklamalar uygulayabilirim. Hala tavsiyenizi bekliyorum, çünkü şimdi MT'ye hesap makinesindeki bir Neandertal gibi bakıyorum. Matkad'da her şey basittir - formüller oldukları gibidir. :hakkında)
hizmetinize sorun.
Ama benim için durum tam tersi. :-))
Ancak şimdi matcad'a değil matlab'a bakıyorum. Ve artık bir Neandertal olarak değil, bir Cro-Magnon olarak.
2 puan daha:
- Prensipte, pozisyon tutma süresi ile kâr miktarı arasında bir korelasyon beklemek normaldir. Kısa zamanda, oradaymış gibi görünüyor (gözle, yanılıyor olabilirim). Ancak daha uzun süre (yine "gözle") durum daha rastgele görünüyor. Ancak tesadüfen, hem küçük artılar hem de küçük eksiler olmalıdır. Ve eksileri yok. "Ayarlama" kodunda şans eseri herhangi bir çıkış var mı?
- Pratik olarak herhangi bir stratejinin "uygulanabilirlik" ve "uygulanamazlık" dönemleri vardır. Dışarıda oturmak bir "uygulanamazlık" dönemini maskelerse, o zaman durakların getirilmesi kayıtlar için bir felaket olabilir. Ve cehalet, gerçek bir hesap için bir felakettir.
Saymalı. İlk sefer değil, ikincisi. Videoda nasıl olduğunu görebilirsiniz - https://www.mql5.com/zh/forum/103424
Yani bu otomatik bir yeniden hesaplama mı? Ancak anladığım kadarıyla, tekliflerin komisyoncu zamanı ile senkronizasyonu sağlanmıyor. Şey, eğer iki uzun parçayı dikmekten bahsediyorsak, o zaman kavşaktaki zaman atlaması, diyelim ki bir saat, temel bir öneme sahip olmayacaktır. Ya orijinal hikaye parçalardan oluşuyorsa ve alıntıları indirmek boşlukları dolduracaksa? Güzel bir karışım yapacaktır.
Ben kendim, hikayeyi indirdikten sonra hemen çevrimdışı bir terminale aktardım ve hiçbir şeyle karıştırmadım.
Hala belirsiz. 14. işlem 20 dakika, 15. işlem 10 ay yaşadı. Kanal neden 15. işlemde AL değil de SAT gösteriyor?
Cevabı biraz genişletmeye karar verdim. Aşağıdaki resimde, kanalların ömrü (eurusd, saat) ile ilgili istatistiklerin toplanması, aşağıdaki şekilde gerçekleştirilir: kanalın uzunluğu sabittir, zamanla birlikte hareket ederiz, her “mevcut” çubuk için sabit uzunlukta bir kanaldır. inşa edilmiş ve kullanım ömrü tahmin edilmiştir (elbette geleceğe göz atarak). Yol boyunca, her türlü ek kanal parametresini topladım. Bu özel durumda, kanalın uzunluğu 300 örnektir.
Güzellikte, elbette, dalgacık dönüşümü resimlerden daha düşüktür, ancak eğrinin şekline dikkat edin (diğer dönemler ve alıntılar için korunur), kanal neredeyse anında sabit bir pozisyon alır, yani. önce zirve gelir ve sonra süre azalır ve bunun tersi olmaz, ancak böyle bir resim beklemek daha mantıklıdır. Bazı kanalların oldukça uzun bir süre, uzunluklarının yaklaşık 3,5'i kadar yaşadığı görülebilir (hatırlatmama izin verin, geleceğe göz atarken kanal parametrelerinin değişmediğini). Dolayısıyla, bu süre zarfında fiyat yörüngesinin nasıl gelişeceğini bilmiyorum, ancak neredeyse kesin olarak, kanalın varlığı sırasında, Hurst üssü dahil olmak üzere ek kriterler çalışmadığı sürece, fiyat hesaplanan seviyeyi geçecektir. 20 dakikada olabilir, birkaç günde olabilir, birkaç ayda olabilir. Tabii ki, bu hoş olmayan özelliklerden biridir - ya bir işleme inanır ya da reddeder ya da bir kayba izin verir. "Sorun" derecesi açısından benzer özellikler, diğer strateji ve modellerde yeterli sayıda bulunabilir.
Bu modelde geri dönüş alanı aramıyorum (diğer modeller bunun için tasarlanmıştır). MathCAD'deki modelin çekirdek kodu birkaç satır alır ve 10 aylık işlemi engelleyen kod birkaç yüz satır alır. Bu nedenle, bu modelin ilk testleri, kayıpların %20'sini verdi (engellemeden sonra), şimdi MathCAD'de zaten %2, MT'de ne olacağı görülmeye devam ediyor.
Bu arada, eğri şeklinin kendisi yararlıdır. İstatistik toplarsanız (belki de zaten toplamışsınızdır), aşırı uçları (ya sağduyu temelinde veya profesyonel sistemlere başvurarak) ve mevcut sayıya yakın şekline bakarak (bir adım geriye giderek) sınıflandırabileceksiniz. kanal), yüksek derecede güvenilirlik kanalı varlığı ile zamanı tahmin edebilirsiniz.
Genel olarak, kanallarda çok büyük bir anlam var ... ama bu zaten bir felsefe.
Candida'ya
2 puan daha:
- Prensip olarak, bir pozisyonda kalma süresi ile kâr miktarı arasında bir korelasyon beklemek normaldir. Kısa zamanlarda, orada gibi görünüyor (gözle, yanılıyor olabilirim). Ancak daha uzun süre (yine "gözle") durum daha rastgele görünüyor. Ancak tesadüfen, hem küçük artılar hem de küçük eksiler olmalıdır. Ve eksileri yok. "Ayarlama" kodunda şans eseri herhangi bir çıkış var mı?
- Pratik olarak herhangi bir stratejinin "uygulanabilirlik" ve "uygulanamazlık" dönemleri vardır. Dışarıda oturmak bir "uygulanamazlık" dönemini maskelerse, o zaman durakların getirilmesi kayıtlar için bir felaket olabilir. Ve cehalet, gerçek bir hesap için bir felakettir.
Tam da daha erken olduğu için (felsefi test) Yuriy beni duvara bir SL ile çivilediğinde Markian teknesi gibi sallandım. Yine de kibar bir söz ve silahla SL'yi tanıtmaya ikna etti. :hakkında)
Bu arada, daha önce stopları doğrudan bir emir parametresi olarak kullanmadım, ancak onu açık bir pozisyonun kontrolü ile uyguladım, çünkü koşullar her zaman değişir ve gelecekte buna bağlı kalmayı planlıyorum.
Yurixx'e
Yuri, SL konusunda yardımını istiyorum. :hakkında)
Daha önce yazdığım gibi, hiç SL kullanmadım ama dinamik sipariş kontrolü kullandım. Belki de bu pek uygun değil çünkü sistem her zaman sunucuya bağlı olmalı ama bence bu daha mantıklı.
SL ile bazı sorunlarım olduğunu (ve yaklaşık bir yıl önceydi) ya da DC'nin çok uzağa yerleştirilmesine ya da başka bir şeye izin vermediğini belli belirsiz hatırlıyorum. Kısacası, belgelere baktım ve bunun emrin kapatıldığı fiyat seviyesi olduğunu “hatırladım”. Tamam dedim kendi kendime ve sipariş tipine göre SL için şu parametreleri girdim:
Teklif-20*Puan
Sor+20*Puan
Tek bir işlem değil, şimdi nedenini anlamaya çalışıyorum, daha doğrusu bir hata kodu talep ediyorum. Birkaç seçenek daha eklendi - yine anlaşma yok. Sonuç olarak, bundan bıktım ve 20.0 alnında SL fiyat seviyesini belirttim, işe yaradı:
"Hiçbir şey anlamıyorum" karikatüründe olduğu gibi. Yuri, dinozora onları nasıl doğru ayarlayacağını açıkla ve neden 1,2 diyelim ki değer 20.0'dan daha kötü
1. SL koyamazsınız, ancak fiyat seviyesini bağımsız olarak dinamik olarak kontrol edebilir ve gerekirse anlaşmayı "kapatabilirsiniz". Bunların hepsi sembolizm, ticaret değil. Sadece istatistik topluyorum. Ancak bu durumda, her şey kendi ellerinizle yapılmalı ve bir test cihazı kullanılmamalıdır. Diğer bir deyişle, geçmiş boyunca çalışan, stratejiyi uygulayan ve sonuçları bir dosyada toplayan bir komut dosyası yazmanız yeterlidir. Bu komut dosyasının %95'i danışmanınızın metni olduğu için bu konuda karmaşık bir şey yoktur.
2. Test cihazı kullanıyorsanız, gerçek hayatta olduğu gibi verilen siparişlerde SL yerleştirilmelidir. Yazdıklarınızdan asıl sorunun ne olduğunu anlamadım. En kolay yol, SL'yi bildirdiğiniz, tanımladığınız ve kullandığınız kod parçalarını kesip buraya getirmektir. Belki de sorun normalizasyondadır (siparişlerdeki tüm fiyatlar normalleştirilmeli, yani Nokta hassasiyetine yuvarlanmalıdır). Bu arada, 20.0'ı açıkça belirttiyseniz, bu tam olarak normalleştirilmiş değerdir. Ama 20*Puan öyle değil. Açıkça 1.2 ayarladıysanız, bu da işe yarar (satın almak için). Şu şekilde deneyin:
Teklif-20.0*Puan
Sor+20.0*Puan
Ancak tekrar ediyorum: Teklif Et, Sor, çıkıyor, denormalize edilebilir.
1. SL koyamazsınız, ancak fiyat seviyesini bağımsız olarak dinamik olarak kontrol edebilir ve gerekirse anlaşmayı "kapatabilirsiniz". Bunların hepsi sembolizm, ticaret değil. Sadece istatistik topluyorum. Ancak bu durumda, her şey kendi ellerinizle yapılmalı ve bir test cihazı kullanılmamalıdır. Diğer bir deyişle, geçmiş boyunca çalışan, stratejiyi uygulayan ve sonuçları bir dosyada toplayan bir komut dosyası yazmanız yeterlidir. Bu komut dosyasının %95'i danışmanınızın metni olduğu için bu konuda karmaşık bir şey yoktur.
Bunu her zamanki gibi dedikleri gibi yapacağım.
2. Test cihazı kullanıyorsanız, gerçek hayatta olduğu gibi verilen siparişlerde SL yerleştirilmelidir. Yazdıklarınızdan asıl sorunun ne olduğunu anlamadım. En kolay yol, SL'yi bildirdiğiniz, tanımladığınız ve kullandığınız kod parçalarını kesip buraya getirmektir. Belki de sorun normalizasyondadır (siparişlerdeki tüm fiyatlar normalleştirilmeli, yani Nokta hassasiyetine yuvarlanmalıdır). Bu arada, 20.0'ı açıkça belirttiyseniz, bu tam olarak normalleştirilmiş değerdir. Ama 20*Puan öyle değil. 1.2'yi açıkça ayarlarsanız, bu da işe yarar (satın almak için)
Sorun şu ki 130 hata kodu veriyor - yanlış duraklar. :hakkında)
Her şey ne kadar zekice. Bir sayıyı 4 ondalık basamağa yuvarlayan herhangi bir işlev var mı?
Dolayısıyla, bu süre zarfında fiyat yörüngesinin nasıl gelişeceğini bilmiyorum, ancak neredeyse kesin olarak, kanalın varlığı sırasında, Hurst üssü dahil olmak üzere ek kriterler çalışmadığı sürece, fiyat hesaplanan seviyeyi geçecektir. 20 dakikada olabilir, birkaç günde olabilir, birkaç ayda olabilir.
Yani, 10 aylık anlaşmanın ortaya çıkması sırasında (böyle bir düşüşle), kanal çökmedi mi? Ancak güçlü bir kanal vardı :)
Tamam dedim kendi kendime ve sipariş tipine göre SL için şu parametreleri girdim:
Teklif-20*Puan
Sor+20*Puan
Tek bir işlem değil, şimdi nedenini anlamaya çalışıyorum, daha doğrusu bir hata kodu talep ediyorum.
Günlüğe bakın, OrderSend ateşlenmezse, nedeni ile ilgili orada bir not yapılır.