"Likit Grafik" makalesi için tartışma - sayfa 3
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Sebebini bulabildiniz mi?
Katkıda bulunmak için elimden geleni yapmaya çalıştım, belki hatayı bulmada yardımcı olur. Farklı zamanlarda çekilen resimlerde, gösterge grafiğinin ana grafiğe göre nasıl değiştiğini görebilirsiniz.
Bana öyle geliyor ki bunun nedeni, her haftanın başında, her hafta grafiği biriktiren ve kaydıran fazladan bir mum olmasıdır, bu H1 tabanlı günlük grafik için geçerlidir. Hafta sonu ve hafta başında bir ekran yapabilirsiniz, daha net olacaktır.
Evet, öyle. Kaymanın belirli değerlerinde "hayalet çubuklar" görünür - daha fazla ayrıntı için bkz. Makalenin 4. bölümünde bunların ortaya çıkış nedeni de açıklanmıştır. Haftaların birleştiği noktada ortaya çıktıkları için, en çok yüksek zaman dilimlerinde fark edilirler. Özellikle günlük grafikte (örneğinizde olduğu gibi), çünkü ekran birkaç haftalık bir zaman aralığını gösterir ve her hafta kayma giderek daha belirgin hale gelir.
Bu bir hata değil, bir özelliktir. "Hayali çubukları" atabilirsiniz, ancak bu veri kaybıdır ve iyi bir şey değildir. İdeal olarak, bu tür yerlerde orijinal grafiği kaydırmak istersiniz, ancak böyle bir seçeneğiniz yoktur. Başlangıç ve sonuç grafiklerinin senkronizasyonu sizin için kritikse, GetRatesLC() işlevi tarafından döndürülen "ekstra" çubukları gösterge arab elleğine kopyalamadan hemen önce filtreleyebilirsiniz.
Benzer bir şey yaptım. Herhangi bir hayalet çubuk olmadan benim için çalışıyor gibi görünüyor.
Kaynak kodun tamamını analiz edemediğim için, sadece yüzeyde bazı garip şeylerle (bence) karşılaştım.
İlk olarak, birkaç yerde tO-=PeriodSeconds() yapısını gördüm. Bu şekilde yapılabileceğinden emin değilim, çünkü t0'dan PeriodSeconds'u çıkararak bir önceki çubuğa ulaşabilirsiniz. t0'ın sınırların dışında olduğu durumun özü, bu sıvı çubuğun henüz oluşmaya başlamamış olmasıdır ve başlangıcını yapay olarak bir periyot kaydırmaya çalışmaya gerek yoktur.
İkinci olarak, kapanış zamanı sayıya göre belirlenmemelidir - açılışa göre mevcut döneme teorik olarak kaç temel çubuk sığar, ancak mevcut dönemin her çubuğu için ayrı ayrı açılış zamanını alın, bir sonraki çubuğun açılış zamanını alın, ikincisi için temel dönemin bir çubuğunu arayın ve temel dönemdeki önceki çubuğu okuyun - bu sıvı çubuğun sonu olacaktır.
Buna neden ihtiyacım var? Amerikalıların, Avustralyalıların, Japonların vb. günlük grafiklerde ne gördüğünü görmek istiyorum. Terminal zamanı herkes için farklı olduğundan, günlük bir mumun oluşum zamanı herkes için farklıdır ve bu nedenle günlük grafiklerdeki resim herkes için farklıdır. Durumu farklı zaman dilimlerinde izleme fırsatına sahip olarak, doğru giriş anını kaçırmamak için daha fazla fırsat vardır. Vardiya zamanını opsiyonel olarak belirlenmiş bir çubuğun zamanından çıkararak gerekli tikin zamanını çıkarmaya çalışmazsak ne olur? Ve GTM zamanını referans noktası olarak alın, kaydırma süresini bu süreden çıkarın ve bu süreden sonra gelen ilk kene yeni bir mum oluşturmaya gidecek ve buna göre bu süreden önce gelen kene önceki mumun son kenesi olacaktır. Bu, normal bir grafiğin oluşumuyla aynı prensiptir, eğer terminal zamanı 00:00 ise, ilk tikin ne zaman geldiği önemli değildir, yine de yeni bir mumun ilk tiki olacaktır.