MQL4 ustaları için soru. Yine Çift Karşılaştırma hakkında. - sayfa 2

 
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.
 
komposter :
 //--- Если value1 равняется value2 до precision знака после запятой, возвращает true, иначе - false.
bool equal ( double value1 , double value2 , int precision = 8 )
{
    return ( nd ( abs ( nd ( value1 , precision ) - nd ( value2 , precision ) ) , precision ) < nd ( MathPow ( 0.1 , precision ) , precision ) ) ;
}
Kod açık ve örneğiniz çok açıklayıcı! Ama bu karışıklık
 nd ( MathPow ( 0.1 , precision ) , precision )
değiştirsen daha iyi olmaz mı
 //--- Если value1 равняется value2 до precision знака после запятой, возвращает true, иначе - false.
bool equal ( double value1 , double value2 , int precision = 8 )
{
    return ( nd(nd ( abs ( nd ( value1 , precision ) - nd ( value2 , precision ) ) , precision )) , precision )  == 0.0 ) ;
}
Yoksa bu mümkün değil mi?
 
Irtron :
Sayıları çift kesinlik ile karşılaştırma sorunu çok zor ve materyalin temel cehaletinden geliyor.
Ama forumda kıskanılacak bir sabitlik vylazit ile.
Bu "sorunun" nasıl çözüleceğine dair net talimatlar vermek veya ikisinden biri =)

irtron :
Ama performans sorunları olacaktır.
Teklifler ne olacak (MT geliştiricileri düzeyinde değil, kullanıcı düzeyinde)?
 
komposter :
Teklifler ne olacak (MT geliştiricileri düzeyinde değil, kullanıcı düzeyinde)?
Örneğin fiyat için. Teklifler, orada, sorar, ayaklar:
 int ComparePrice ( double a , double b )
{
    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.
 
Irtron :
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.
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?
 
Irtron :
kompost :
Teklifler ne olacak (MT geliştiricileri düzeyinde değil, kullanıcı düzeyinde)?
Örneğin fiyat için. Teklifler, orada, sorar, ayaklar:
 int ComparePrice ( double a , double b )
{
    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.
 ComparePrice ComparePrice
 
Irtron :
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 =)
 
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.
 
Irtron :
Örneğin fiyat için. Teklifler, orada, sorar, ayaklar:
Bu zaten bir şey. Özellikler geldi ;)
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:
 int start ()
{
    double a = 1.23450001 , b = 1.23449999 ;
    int start1 = GetTickCount () , c1 ;
    for ( c1 = 0 ; c1 < 100000000 ; c1 ++ ) ComparePrice ( a , b ) ;
    int end1 = GetTickCount () ;
    
    int start2 = GetTickCount () , c2 ;
    for ( c2 = 0 ; c2 < 100000000 ; c2 ++ ) equal ( a , b ) ;
    int end2 = GetTickCount () ;
 
    Print ( " ComparePrice: " , ( end1 - start1 ) , " , equal: " , ( end2 - start2 ) ) ;
 
    return ( 0 ) ;
}
 
int ComparePrice ( double a , double b )
{
    a -= b ;
    b = Point / 2 .;
    if ( a > b )
        return ( 1 ) ;
    if ( a < - b )
        return ( - 1 ) ;
    return ( 0 ) ;
}
 
bool equal ( double a , double b )
{
    return ( MathAbs ( a - b ) < Point ) ;
}
2007.09.10 03:19:24 CheckCompareDoubleSpeed GBPUSD,Günlük:KarşılaştırFiyat: 20922 , eşit: 20453
 
Integer :

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.
Neden: