Elliot Dalga Teorisine dayalı ticaret stratejisi - sayfa 153
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
Örneğin buradan başlayın http://forex.kbpauk.ru/showflat.php/Cat/0/Number/16113/an/0/page/2#Post16113
Vladislav , bu bağlantı forumda kayıt gerektirir. Ama bu foruma zaten 3 kez kaydolmaya çalıştım. 2 kez altı ay önce ve şimdi denedim. Ancak sabuna kaydolmak için yapılan tüm girişimler için aşağıdaki içeriğin bir mektubu alınır:
**************
Kaydınızın ilk kez yapabilmeniz için önce bir yönetici tarafından onaylanması gerekir.
giriş yapacak. Kaydınızı onaylamak için size bir e-posta gönderilecektir. Kayıt şurada onaylandı:
günde ortalama bir kez.
**************
Ve hepsi bu! Kayıt onayı yok ve buna bağlı olarak siteye girememe
***********
Giriş/şifre bulunamadı.
Devam edemiyor (kimse nedenini bilmiyor, sorma bile).
***********
Tabii ki, son cümle özellikle dokunaklı - "(kimse nedenini bilmiyor, sorma bile)". Muhtemelen yöneticinin gözünde harika görünüyor?!
Muhtemelen forum yöneticisi, bir kişinin kendi forumunun bilgilerine onuncu kez erişmeye çalıştığı anda bu ifadenin, ancak bilgi okumak yerine böyle bir yazının admin olarak yetkisini artıracağını düşünüyor mu? Aynı zamanda, sorulması gereken en ilginç şey, gerçekten kimsenin olmamasıdır - forumda yönetici ile iletişim için e-posta yoktur.
Muhtemelen yeni üyeler artık bu foruma kayıtlı değil mi? Mesela, geçen yıllarda kimler kayıt olmayı başardı - kapalı bölümleri okudu ve kimin zamanı yoktu, o zaman buna göre geç mi kaldı? Ne olmuş?
Belki yukarıda önerilen bağlantıyı kullanarak bu konudaki bir zip dosyasına ilginç tartışma sayfaları koyabilirsiniz?
Şimdiden teşekkür ederim!
İşte sayfanın kendisi http://fxfilecheng.narod.ru/page.rar
Ve işte ekli dosya http://fxfilecheng.narod.ru/Pesavento_Fibonacci_Ratios.rar
Bu bağlantı, ZigZag'daki hatanın bir analizini içerir.
Yapılan sonuçların doğruluğunu kontrol etmek için, bulunan değerlerin arabelleğe yazıldığı satırlardan sonra zikzak koduna yerleştiririz:
ExtMapBuffer[shift]=val; - tampon için dize
if (shift<13 && val>0) Print ("shift="+shift+" low val="+val+" Low[shift]="+Low[shift]); - orada gerçekte ne yazıldığını ve en önemlisi nerede yazıldığını kontrol etmek
ExtMapBuffer2[shift]=val;
if (shift<13 && val>0) Print ("shift="+shift+" yüksek val="+val+" Yüksek[shift]="+Yüksek[shift]);
Kontrol dakikalar içinde gerçekleştirilir.Kontrol edilen çubuk sayısı 13'ten farklı olacak şekilde ayarlanabilir.
Ve hemen zikzak arabelleklerine çöp yazıldığı anlaşılır. Ve herkes bu çöple çalışıyor.
Herkes zikzak yapmanın doğru bir şey verdiğini düşünüyor. Ve aslında? Birçok zikzak sisteminin temel prensibi. Ve temel çürük.
Genel olarak, bir programlama problemi olarak ilginçtir - bakmanız gerekecek. Bu arada, bu hücrelerde tam olarak ne yazdığını kontrol etmediniz - akşama kadar daha fazla boş zaman olacak, kendim bir göz atacağım. Gerçek şu ki, çizerken, varsayılan olarak göstergenin çizilmeyen değeri sıfırdan farklıdır (yanılmıyorsam maksimum uzun) - buna da birkaç kez rastladım. Ve bir şey daha: dizilerin yanlış adreslenmesiyle ilgili göstergelerde (bunu nasıl yapacağımı bilmiyorum) yeterli sayıda hata var. Basitçe söylemek gerekirse: dizinler yanlış sayılır veya kaydırılır: C'de diziler sıfırdan dahil edilmeyen son öğeye kadar adreslenir. En yaygın hata, sınır dışı dizilerdir. Statik yerleştirme ile, program veri alanı dışındaki belleği değiştirmeye çalışana kadar bu, kompleksin performansını etkilemeyecektir. Ancak bazen ortaya çıkan (ne zaman olduğu kesinlikle tahmin edilemez) algoritmanın kendisi kullanılamaz. CPP'de ihtiyacım olan algoritmaları yeniden yazarken, yanlış adresleme ile birçok hatayı düzelttim (statikte bir sınırla karşılaştığımda ve dll'lerden veri dizilerinin dinamik yerleşimini yapmak zorunda kaldım - hatalar burada başladı - VCPP'de programları hata ayıklama bilgileriyle derleyebilir ve sorunları en azından kısmen yerelleştirebilirsiniz).
Yerleşik zikzak algoritması ile ilgili olarak - kalıp aramak amacıyla, IMHO uygun değildir (en azından düzeltilmiş, en azından yerel). Mevcut durum açısından önemli olan dalgalanmaları filtreleyecek bir algoritmaya ihtiyacımız var. Örneğin, sapma değeri mevcut "gürültü" den küçükse, salınım hemen yok sayılır, daha büyükse hemen dikkate alınır ve ardından kaldırılmaz. IMHO - her şeyi olduğu gibi görmek daha iyidir. Bu, EBA'nın amaçları doğrultusunda, piyasadaki hareketi tek kalıp 3-5 ile tarif etmeye çalıştıklarında her şeyin bu kalıba ayarlanması gerekiyor. Daha geniş bir küme kullanırsanız (tüm Pesavento-Gartley kalıpları), o zaman aslında, hangi kalıbın tanımlandığı çok önemli değildir ve genellikle önemli geri dönüşlerden önce olur. AB=CD desenindeki resimden kurtulduğum başlıktaki yukarıdaki mesajıma bakın, hala bir Gartley kelebeği vardı (daha önce tanımlanmıştı) ve seviyelerin nasıl çalıştığı açıktı. Ve dürüst olmak gerekirse, Elliot dalgasının ne olduğu benim için önemli değildi. Ve beni endişelendiren, yerleşim bölgelerinin çözülme olasılığıydı. Ve regresyon kanalları buna karar vermeye yardımcı olur, ancak bu neredeyse tüm dalın tekrarıdır.
Saygılarımla, Vladislav.
İyi şanslar ve geçen trendler.
Genel olarak, bir programlama problemi olarak ilginçtir - bakmanız gerekecek. Bu arada, bu hücrelerde tam olarak ne yazdığını kontrol etmediniz - akşama kadar daha fazla boş zaman olacak, kendim bakacağım. Gerçek şu ki, çizerken, varsayılan olarak göstergenin çizilmeyen değeri sıfırdan farklıdır (yanılmıyorsam maksimum uzun) - buna da birkaç kez rastladım.
Aslında bir sayıdır (2147483647 veya 2 üzeri 31 eksi 1 [2^31-1])
ve sıfır var. MQL-IV'te boş önemsiz değerlerin gösterilmemesi için SetIndexEmptyValue() kullanılır.
Вобщем как задачка по программированию интересно - нужно будет посмотреть. Кстати, Вы не проверяли что именно пишется в эти ячейки - к вечеру будет больше свободного времени сам гляну. Дело в том, что при прорисовке нерисуемое значение индикатора по умолчанию отлично от нуля (максимальный лонг, если не ошибаюсь)- я на этом тоже пару раз попадался.
Aslında bir sayıdır (2147483647 veya 2 üzeri 31 eksi 1 [2^31-1])
ve sıfır var. MQL-IV'te boş önemsiz değerlerin gösterilmemesi için SetIndexEmptyValue() kullanılır.
eklemeye karar verdi. Bu numara (2147483647) genellikle aşağıdaki durumda ortaya çıkar:
1) En az bir gösterge arabelleğine sahip bir gösterge yazılır
2) Önemsiz değerler SetIndexEmptyValue() işlevi tarafından bastırılır, ancak aynı zamanda
3) Boş değerler zorunlu boş değerle doldurulmaz
Sonuç: grafiğe baktığınızda, gösterge doğru çalışıyor, ancak başka bir gösterge veya danışmandan aşınmış bir endekse böyle bir göstergeye erişmeye başladığınızda, mucizeler olmaya başlıyor - bu 2147483647 numarası görüntüleniyor.Tecrübeniz varsa, hemen gösterge kodunda bu algoritmik hatayı düzeltmeye başlayın, değilse, kara kedi arayışı karanlık bir odada başlar, kedinin kendisi olduğu gibi yoktur. Ama yine de onu aramakta fayda var - buna deneyim denir ve derinlere gömülür .... hafıza :)
Вобщем как задачка по программированию интересно - нужно будет посмотреть. Кстати, Вы не проверяли что именно пишется в эти ячейки - к вечеру будет больше свободного времени сам гляну. Дело в том, что при прорисовке нерисуемое значение индикатора по умолчанию отлично от нуля (максимальный лонг, если не ошибаюсь)- я на этом тоже пару раз попадался.
Aslında bir sayıdır (2147483647 veya 2 üzeri 31 eksi 1 [2^31-1])
ve sıfır var. MQL-IV'te boş önemsiz değerlerin gösterilmemesi için SetIndexEmptyValue() kullanılır.
Kusura bakmayın ama aslında 2 üzeri +31'in kuvveti genel durumda, bir birim olamaz. Bu eşitlik ancak verinin bit derinliğini sınırlayarak sağlanabilir. Bit derinliğini değiştirirken ne yapacaksınız? Dizi sıfır olarak başlatılırsa, sıfır olmalıdır, değilse, sonucun tanımsız olduğunu göstermelidir. Sonuçta, geliştiricilerin kendileri CPP standardına atıfta bulundu. Her şeyi daha kolay yapmama rağmen: Bir sıfıra ihtiyacım var - onu sıfıra zorluyorum.
Saygılarımla, Vladislav.
İyi şanslar ve geçen trendler.
Tehdit 2 Rosh - eki okuyun. Hatırladığım kadarıyla, SetIndexEmptyValue() işlevi tarafından varsayılan değeri bastırmadan da böyle bir etki (sıfır yerine 2147483647) meydana geldi, yanılıyor olabilirim - çok uzun zaman önceydi. Evet ve uzun zaman önce, C'de programlama döneminde geliştirilen alışkanlığa geri döndüm - her şeyi (en azından sıfırla, en azından başka bir gerekli değerle) zorla başlatmak için - genellikle çok zaman kazandırır ve onsuz sadece bir felaket :). O zamandan beri bu sorun beni rahatsız etmedi - sadece kendim nasıl tökezlediğimi hatırladım.
Kusura bakmayın ama aslında 2 üzeri +31'in kuvveti genel durumda, bir birim olamaz. Bu eşitlik ancak verinin bit derinliğini sınırlayarak sağlanabilir. Bit derinliğini değiştirirken ne yapacaksınız? Dizi sıfır olarak başlatılırsa, sıfır olmalıdır, değilse, sonucun tanımsız olduğunu göstermelidir. Sonuçta, geliştiricilerin kendileri CPP standardına atıfta bulundu. Her şeyi daha kolay yapmama rağmen: Bir sıfıra ihtiyacım var - onu sıfıra zorluyorum.
İlk değerle başlatmadan ( ArrayInitialize() function ) değil, sıfır veya başlatılmamış (genellikle etki aynıdır) değerlerin (SetIndexEmptyValue() işlevleri) çıktısını bastırmaktan bahsediyordum. Bu işlevler birbirine eşdeğer değildir.
Sadece imzalı, imzasız hayır. Peki ya uzun uzun veriler? Size söylüyorum - verilerin bit derinliğini değiştirirken ne yapacaksınız? Teknik oldukça hızlı gelişiyor ve 64-bit veri yollarına geçerken int tipindeki değişkenlerin boyutu değişecektir - CPP standardına göre, veri yolunun boyutuna bağlıdır ve minimum değerle sınırlıdır (değil maksimum), sırasıyla ve yalnızca int değil, aynı zamanda uzun aralığı. Bu büyüler kesinlikle tek bayttır. Tüm standartlar düşünüldükten sonra bir şey için mi? Sebeplerden biri program uyumluluğudur.
Saygılarımla, Vladislav.
İyi şanslar ve geçen trendler.