Kimin stratejiye ihtiyacı var? Çok ve ücretsiz - sayfa 58

Yeni yorum
 
1. Şamandırayı double ile değiştirmek için göstergeleri yeniden yazabilirim.
2. korumalı statik şamandıra fMicron = 0.000075f; // İki şamandırayı karşılaştırırken kullanılan katsayı
3. Gösterge Tabanı Oluşturucu:

 /// <summary>
/// The default constructor
/// </summary>
public Indicator ( )
{
    sIndicatorName   = string . Empty ;
    bSeparatedChart = false ;
    bIsDescreteValues = false ;
    afSpecValue     = new float [ ] { } ;
    fMinValue       = float . MaxValue ;
    fMaxValue       = float . MinValue ;
    bIsCalculated   = false ;
    parameters       = new IndicatorParam ( ) ;
    component       = new IndicatorComp [ ] { } ;
}




4. Baz Fiyat:



 /// <summary>
/// Calculates the base price.
/// </summary>
/// <param name="price">The base price type.</param>
/// <returns>Base price.</returns>
protected static float [ ] Price ( BasePrice price )
{
     float [ ] afPrice = new float [ Bars ] ;

     switch ( price )
     {
         case BasePrice . Open :
            afPrice = Open ;
             break ;
         case BasePrice . High :
            afPrice = High ;
             break ;
         case BasePrice . Low :
            afPrice = Low ;
             break ;
         case BasePrice . Close :
            afPrice = Close ;
             break ;
         case BasePrice . Median :
             for ( int iBar = 0 ; iBar < Bars ; iBar + + )
                afPrice [ iBar ] = ( Low [ iBar ] + High [ iBar ] ) / 2 ;
             break ;
         case BasePrice . Typical :
             for ( int iBar = 0 ; iBar < Bars ; iBar + + )
                afPrice [ iBar ] = ( Low [ iBar ] + High [ iBar ] + Close [ iBar ] ) / 3 ;
             break ;
         case BasePrice . Weighted :
             for ( int iBar = 0 ; iBar < Bars ; iBar + + )
                afPrice [ iBar ] = ( Low [ iBar ] + High [ iBar ] + 2 * Close [ iBar ] ) / 4 ;
             break ;
         default :
             break ;
     }
     return afPrice ;
}

6. Çalışan NET <-> MT köprüsüne sahibim. MT aracılığıyla FSB ticareti yapma zamanı. Tabii ki sadece "kaya gibi sağlam" olana kadar demo hesaplar için olacak.

 

Sanırım Aroon göstergesi sadece şunu kullanıyor: bIsDescreteValues = true;


RSI hakkında, formülü merak ettiğimi hatırlıyorum. 5-6 yıl önceydi. Sanırım bu formülü popüler bir TA kitabından kullandım. Tam olarak hangisi olduğunu hatırlamayın.

 

"Önceki çubuk değerini kullan"

Şahsen bunun FSB'nin en önemli özelliklerinden biri olduğunu düşünüyorum. 


         /// <summary>
         /// Sets the "Use previous bar value" checkbox
         /// </summary>
         /// <returns>Is any Changes</returns>
         public bool SetUsePrevBarValueCheckBox ( int iSlot )
         {
             bool isChanged = false ;

             for ( int iParam = 0 ; iParam < Slot [ iSlot ] . IndParam . CheckParam . Length ; iParam + + )
             {
                 if ( Slot [ iSlot ] . IndParam . CheckParam [ iParam ] . Caption = = "Use previous bar value" )
                 {
                     bool bOrigChecked = Slot [ iSlot ] . IndParam . CheckParam [ iParam ] . Checked ;
                     bool bChecked = true ;

                     // Entry slot
                     if ( Slot [ iSlot ] . SlotType = = SlotTypes . Open )
                     {
                        bChecked = true ;
                     }

                     // Open filter slot
                     else if ( Slot [ iSlot ] . SlotType = = SlotTypes . OpenFilter )
                     {
                        bChecked = EntryExecutionTime ! = TimeExecution . Closing ;
                     }

                     // Close slot
                     else if ( Slot [ iSlot ] . SlotType = = SlotTypes . Close )
                     {
                        bChecked = true ;
                     }

                     // Close filter slot
                     else if ( Slot [ iSlot ] . SlotType = = SlotTypes . CloseFilter )
                     {
                        bChecked = false ;
                     }

                     if ( bChecked )
                     {
                         for ( int iPar = 0 ; iPar < Slot [ iSlot ] . IndParam . ListParam . Length ; iPar + + )
                         {
                             if ( Slot [ iSlot ] . IndParam . ListParam [ iPar ] . Caption = = "Base price" & &
                                Slot [ iSlot ] . IndParam . ListParam [ iPar ] . Text     = = "Open" )
                             {
                                bChecked = false ;
                             }
                         }
                     }

                     if ( bChecked ! = bOrigChecked )
                     {
                        isChanged = true ;
                        Slot [ iSlot ] . IndParam . CheckParam [ iParam ] . Checked = bChecked ;
                     }
                 }
             }

             return isChanged ;
         }
 

