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.
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.
Son zamanlarda, şubelerden birinde (tam olarak hatırlamıyorum), bir kişi bir danışmanın anlaşılmaz çalışmasına yakındı. Ancak siparişinizden sunucudan alınan fiyatın bile normalleştirilmesi gerektiği ortaya çıktı!!! 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?
kompost : Teklifler ne olacak (MT geliştiricileri düzeyinde değil, kullanıcı düzeyinde)?
Örneğin fiyat için. Teklifler, orada, sorar, ayaklar:
intComparePrice(doublea, doubleb){a -= b;
b = Point / 2.;
if(a > b)return(1);
if(a < -b)return(-1);
return(0);
}
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.
Katılıyorum, Omega'da her şey INT'deydi. Her şeyi önce MT'de INT'ye çevirmeyi ve sonra hesaplamayı mı teklif ediyorsunuz? PS Ve ComparePrice'ınız çok ilginç bir çözüm, hemen gelmedi.
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 =)
VBAG : Ancak siparişinizden sunucudan alınan fiyatın bile normalleştirilmesi gerektiği ortaya çıktı!!!
Mümkün değil (c). Sakatat MT zanormalizeny neredeyse hiçbir yerde. Anlaşılmaz tarihsel verileri test ederken danışmanın anlaşılmaz çalışması hakkında çok fazla konuşma yapıldı ve konuşuldu.
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.
MQL5.com web sitesine giriş yapmak için çerezlerin kullanımına izin vermelisiniz.
Lütfen tarayıcınızda gerekli ayarı etkinleştirin, aksi takdirde giriş yapamazsınız.
Hesabınıza giriş yaptınız. İki faktörlü kimlik doğrulama devre dışı bırakıldı. Yeniden kurup yeni bir QR kodu tarayın veya iki faktörlü kimlik doğrulama devre dışıyken devam edin.
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.