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
Fiyatlar, lotlar, para - sabit doğruluk.
Göstergeler - yüzer.
Bu fark özündedir, ancak her ikisini de temsil etmek için çift kullanılır. Aslında "programlama stili" dediğiniz şeyi tanımlar.
Yine "doğruluk" kriteri herkes için farklıdır. Benim kavramlarıma göre, örneğin, NormalizeDouble () en saçma, verimsiz ve buna göre kesinlikle gereksiz işlevdir.
değiştirsen daha iyi olmaz mı
Yoksa bu mümkün değil mi?
Sayıları çift kesinlik ile karşılaştırma sorunu çok zor ve materyalin temel cehaletinden geliyor.
Bu "sorunun" nasıl çözüleceğine dair net talimatlar vermek veya ikisinden biri =)
Ama performans sorunları olacaktır.
Teklifler ne olacak (MT geliştiricileri düzeyinde değil, kullanıcı düzeyinde)?
Tüm lot ve düzey hesaplamalarını tam sayılarda yapmak genellikle daha iyidir. Prensipte birçok kez daha hızlı ve ayrıklaştırma hataları olmadan.
Tekrar.
Fiyatlar, lotlar, para - sabit doğruluk.
Göstergeler - yüzer.
Bu fark özündedir, ancak her ikisini de temsil etmek için çift kullanılır. Aslında "programlama stili" dediğiniz şeyi tanımlar.
Yine "doğruluk" kriteri herkes için farklıdır. Benim kavramlarıma göre, örneğin, NormalizeDouble () en saçma, verimsiz ve buna göre kesinlikle gereksiz işlevdir.
Ondan sonra sadece NormalizeDouble()'ı kendim için zorunlu bir prosedür olarak kabul ettim. Kodun bazen nasıl çalıştığını gerçekten anlamıyorum, bu yüzden nasıl olması gerektiği ile ilgileniyorum.
NormalizeDouble() yerine hangi yaklaşımı önerirsiniz?
Teklifler ne olacak (MT geliştiricileri düzeyinde değil, kullanıcı düzeyinde)?
Tüm lot ve düzey hesaplamalarını tam sayılarda yapmak genellikle daha iyidir. Prensipte birçok kez daha hızlı ve ayrıklaştırma hataları olmadan.
PS Ve ComparePrice'ınız çok ilginç bir çözüm, hemen gelmedi.
Tekrar.
Fiyatlar, lotlar, para - sabit doğruluk.
Göstergeler - yüzer.
Bu fark özündedir, ancak her ikisini de temsil etmek için double kullanılır. Aslında "programlama stili" dediğiniz şeyi tanımlar.
Yine "doğruluk" ölçütü herkes için farklıdır. Benim kavramlarıma göre, örneğin, NormalizeDouble () en saçma, verimsiz ve buna göre kesinlikle gereksiz işlevdir.
Başlangıç olarak, sipariş vermek için birkaç Uzman Danışman yazın, aniden stoploss'un yanlış yerde 1 pip olduğu gerçeğinden müşterinin fırtınasını hissedin... Ve sonra onlara NormalizeDouble()'ın saçmalığını açıklayın. işlevi, nasıl yapabildiğini merak ediyorum =)
Ancak siparişinizden sunucudan alınan fiyatın bile normalleştirilmesi gerektiği ortaya çıktı!!!
Anlaşılmaz tarihsel verileri test ederken danışmanın anlaşılmaz çalışması hakkında çok fazla konuşma yapıldı ve konuşuldu.
Örneğin fiyat için. Teklifler, orada, sorar, ayaklar:
Bir fiyat karşılaştırması yaparsak, benimki gibi aşırı yüklenmiş bir fonksiyon kesinlikle gerekli değildir.
Ve basitleştirilmiş bir biçimde, ComparePrice kadar hızlı çalışır:
Başlangıç olarak, sipariş vermek için birkaç Uzman Danışman yazın, aniden stoploss'un yanlış yerde 1 puan çıkması gerçeğinden müşterinin fırtınasını hissedin... Ve sonra onlara NormalizeDouble'ın saçmalığını açıklayın () işlevi, nasıl yapabildiğini merak ediyorum =)
Bir sırrı ifşa edeceğim.
Başlamam gerekenden çok daha fazla ısmarlama uzman yazdım. Müşterinin fırtınasını hiç hissetmedim, çünkü hiçbir zaman bir sebep göstermedi. Programlarımdaki stoploss'un gerektiği yerde olması (ve "görünmemesi") garanti edilir. Buna göre, müşteriye, özellikle oradaki çok özel bir işlev hakkında hiçbir şey açıklamaya gerek yoktur. Bana öyle geliyor ki, sipariş için bir danışman yazmanın anlamı, müşteriyi bu tür soru ve açıklamalardan kurtarmaktır.