Gösterge değerlerini tam hassasiyetinde görmek için grafik penceresinde F12 tuşuna basın.


Başka bir seçenek de "Komut Konsolu" kullanmaktır. ind xxxx , bar xxxx için göstergeleri gösterir




MT formüllerine derinlemesine girmiyorum. Muhtemelen çok farklı değiller. İşte varsayılan FSB RSI ve MT RSI.







______--

Düzenlemek:

Bu ek yumuşatma olmadan RSI'yı hesaplamaya çalıştım:

             for ( int iBar = 1 ; iBar < Bars ; iBar + + )
             {
                 if ( afBasePrice [ iBar ] > afBasePrice [ iBar - 1 ] ) afPos [ iBar ] = afBasePrice [ iBar ] - afBasePrice [ iBar - 1 ] ;
                 if ( afBasePrice [ iBar ] < afBasePrice [ iBar - 1 ] ) afNeg [ iBar ] = afBasePrice [ iBar - 1 ] - afBasePrice [ iBar ] ;
             }

             float [ ] afPosMA = MovingAverage ( iPeriod , 0 , maMethod , afPos ) ;
             float [ ] afNegMA = MovingAverage ( iPeriod , 0 , maMethod , afNeg ) ;

             //for (int iBar = iFirstBar; iBar < Bars; iBar++)
             //{
             //    afPosMA[iBar] = (afPosMA[iBar - 1] * (iPeriod - 1) + afPos[iBar]) / iPeriod;
             //    afNegMA[iBar] = (afNegMA[iBar - 1] * (iPeriod - 1) + afNeg[iBar]) / iPeriod;
             //}

             for ( int iBar = iFirstBar ; iBar < Bars ; iBar + + )
             {
                 if ( afNegMA [ iBar ] = = 0 )
                    afRSI [ iBar ] = 100 ;
                 else
                    afRSI [ iBar ] = 100 - ( 100 / ( 1 + afPosMA [ iBar ] / afNegMA [ iBar ] ) ) ;
             }


Ancak bu durumda 2009.3.24 için RSI değeri 74.800'e sıçrar.



----------------------


Güzel sözler için teşekkürler Stellarator!

Forex Strategy Builder'ı sadece sizin gibi insanlar yüzünden terk etmeyeceğim. Tam tersine bile FSb'yi daha sağlam ve kullanıcı dostu hale getirmek için tartışmaya açığım.

Bu doğrultuda FSB'ye MT göstergeleri ekleyebileceğimi düşünüyorum. MT uyumluluk modu gibi bir şey :)

MT_MACD, MT_RSI, ... Bunlar MT standardı olanlarla aynı parametrelerde olacak.


Bar Açma ve Bar kapama giriş/çıkış noktalarına çözüm bulmalıyız. FSB -> MT entegrasyonu için hayati önem taşırlar.


 
Stellarator >> :

.........Onları (iki arabellek) bir araya getirmek işe yaramayacak (düşündüm ki ... sadece 1/0 (bir bit maskesine dönüştürülebilir) değil, aynı zamanda fiyat etiketleri de olabilir) . Büyük ihtimalle gösterge değerleriyle bir şekilde ilgileneceğim... Bakalım... Yol boyunca...

Peki, neden olmasın (?).

