Biraz şaşırdım :) Retorik bir soru DEĞİL paylaşmaya ve sormaya karar verdim. - sayfa 7
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
Mesele bir kez daha test cihazında değil! test cihazında değil , geçmişin devam ettirildiği ve bağlantının kesildiği gerçek koşullarda
Gerçek koşullarda gösterge sıfırlanır ve yeniden hesaplanırsa, bunda yanlış bir şey yoktur.
Başka bir soru ortaya çıktı. Çoğu insanın burada yapacağı bir şey yok, değil mi? Otururlar ve terminalin normal işlevselliğini mql5'te yeniden yazarlar. Muhtemelen yakında birisi mql5'te bir terminalin tamamını yazacaktır.
Gerçek koşullarda gösterge sıfırlanır ve yeniden hesaplanırsa, bunda yanlış bir şey yoktur.
Başka bir soru ortaya çıktı. Çoğu insanın burada yapacağı bir şey yok, değil mi? Otururlar ve terminalin normal işlevselliğini mql5'te yeniden yazarlar. Muhtemelen yakında birisi mql5'te bir terminalin tamamını yazacaktır.
Tabii ki, sorun değil. Bir terminalde asılı 100 ZUP'niz olduğunda (ben sadece bir örneğim), sorun değil...
Aynı soru geldi. Herkes sadece kendi çan kulesinden konuşmayı sever, neden?
Birden fazla göstergenin kullanıldığı yer burasıdır:
Normal işlevin IndicatorCount'un etkisi onun için ölümcüldür (kişisel olarak kontrol ettim). Ve sınıflar olarak uygulandığında, iletişim kesintileri genellikle mor renktedir.
PS Bir MA için kesinlikle endişelenecek bir şey yok
Tabii ki, sorun değil. Bir terminalde asılı 100 ZUP'niz olduğunda (ben sadece bir örneğim), sorun değil...
Aynı soru geldi. Herkes sadece kendi çan kulesinden konuşmayı sever, neden?
Birileri her zaman yapabileceğinden fazlasını ister. Ama neden bu kadar çok?
Göstergeyi sıfırlama sorununu beş satır kodla aşabilirsiniz. İlk çubuğun zamanını hatırlayın, eğer değiştiyse, tam bir yeniden hesaplamaya ihtiyacınız var. Son çubuğun numarasını hatırlayın, sıfırlama durumunda bu çubuktan yeniden hesaplamaya devam edin, o kadar.
Çan kulemden, hiçbir şeyi argümanlarla desteklemeden, çan kulemin daha doğru olduğunu söylemekten korkmuyorum, nokta.
Birileri her zaman yapabileceğinden fazlasını ister. Ama neden bu kadar çok?
Göstergeyi sıfırlama sorununu beş satır kodla aşabilirsiniz. İlk çubuğun zamanını hatırlayın, eğer değiştiyse, tam bir yeniden hesaplamaya ihtiyacınız var. Son çubuğun numarasını hatırlayın, sıfırlama durumunda bu çubuktan yeniden hesaplamaya devam edin, o kadar.
Çan kulemden, hiçbir şeyi argümanlarla desteklemeden, çan kulemin daha doğru olduğunu söylemekten korkmuyorum, nokta.
Bu kadar özgüvenli olmayın. Sadece dinlemeyi değil, başkalarını duymayı da öğrenin.
Ortada hikaye değişebilir ve yaklaşımınız cehenneme gidecek. Bunu Renat'a sor.
MT4'teki IndicatorCounted()'da az önce ipucumdan düzeltilen bir hata, hurdaya doğru yazılmış göstergeler bile gönderdi (özellikle küçük zaman dilimlerinde ZigZag).
Bu konuya yaklaşımınızdan bahsetmiyorum bile ....
Seninle tartışmayacağım bile, çünkü bu durumda tamamen haksızsın.
Bu kadar özgüvenli olmayın. Sadece dinlemeyi değil, başkalarını duymayı da öğrenin.
Ortada hikaye değişebilir ve yaklaşımınız cehenneme gidecek. Bunu Renata'ya sor.
MT4'teki IndicatorCounted()'da az önce ipucumdan düzeltilen bir hata, hurdaya doğru yazılmış göstergeler bile gönderdi (özellikle küçük zaman dilimlerinde ZigZag).
Seninle tartışmayacağım bile, çünkü bu durumda tamamen haksızsın.
Çubuk sayısı artmış, ancak çubuğun süresi değişmemiş veya birden fazla çubuk eklenmiş olsun, sıfırlama sırasında birkaç kontrol daha ekleyin.
Kendine güvene gelince, tam tersi, burada özellikle kendine güvenen sensin, zaten kendini MQ'dan daha havalı bulan üçüncü kişi.
Çubuk sayısı artmış, ancak çubuğun süresi değişmemiş veya birden fazla çubuk eklenmiş olsun, sıfırlama sırasında birkaç kontrol daha ekleyin.
Kendine güvene gelince, tam tersi, burada özellikle kendine güvenen sensin, zaten kendini MQ'dan daha havalı bulan üçüncü kişi.
Ne kontrolleri? Durum. Eski çubukta yeni bir onay işareti belirir. Hiçbir şey değişmedi - ne toplam çubuk sayısı ne de son çubuğun açılış zamanı , aynı zamanda
son 30 bar yeniden yazıldı (açılış/kapanış fiyatları, maksimum, minimum, az da olsa değişti).
Algoritmanızla ne yapacaksınız? Hiç bir şey! Sadece bu durumda işe yaramayacak. Ve gösterge tamamen yanlış olacak!
En son sürümlerden önce MT4'te ne vardı - vakaların% 70'inde bu duruma hiçbir şekilde tepki vermedi.
Ancak bu sorunu analiz ettikten sonra her şey düzeltildi, burada Stingo bununla ilgili yazıyor: https://www.mql5.com/en/forum/132422
Kendimi diğerlerinden daha iyi görmüyorum. Aksine, MT4 ve MT5'teki tüm hataların düzeltilmesine aktif olarak yardımcı oluyorum - herhangi bir MetaQuotes temsilcisine sorun.
Ve bazı mekanizmaların istediğiniz gibi uygulanmadığı gerçeği - herkesi memnun edemezsiniz ....
Bu ilginç bir soru, neyin doğru olduğu, tarih düzeltmesinden önce veya sonra neyin olduğu. Düzeltilen çubuklara geri dönmezseniz gösterge, geçmiş düzeltilmemiş gibi çalışmaya devam edecektir. hrenfx'in bu konuya yaklaşımı tam olarak bu, eski hikayeyi doğru buluyor, tam tersi sizde var.
Ayrıca sadece standart prev_calculated kullanmanız gerektiğine dair bir görüş var, seçenek yok. Gösterge ağırsa, başlangıçta hesaplanan çubuk sayısını sınırlayın. Gerisi bir tef ile dans ediyor, sonuç şüpheli.
Bu ilginç bir soru, neyin doğru olduğu, tarih düzeltmesinden önce veya sonra neyin olduğu. Düzeltilen çubuklara geri dönmezseniz gösterge, geçmiş düzeltilmemiş gibi çalışmaya devam edecektir. hrenfx'in bu konuya yaklaşımı tam olarak bu, eski hikayeyi doğru buluyor, sizde tam tersi var.
Ayrıca sadece standart prev_calculated kullanmanız gerektiğine dair bir görüş var, seçenek yok. Gösterge ağırsa, başlangıçta hesaplanan çubuk sayısını sınırlayın. Gerisi bir tef ile dans ediyor, sonuç şüpheli.
Neyin doğru neyin yanlış olduğuna herkes kendisi karar verir. ZigZag için yukarıda açıklanan durum tamamen ölümcüldür. MA için - değerinde 0.0001 sapma olacaktır...
Fikir genellikle empoze edilebilir (yanlış olduğunu söylemiyorum).
Genel olarak, tartışmayı burada bitirmeyi öneriyorum. Teorik düşünceler hiçbir şeye yol açmaz ..
Test cihazında, gösterge hesaplamalarının özel optimizasyonu mükemmel şekilde çalışacaktır, ancak terminalde hoş olmayan geçmiş kaymaları ve yanlış hesaplamalar görünebilir.
Bu arada, MT5, geçmiş temelin bütünlüğünün gerçek zamanlı olarak çok etkili ve anlık kontrolünü kullanır, bu da prev_counted'ı sıfırlama sıklığını sıfıra yükseltir. Bu sayacı doğru bir şekilde hesaba katmaz, ancak kendi optimizasyonlarınızı gerçekleştirirseniz, gerçek işte birçok sorunu yakalayabilirsiniz. Dakika geçmişi güncellemeleri, sunucunun kendisi tarafından anında terminallere iletilir.
Test cihazında, gösterge hesaplamalarının özel optimizasyonu mükemmel şekilde çalışacaktır, ancak terminalde hoş olmayan geçmiş kaymaları ve yanlış hesaplamalar görünebilir.
Ve bunun hakkında konuşuyorum.
Belki hala prev_counted'ı sıfıra değil, ilk değiştirilmemiş değere nasıl sıfırlayacağınızı düşünüyorsunuz?