Çeşitli gösterge arabelleklerinden birkaç değer almak için uzun süredir icustom'a tek bir çağrı kullanıyorum, özellikle optimize ederken ve hatta "ağır" hindilerle bu işlevi kodda birkaç kez kullanmak çok israf oluyor. Aslında, ihtiyacımız olan tek şey (maksimum) ticaretin yönünü ve seviyelerini ve SL & TP'yi elde etmektir ..... görev basit aritmetik ile çözülür.

İşte yalnızca bir ek arabellek (Sinyal) içeren gösterge kodunun bir parçası:

 // в самом кончике start такой фрагмент

      
   if ( Direction [ 0 ] ! = 0 )
      {
      if ( Direction [ 0 ] > 0 ) Signal [ 0 ] = Set_TP [ 0 ] / Point * 1000000 + Set_SL [ 0 ] / Point ;
      if ( Direction [ 0 ] < 0 ) Signal [ 0 ] = - ( Set_TP [ 0 ] / Point * 1000000 + Set_SL [ 0 ] / Point ) ;
      }
   return ( 0 ) ;

Ve işte EA kodundaki ters dönüşüm:

 int start ( )
  {
   // Получение значений из буфера индикатора в последней фазе формирования бара
   if ( TimeCurrent ( ) > ( Time [ 0 ] + CP60 )
      {
      Signal = iCustom ( NULL , 0 , "_iK_tay_v01M1" , Discret , 6 , 0 )
      }     

   if ( Time [ 0 ] ! = prevtime )
      { 
      Calcul ( ) ;
      //if (Tral !=0) CalcLevel();
      prevtime = Time [ 0 ] ;
      }
   else return ;

. . . . . . . . .

void Calcul ( )
  {
   OpenSell = 0 ; OpenBuy = 0 ; CloseBuy = 0 ; CloseSell = 0 ;
   
   if ( Signal > 0 ) 
      {
      OpenBuy = 1 ; CloseSell = 1 ;
      TP = NormalizeDouble ( Signal * Point / 1000000 , Digits - 1 ) ;      
      SL = ( Signal - TP / Point * 1000000 ) * Point ;   
      }
   if ( Signal < 0 ) 
      {
      CloseBuy = 1 ; OpenSell = 1 ;
      TP = NormalizeDouble ( MathAbs ( Signal ) * Point / 1000000 , Digits - 1 ) ;      
      SL = ( MathAbs ( Signal ) - TP / Point * 1000000 ) * Point ;   
      }   
   return ;
  }

Böylece tek bir gösterge çağrısı ile 3 gösterge değeri (yön, TP ve SL) elde ediyoruz. Elde edilen sonuçlar daha sonra istediğiniz gibi atılabilir :)

Prensip, umarım, açıktır.

 

Herkese günaydın!


Miroslav_Popov писал(а) >>

1. Şamandırayı double ile değiştirmek için göstergeleri yeniden yazabilirim.

Miroslav - bu önemli! Nedenlerinin bir kısmı zaten yazılarımda verildi. Ama işçilik maliyetlerini çok iyi anlıyorum... Ve şu anda (büyük olasılıkla) aradığınız köprü üzerinde çalışıyor olmanız veya başka bir şey.


Ama zaman bulunmalı. Tahminlerime göre - belirli bir saatten fazla değil (bir gün içinde). Çünkü bu sadece değişkenleri bildirirken birini diğeriyle değiştirmekten ibaret değildir (bu aynı zamanda en azından "güzellik için" (değişkenlerin sekmelerle tanımlandığı, vb.) önemli değil).

İlk olarak, şamandıranın bilerek kullanıldığı (hassasiyetin düşmesini sağlamak için) oldukça olası durumlar vardır. Burada kodun tamamını bir bütün olarak görmeniz gerekir.

İkinci olarak, bu tür ("yeni") sayıları karşılaştırma ve bunları FSB'de gösterme sorunu (bununla ilgili daha fazlası aşağıda, 2. paragrafta)

Kısacası - tüm kodu dikkatlice gözden geçirmeniz ve en azından gerçek matematiğin ikiye katlanmasıyla ilgili olası dezavantajları tahmin etmeniz gerekecektir.


Miroslav_Popov yazdı >>

2. korumalı statik şamandıra fMicron = 0.000075f; // İki şamandırayı karşılaştırırken kullanılan katsayı


(ve hemen aşağıda):

Gösterge değerlerini tam hassasiyetinde görmek için grafik penceresinde F12 tuşuna basın.

Ve bu sorunlardan biri! Neden tam olarak 0.000075? 0.00005 değil mi? Veya 0.000001? (benimki gibi)

Ayrıntılı bir problem (ilgilenenler için) ve bir soru:

Bildiğiniz gibi iki reel sayıyı eşitlik için karşılaştırmak asla benzer yapılarla yapılmamalıdır: 

double Value1, Value2;

if (Value1 == Value2) {
  // Some useful code there
}

Bunun nedeni, bazı hesaplamaların sonuçlarından sonra (özellikle çarpma / bölme temasındaki varyasyonlar), bu değişkenlerin değerlerinin görsel olarak benzer olabilmesidir (örneğin 1.0 ve 1.0), ancak YAPMAYIN gerçekten maç . (aslında 1.000001 ve 1.000000). Bu özellik, gerçek sayıların bilgisayarlardaki temsilinin belirli bir ayrıklığından ve hesaplamaların belirli bir (sonlu) ayrıklığından (doğruluğundan) kaynaklanmaktadır. Genel durumda, eşitlik karşılaştırması klasik temadaki (bu arada Miroslav tarafından kullanılan) varyasyonlara göre yapılır: 

if (Math.Abs(afIndValue[iCurrBar] - afIndValue[iBaseBar]) < fMicron) {
  // Some code there
}

Bu, bu durumda fMicron tarafından belirlenen bazı sonlu kesinlik ile eşitlik için iki gerçek sayının "klasik" karşılaştırmasıdır.


Ve burada potansiyel sorunlardan biri yatıyor. Bu fMicron'un değerini nasıl, kim ve hangi durumlar için belirlemeli? Miroslav'ınki gibi bir sabit her zaman iyi midir (anlamı da tartışılmaktadır)?


Genel olarak, entrikayı yakalamazsanız, aşağıdaki teorinin destekçisidir:

1. Genel durumda, eşitlik ve eşitsizlik (<, >) için bu tür değişkenlerin iki tür karşılaştırması vardır.

2. İki tür değişken vardır: sabit kesinliği garanti edilen değişkenler (fiyatlar, lotlar vb.) ve belirli bir kesinliği olmayan soyut değerler (gösterge değerleri gibi).

3. Eşitsizlik açısından, (herhangi bir türden) değişkenler (genel durumda) aptalca "alnında" (if (Değer1 < Değer2) { ...}) karşılaştırılır. Buradaki doğruluğu sınırlamak gerekirse (ki bu oldukça nadirdir), Miroslav'ınki gibi bir yapı kullanabilirsiniz: 

if (afIndValue[iBaseBar] < afIndValue[iCurrBar] - fMicron) {
  // Some code there
}

4. Ancak eşitlik açısından, üzerinde çalışılan verilere bağlı olarak soruna (genellikle) farklı şekillerde yaklaşılır.

4.1. İki sayıyı sabit bir hassasiyetle karşılaştırmak gerekirse (örneğin, emrin değiştirilmesi gerekip gerekmediğine karar vermek için iki fiyat değeri ("Sonuç Yok" ile karşılaşmamak için), genellikle böyle yapılır (ayrıca "klasik"):

 int ComparePriceInt ( double Value1 , double Value2 ) {
   Value1 - = Value2 ;
   Value2 = Point / 2.0 ;
   if ( Value1 > Value2 )
       return ( 1 ) ;
   if ( Value1 < - Value2 )
       return ( - 1 ) ;
   return ( 0 ) ;
}

Bizim durumumuz için fonksiyon gereksiz, ama mesele bu değil. İçindeki anahtar yapı Point / 2.0'dır . Bize gerekli, doğru ve yeterli hesaplama doğruluğunu veren bu fMicron'dur... BU ÖZEL DURUMDA ! İki fiyat karşılaştırıldığında (aynı Rakamlarla ve sonuç olarak Puanla ) (Nokta = 0.0001):

fMikron = 0.00005

ve 1.2345'i (sipariş fiyatı) 1.23451 (gösterge değeri) ile karşılaştırarak - eşitliği ve 1.23456 ile 1.2345 - eşitsizliği elde ederiz... Tahmin edin fMicron = 0.000075 ile son durumda ne olacak? ;) Elbette, değişkenleri bir (daha küçük) kesinliğe önceden normalleştirebilirsiniz. Ama bu bizim yöntemimiz değil :D...

Bir kez daha - bu parametrenin seçimi önemlidir ve her özel durum için "biraz benzersiz" :)1


Aşağıdaki paradigmayı öneririm :

1. Sabit hassasiyetli değişkenler, fMicron'un hesaplanan değeri ile karşılaştırılır (Puan / 2, örneğin fiyatlar durumunda)

2. Göstergelerin değerleri ve diğer benzer "sonsuz derecede doğru küçük şeyler" :), kullanılan cihazların minimum Puan değerine eşit fMicron sabiti ile 10'a bölünerek karşılaştırılır. Yani. Rakamların 4'ü geçmediği araçlarda - fMicron = 0.00001, Rakamlar = 5 ise, fMicron = 0.000001 ve benzer şekilde.

Miroslav - uzman görüşü gerekli :)?!


Şimdi halka bir soru:

NEDEN herhangi bir DataWindow'da (MT veya FSB'de (Gösterge Tabloları)) - gösterge değerleri her zaman sabit bir hassasiyetle gösterilir (Rakamlar = 4)? Neden 3 ondalık basamak değil? Veya 5, 6, 7, ...? :)?! Hayır, gerçekten mi?

Miroslav'ın bir "zulası" vardı (gizli özellik? ;)) - F12'den bahsediyorum! Ve MT'de ne basılacak?

Ve genel olarak, peki, bu sabiti kim belirledi? (4 ondalık basamak)

Sanırım çoğu enstrüman için (birisi onu hackledi) gelen tekliflerin (1.2345) boyutuyla neredeyse doğrudan ilgili. Ancak birçok DC'nin büyük bit derinliklerine geçtiği bir sır değil (örneğin, 5). Öyleyse neden gösterge değerlerini gerçekten enstrüman alıntıları (Rakamlar) ile aynı boyutta göstermiyorsunuz?

Yoksa temelde konuyla ilgili bir şeyi “yakalamıyor” muyum (lütfen - birisine açıklayın, belki bu “çok gerekli” çünkü ...)?!


Miroslav_Popov yazdı >>

3. Gösterge Tabanı Oluşturucu:

4. Baz Fiyat:

Miroslav, Kaynak sayfasında sunulan kodu çok iyi anladım :). Ve korumalı statik şamandıra [ ] Fiyat ( BasePrice fiyat ) ne yapar, çok iyi anlıyorum. Bu, kodumun hantallığına dair bir ipucuysa, depolama için ek tamponlar kullanmayı kasten reddettiğimi söyleyeceğim (genel durumda, fiyat tamponlarının kopyaları veya bunların hesaplanmış kopyaları (Tipik, vb.)). Ve yer kaydedilir ve her türlü Tipik'in olduğu yerde - hala hesaplanmaları gerekir!


Burada FSB ve MT'de gösterge değerlerinin hesaplanması yaklaşımındaki kritik farktan bahsetmek gerekiyor:

1. İlk olarak, en azından şimdilik - FSB'nin kendisi için FSB'ye yüklenen alıntılar statiktir, yani. bunları bir kez indirdi, tüm çubuk aralığı İÇİN gerekli göstergelerin değerlerini BİR KEZ hesapladı ve ardından bir ticaret robotunun davranışını taklit ederek basitçe "gezdi". Onlar. bir kez daha - gösterge değerleri, ticaret robotu sanallaştırmasına başlamadan ÖNCE bir kez hesaplanır. Bu, özellikle ticari işlemlerin öykünme hızını açıklar. MT'deki alıntılar sürekli gelir ve yerel strateji test cihazı geleceği GÖRMEZ, yani. her seferinde göstergenin değerini hesaplamak zorunda kalıyoruz. Ve aptalca Miroslav'ın yaklaşımını uygularsanız (tüm tamponun hesaplanması) ... bana sadece çürük yumurta atarlar :). Bu nedenle, IndicatorCounted() kullanımına özellikle dikkat edilir! Göstergeler, her özel durumda (tüm çubukların veya yalnızca birinin hesaplanması gerekiyorsa) neredeyse mümkün olduğunca hızlı hesaplanır. Bazı yerlerde, bir şey - yine de optimize edebilirsiniz, ancak boş zamanlarınızda ...

2. Res. her seferinde (yeni bir tick geldiğinde) ek tamponlarda fiyat değerleri oluşturmak gereksizdir. Onları hesaplamak ZORUNDA DEĞİLLER, bu yüzden bırakın işlevlerin kendileri yapmasına izin verin (aynı Hareketli Ortalama, vb.). Alan kaydedilir, mantık basitleştirilir (bu arabelleklerde her seferinde hangi çubukların yeniden hesaplanacağını analiz etmek gerekli değildir), hız kaydedilir (genel durumda daha yüksek bir yerde bile). "Bence - yani" (c) Winnie the Pooh


Göstergelerin dönüştürülmesine bir kez daha değinirsek, muhtemelen önemli olan, işlevlerin (ve göstergelerin kendilerinin) mantığını tamamen korumamdır, MT'deki belirli bir kullanım durumu için onu biraz değiştiririm. Ancak, göstergenin kendisini kontrol etmek için parametrelerin sırasını ve adlarını saklıyorum.

Çocuklar - sonuçta kaynağa bakın. "Güzel" yapmaya çalıştım :).


Dönüşümümün son anlamı aşağıdaki gibidir. Örneğin, Pozisyonun Açılış Noktasına ve ek mantık için üç göstergeye sahibiz. İşte sipariş verme kodunun nasıl görüneceği (tabii ki kabaca):

 if ( IsSignal ( iCustom ( NULL , 0 , "fsbIndicator1" , SLOT_TYPE_LC , Param2 , Param3 , . . . , 0 , 0 ) )
     & & IsSignal ( iCustom ( NULL , 0 , "fsbIndicator2" , SLOT_TYPE_LC , Param2 , Param3 , . . . , 0 , 0 ) )
     & & IsSignal ( iCustom ( NULL , 0 , "fsbIndicator3" , SLOT_TYPE_LC , Param2 , Param3 , . . . , 0 , 0 ) ) )
{     
// Открываем длинную позицию (предпоследний 0 в значениях индикаторов - указатель на буфер логики длинных позиций (1, соотв. - на буфер логики коротких))
     // Если у нас значение POP берется из еще одного индикатора, то это значение берется аналогично, только меняется логика поведения индикатора:
     // iCustom(NULL, 0, "fsbIndicator", SLOT_TYPE_POP, Param2, Param3, ..., 0, 0)
}

Bunun gibi bir şey. Parametre değerlerinizi iCustom'a gönderin ve hepsinin sinyal vermesini bekleyin. Herşey. Gösterge değerlerinin kendilerinin analizi yok... neden?

Bence güzel... ya da değil :)?

 

Göstergeler hakkında:

Hakkında (Aroon ve bIsDescreteValues = true;) dikkate alacağım.


RSI hakkında ...

Miroslav - istenen yapı kafanızı karıştırdı :). Tekrar etrafa yorum yapmak için çok tembel olmayın ve "tesadüf" değerleri almak için DOĞRU ÇALIŞIYOR göstergesini DOĞRU KULLANIN :). Size hatırlatmama izin verin - RSI'yi hesaplamak için klasik formül, MA'nın üstel çeşitliliğine (özellikle yumuşatılmış) dayanmaktadır. SO bu yumuşatma modunu (düzeltilmiş) gösterge parametrelerinde BELİRTİN... ve sonuçlar sizi "hoş bir şekilde şaşırtacak" :) (varsayılan olarak, size hatırlatırım, Klasiklerle tutarsızlıklar veren Basit kullanılır)! Bu prosedürü kendim yapamam - ama sözlerimden %100 eminim. vazgeç beni :)?

Test sonuçlarına bağlı olarak, aşağıdaki öneri olacaktır, istenen kodu kaldırın ve RSI (ve sırasıyla RSI'nin kendisini) kullanan tüm göstergelerde Smoothed'da maMethod parametresinin varsayılan değerini yapın . Böylece varsayılan olarak kullanıcılardan böyle bir soru gelmez. AMA böylece göstergelerde bu parametrenin seçimini ÇALIŞABİLİR yapın! (örneğin, RSI hesaplamalarının sonucuna dayanarak, aynı zamanda RSI'nin kendisinin mevcut davranışıyla birlikte RSI MA Osilatörünü dönüştürdüm - ilgili parametrede orada neyin belirtildiği önemli değil)

 
Miroslav_Popov >> :

"Önceki çubuk değerini kullan"

Şahsen bunun FSB'nin en önemli özelliklerinden biri olduğunu düşünüyorum.

AH EVET!

Bu gerçekten de FSB'nin en önemli özelliklerinden biridir. Ve bu özellik göz önüne alındığında, gösterge mantığının doğru çalışıp çalışmadığını test etmeye özen göstermeye çalıştım.

"Varsayılan" değer sayısını gösteren kod için teşekkürler! dikkate alalım...

 
rider >> :

Peki, neden olmasın (?).

Çeşitli gösterge arabelleklerinden birkaç değer almak için uzun süredir icustom'a tek bir çağrı kullanıyorum, özellikle optimize ederken ve hatta "ağır" hindilerle bu işlevi kodda birkaç kez kullanmak çok israf oluyor. Aslında, ihtiyacımız olan tek şey (maksimum) ticaretin yönünü ve seviyelerini ve SL & TP'yi elde etmektir ..... görev basit aritmetik ile çözülür.

...

Prensip, umarım, açıktır.




:), evet, elbette işe yarayacak (geçen sefer kasıtlı olarak ifademi "kaba" hale getirdim), değerleri tek bir parametreye katlama sorununa aşinayım :). Ve verilen kod için teşekkürler (hemen soru şu ki - orijinal değerlerde hiç tutarsızlıklar oldu mu ve "daha sonra genişletildi" mi? hala iki katına çıktı ...)

Anahtar soru... BU BELİRLİ DURUMDA GEREKLİ Mİ?

İki sebep olabilir:

1. Ek bir arabellek kullanımı (benim için bu çok önemlidir) - sonuçta, göstergelerde çok fazla yoktur. AMA AMA yeterince sahibim (görünüşe göre sonunda Ishimoku'yu alma zamanı - ve her şey netleşecek :)))

2. Göstergeyi kodunuzdan çağırma hızı (sizin örneğiniz)... Cevabım şart değil! Tüm sorumlulukla beyan ederim. Motivasyon:

Her yeni onay işaretiyle, yine de göstergeye tırmanmanız gerekir (zorunlu). Böyle? (peki, orada - istenen fiyatları veya başka bir şeyi alın) Her birinde olmasa bile, orada ihtiyacınız olduğunda. Ana ipucu, görünüşe göre, danışmanın bir yinelemesinde birden fazla iCustom çağrısının, göstergenin birden fazla yeniden hesaplanmasını oluşturması mı? vazgeçirmek zorunda kaldı! Anahtar nüans, "Uzman Danışmanın bir yinelemesinin sınırı" dır. Yani - bu sınırlar dahilinde, gösterge BİR KEZ hesaplanır (ilk çağrıda)! %100 kesinlik ile beyan ederim. Diğer tüm çağrılar onu hiç başlatmaz, ancak gerekli tamponlardan gerekli değerleri almanız yeterlidir. Değişmeyen giriş parametreleriyle %100 koşul (arabellek ve ofset hariç). Kural, bir sembol içindeki hesaplamalar için geçerlidir. Ancak, iCustom diğer TF'lere ve araçlara döndüğünde bile ilkenin devam ettiğini düşünüyorum.


Genel olarak - Bu gece Ishimoku'ya bakacağım - kesinlikle orada karar vereceğim, sonuçta mantık için iki tampon var ... veya bir :)

 

Genelde akşama kadar herkes (işe gitti).

Problem hakkında 

We have to find solution to Bar Opening and Bar closing entry/exit points. They are vital for FSB -> MT integration.

düşünmek.


Ancak büyük olasılıkla (bu konuda MT'den gelen sinyal eksikliği göz önüne alındığında) - yukarıdaki kod (önceki-önceki sayfadaki şablon) aşağı yukarı optimaldir (biraz iyileştirilmesi gerekebilir ... akşamları I sorunu "derinleştirmeye" çalışacaktır)

1...51525354555657585960616263646566
Yeni yorum