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

 
Miroslav_Popov >> :

Veya yüzde cinsinden bir düşüş ekleyebilirsiniz, böylece daha net olur. Teşekkür ederim.

 

Bu, FSB'den MQL4'e Dönüştürücünün başlangıcı olabilir.

Herhangi bir yardım veya geri bildirim çok takdir edilmektedir.


 //+------------------------------------------------------------------+
//|                   FSB__Bar_Opening - Bar_Closing.mq4 v0.0.1 Beta |
//|                                 Copyright © 2009, Miroslav Popov |
//|                                              http://forexsb.com/ |
//|                                                                  |
//| An exmple EA pattern:                                            |
//| * Enter the market at Bar Opening                                |
//| * Exit the market at Bar Closing                                 |
//+------------------------------------------------------------------+
#property copyright "Copyright © 2009, Miroslav Popov"
#property link       "http://forexsb.com/"

// The time span before bar closing time in seconds.
// It determines the time interval for position closing.
extern double ClosingTimeSpan = 10 ;


int start ( )
{
   // Check if there are open positions from the previous bar
   int iOrders = OrdersTotal ( ) ;
   if ( iOrders > 0 )
      ClosePositionsAtBarClosing ( true , true , ClosingTimeSpan ) ;
 
 
   
   // Opening Logic Conditions
   bool bLongEntryAllowed   = false ;
   bool bShortEntryAllowed = false ;

   // Put the entry logic rules here ...
   
   if ( iMA ( NULL , 0 , 13 , 0 , MODE_SMA , PRICE_CLOSE , 1 ) >
       iMA ( NULL , 0 , 13 , 0 , MODE_SMA , PRICE_CLOSE , 2 ) )
      bLongEntryAllowed = true ;
   else
      bShortEntryAllowed = true ;


   // Entry at Bar Opening
   iOrders = OrdersTotal ( ) ;
   if ( iOrders = = 0 )
   {
       if ( bLongEntryAllowed | | bShortEntryAllowed )
         OpenPositionAtBarOpening ( bLongEntryAllowed , bShortEntryAllowed ) ;
         
      iOrders = OrdersTotal ( ) ;
       if ( iOrders > 0 )
         return ( 0 ) ;
   }



   // Exit Logic Conditions
   bool bCloseLong   = true ;
   bool bCloseShort = true ;

   // Put the exit logic rules here ...
   
   // Exit
   if ( bCloseLong | | bCloseShort )
      ClosePositionsAtBarClosing ( bCloseLong , bCloseShort , ClosingTimeSpan ) ;
}

// Entry at a Bar Opening price.
//
// MetaTrader does not provide an onBarOpen event so we check the current tick volume.
// We open a position when the current tick volume is equal to 1.
void OpenPositionAtBarOpening ( bool bLongEntryAllowed , bool bShortEntryAllowed )
{
   if ( ! bLongEntryAllowed & & ! bShortEntryAllowed )
   { // An entry is not allowed.
       return ( 0 ) ;
   } 
   
   // Check for Bar Opening
   if ( iVolume ( NULL , 0 , 0 ) > 1 )
   {    // This is not the first tick.
       return ( 0 ) ;
   } 
   
   int iLots = 1 ;

   // Check the free margin.
   if ( AccountFreeMargin ( ) < ( 1000 * iLots ) )
   {
       Print ( "We do not have money enough! Free Margin = " , AccountFreeMargin ( ) ) ;
       return ( 0 ) ;   
   }
      
   int ticket = 0 ;
   if ( bLongEntryAllowed )
   {
      ticket = OrderSend ( Symbol ( ) , OP_BUY , iLots , Ask , 3 , 0 , 0 , "Bar Opening" , 0 , 0 , Green ) ;
   }
   if ( bShortEntryAllowed )
   {
      ticket = OrderSend ( Symbol ( ) , OP_SELL , iLots , Bid , 3 , 0 , 0 , "Bar Opening" , 0 , 0 , Red ) ;
   }
   
   if ( ticket > 0 )
   {
       if ( OrderSelect ( ticket , SELECT_BY_TICKET , MODE_TRADES ) )
         Print ( "Position opened at: " , OrderOpenPrice ( ) ) ;
   }
   else 
   {
       Print ( "Error opening a position: " , GetLastError ( ) ) ;
   }
      
   return ( 0 ) ;
}


// Exit at a Bar Closing price (almost).
//
// MetaTrader does not provide an onBarClose event so we are not able to close a position
// exactly at Bar Closing. We workaround the problem by closing the position within a time span
// near to the bar closing time. In the cases when there is no any ticks within this period,
// we close the position att he next bar opening price.
void ClosePositionsAtBarClosing ( bool bCloseLong , bool bCloseShort , datetime dtClosingTimeSpan )
{
   int   iOrders = OrdersTotal ( ) ;
   bool bIsOpen = false ;

   for ( int iOrder = 0 ; iOrder < iOrders ; iOrder + + )
   {
       OrderSelect ( iOrder , SELECT_BY_POS , MODE_TRADES ) ;
      
       if ( ( OrderType ( ) = = OP_BUY | | OrderType ( ) = = OP_SELL ) & & OrderSymbol ( ) = = Symbol ( ) )
       {    // There is an open position for this symbol.

         datetime dtOpeningTime     = iTime ( NULL , 0 , 0 ) - TimeSeconds ( iTime ( NULL , 0 , 0 ) ) ; // The opening time of current bar
         datetime dtClosingTime     = dtOpeningTime + Period ( ) * 60 ;                        // The closing time of current bars
         datetime dtCurrentTickTime = TimeCurrent ( ) ;                                      // The time of current tick
         
         if (
            dtCurrentTickTime > dtClosingTime - dtClosingTimeSpan | | // The current tick is within the closing time span.
             iVolume ( NULL , 0 , 0 ) = = 1                                  // or this is the first tick of next bar
             )
         {
             if ( OrderType ( ) = = OP_BUY & & bCloseLong )
             {    // Close a long position
               bIsOpen = OrderClose ( OrderTicket ( ) , OrderLots ( ) , Bid , 3 , Violet ) ;
               
               if ( bIsOpen )
                   Print ( "Long position closed at: " , OrderClosePrice ( ) ) ;
               else
                   Print ( "Error closing a position: " , GetLastError ( ) ) ;
             }
             else if ( OrderType ( ) = = OP_SELL & & bCloseShort )
             {    // Close a short position
               bIsOpen = OrderClose ( OrderTicket ( ) , OrderLots ( ) , Ask , 3 , Violet ) ;
               
               if ( bIsOpen )
                   Print ( "Short position closed at: " , OrderClosePrice ( ) ) ;
               else
                   Print ( "Error closing a position: " , GetLastError ( ) ) ;
             }
         }
       }
   }
   
   return ( 0 ) ;
}
 

FSB'nin bir strateji ile bir dll oluşturması kötü olmaz ve fonksiyon şöyle görünebilir:

 #define inp   100
//---

#import "FSB.dll"
int     bEntryAllowed ( double close [ inp ] , double open [ inp ] , double high [ inp ] , double low [ inp ] , volume [ inp ] ) ;
#import


yani, dll'ye bir dizi çubuk gönderdi ve stratejiden bir yanıt aldı


dll'nin kendisi böyle

#define WIN32_LEAN_AND_MEAN  // Exclude rarely-used stuff from Windows headers
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
//----
#define MT4_EXPFUNC __declspec(dllexport)
#define inp 100
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
BOOL APIENTRY DllMain ( HANDLE hModule , DWORD ul_reason_for_call , LPVOID lpReserved )
   {
//----
   switch ( ul_reason_for_call )
     {
       case DLL_PROCESS_ATTACH :
       case DLL_THREAD_ATTACH :
       case DLL_THREAD_DETACH :
       case DLL_PROCESS_DETACH :
         break ;
     }
//----
   return ( TRUE ) ;
   }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
MT4_EXPFUNC double __stdcall int     bEntryAllowed ( double close [ inp ] , double open [ inp ] , double high [ inp ] , double low [ inp ] , volume [ inp ] )

   {
   int out ;

   //--- strategy

   if ( close [ 1 ] > close [ 0 ] ) out = 1 ;
   if ( close [ 1 ] < close [ 0 ] ) out = - 1 ;

   return ( out ) ;
   }
sonuçta, hala tüm göstergeleriniz var ve yalnızca zaman serisi verilerine ihtiyacınız var
 

Tam FSB <-> MT4 köprüsünü daha sonra sağlayacağım.

Böylece FSB, MT'den kotasyon ve hesap bilgilerini alacak ve alım satım emirlerini geri gönderecektir. Bu şekilde FSB stratejilerini MT'de takas edebilecektir.


Şimdi, herhangi bir birlikte çalışma olmadan EA olarak MT'deki FSB stratejilerine uyacak bazı temel EA çerçeveleri yapmaya çalışıyorum.


Aşağıdaki gibi birkaç basit desene ihtiyacım var:


* Çubuk Açılışında (veya Gösterge değerinde) şu durumlarda girin (ekleyin, azaltın, kapatın):

- koşul1 == doğru; ve

- koşul2 == doğru; ve

- koşul3 == doğru; ve

- koşul4 == doğru

* Şu durumlarda Bar Kapanışından çıkın:

- koşul1 == doğru; veya

- koşul2 == doğru;

veya

* Gösterge değerinde çıkış.

veya

* Kalıcı Stop Loss'ta Çıkış

veya

* Giriş kurallarına uyarak ters çevirin.


Göstergelerin çoğu standarttır ve diğerleri oldukça basittir ve MQL4'te kolayca yeniden yazılabilir. Temel EA modeline sahip olduğumuzda, göstergeleri çevirmek sorun olmayacaktır.


Şu anda test ettiğim şeyler:

Pozisyonu "Bar Açılışında" açın ve "Bar kapanışında" kapatın.


Bu yüzden iki yeni ürün geliştirmeyi umuyorum:

1. FSB - MT veri beslemesi ve yürütme köprüsü

2. MQL4'e strateji ihracatçısı


Muhtemelen her iki program da açık kaynak olacaktır.

 

(oh, bu konuda zaten oldukça sessiz olduğunu düşündüm ... hadi canlandıralım :) ?! (Çok yazacağım... Mantıklı olmaya çalışacağım;) ve aşırı yüklememek için birkaç mesaja böleceğim)


Lord - hoş geldiniz!


Miroslav - ilk önce birkaç kelime "hava durumu hakkında" (lirik kısım) ... (Rus dilini anladığınızı umuyorum, çünkü düşüncelerimi en son İngilizce olarak ifade etme riskini alacağım :))) .


Ürün kesinlikle harika! Hem eski bir programcı hem de soyut bir kullanıcı (soyut yazılımın) olarak deneyimlerime dayanarak konuşuyorum. Kişi ona sevgi duyar (çünkü her şey çok dikkatli yapılır) ve programın gelişiminin "beklenmedik bir şekilde" durmayacağını (ölmeyeceğini) umar. Evet, büyük olasılıkla bazı mantıksal hatalar var (açıklayıcı bir örnek Data Horizon'dı), arayüzde küçük kusurlar var ... Ama genel olarak - BU BİR ŞARKIDIR! Bu sadece bir şarkı!!!


Sizden kamuoyunun dikkatini bir gösterge gerçeğe daha çekmenizi rica ediyorum. Eleştiriye karşı tutum ve sorunları / eksiklikleri / yeni fırsatları / vb. tartışma tarzı. Konunun başlangıcı, alternatif bir ürünün geliştirilmesinin nerede başladığı ve SSB yazarının kendisine yöneltilen yorumlara nasıl tepki verdiği bağlamında bu benim. Miroslav'ın ayrıca ÜCRETSİZ bir program geliştirmek için bir "arabasına" sahip olduğunu düşünmüyorum (ve kendisinin de böyle bir programcı olduğunu). Ama sizin ve benim için (konuşmak için) zaman bulur, bizim yorumlarımıza ve taleplerimize göre ürününü geliştirir, hataları düzeltir, yeni bir şeyler SUNAR (son gönderilere bakın). Ve SSB ile yukarıdaki durumda olduğu gibi, histeri olmadan her şey sakin, ölçülür. (Ekstra) saygıyı hak ediyor. Saygılarımla, Miroslav...


Lirik kısmı bitiriyorum (soyut şimdi) - şahsen "rastgele fiyat hareketi" teorisinin destekçisiyim. Yani, bu konuda, piyasada çalıştığına ikna olan belirli bir insan çevresinin (http://www.bigmany.ru gibi sitelerin yaratıcıları dahil) bakış açısını tamamen paylaşıyorum (şimdi Forex ve "yanındaki her şey"), piyasanın kendisinin (sadece) iki ana göstergesinden ikincisini bulmanın bir yolu olmadığı (Hacim (Hacim) hakkında konuşuyorum) - bu sadece işe yaramaz ve anlamsız (herhangi bir makul anlamdan yoksun) herhangi bir teknik bilgiye ve daha az derecede temel analize güvenmek...


Bu konuda hiç bitebilir :), ama bildiğiniz gibi - Rusya aptallar ve yollar ile ünlüdür ve bu ifadenin ilk noktasını kullanarak - hala "yapma" fikrini bırakmıyorum milyonlarca" :D, ama aslında - Ben sadece ilginçim. "Analistlerin görüşlerini" dinlemek ilginçtir (burçları olan astrologlar gibi - "bir sürü uzman var", çok az mantıklı), sadece tablolara bakmak ilginç (kabul etmelisiniz - büyüleyici), ilginç kodu kurcalamak için (insanların bu göstergeyle neyi ifade etmeye çalıştığını gerçekten anlamaya başlarsınız), ... sadece - ilginç ... "Sistemi" aldatmak ilginç (veya daha iyisi - bir kez DEĞİL) ... Bu yüzden buradayım (piyasada, şartlı). Ve sadece kendime değil, halka da fayda sağlamayı umuyorum. Çünkü Miroslav gibi o da hayatta belli bir fedakardır.


Şu anki görüşüm, şu anda dünya çapında (ve açık çoğunluğun) kullanımda olan teknik analiz sistemlerinin gerçekten de piyasayı ETKİLEDİĞİ yönünde. Onlar. monitörlere bakan ve göstergelerinin değerlerine göre kendilerini yönlendiren bir insan kalabalığı, oybirliğiyle belirli bir yönde hareket bekliyor, işlem yapıyor .. ve bu fiyatı hareket ettiriyor. Küçük ölçekte olsun, her zaman olmasa da (sonuçta TA'ya aldırış etmeyen "fabrikalar, gazeteler, vapurlar" sahipleri, bir noktada belirli bir miktar alıp satmaları gerekiyor. zaman, hiçbir yere gitme). Ama oluyor! Diğer bir deyişle, "bilgi sahibi" olarak (aynı TA), piyasadaki pozitif rastgele hareketlerinizin olasılığını (biraz mı?) %50'den fazlasına kaydırmayı deneyebilirsiniz. Kolay değil... AMA mümkün! Madem ikna oldum. Bu önermede hayal kırıklığına uğrar düşmez piyasadan ayrılacağım... ... genel olarak, yukarıya bakın)

 

Pekala, şimdi konuya.

1. Bir durgunluk varken, diye düşündüm. Evet, Miroslav'ı bekleyebilirsiniz (MT ile FSB arasında bir köprü, hatta bir strateji derleyicisi yaptığında). Ama sonunda - sonuç, en azından kendisi bir şeyler yapan kişi tarafından alınır :). Şimdi (zaten garantili) bu araca (FSB) sahip olduğum, örneğin MT'm olduğu, bu iki varlığın dışında başka bir şey olmayacağı düşüncesinden yola çıktım - o zaman onların çerçevesinde çalışırız, yani: FSB (şu anda) ) kapalı sistem; her halükarda bizimle ticaret MT olacaktır; herhangi bir senaryoda bir danışmanın (ticaret robotu) koduna ihtiyaç duyulacaktır - evet, göstergelerin değerlerinin (kabaca) kaydırıldığı bir tür evrensel şablon olmalıdır ve bu kadar, ayrıca "onaylı şema"; cevap göstergelere ihtiyaç vardır.


2. Hemen EA koduna odaklanacağım. Bu yüzden, basit Uzman Danışmanların yaratıcılarının iyimserliğini paylaşmıyorum - peki, terminalin ve pazarın çalışması sırasında anormal durumların sayısını hayal etmek imkansız. Ancak paradan bahsediyoruz, şakalar burada uygun değil (hata kodunu kontrol etmediler - bir tür varsayılan eylemi hesapladılar ... ve yelken açtılar - sanki olmamış gibi 1000 dolar (şartlı olarak)). Onlar. Gerçekten parayla çalışan (veya daha iyisi - gerçek parayla çalışan) herhangi bir uzmanın dış olaylara tepki açısından "güçlendirilmiş somut" olması gerektiğine inanıyorum. Kod, terminalin, sunucunun veya piyasadaki hareketlerin işleyişindeki maksimum varyasyon sayısını sağlamalıdır. Kısacası - bu oldukça ciddi ve bir atlama (yazılı) ile çözülmedi. Memnuniyetle, bu tür kalıpların yaratılmasına katılmaya hazırım. Ancak...


3. Ben de en alttan gitmeye karar verdim. Alandan bir fikir - uzmanı çalıştıracak hiçbir şeyimiz yoksa (göstergelerin kendileri) - neden bir uzmana ihtiyacımız var :)?! Ve göstergeleri aldı ...

Gerekçe şuydu. İlk olarak, aslında hiç kimse FSB'deki göstergelerin değerlerinin MT'deki normal veya ek göstergelerin değerlerine eşdeğer olduğunu garanti edemez. Ve her iki programda da "karşılaştırılabilir" sonuçlar elde etmek için - değerlerin eşleşmesi gerekir. İkincisi, göstergelerin sayısı (normal olanlar) hala farklıdır. Ve harici kullanmak (ve aramak) için ... Bir şekilde ya düzenli ya da kendimi (hayatta) seviyorum ... ("tuhaflıklarımı" yazacağız :)). Üçüncüsü, bana göre, FSB'den gelen gösterge kodunun "damıtılması", Miroslav'nın bahsettiği gibi hala doğrudan ve mega bir görev değil - algoritmaların kendileri oldukça basit, Miroslav'ın göstergelerinin kendileri kod açısından çok "düzenlenmiş" ( kod birleştirilmiştir), yani. Kabaca söylemek gerekirse - bir kez bir şablon oluşturuyoruz ve hindilerin kodunu tek tek "şekillendiriyoruz" (peki, bu çok ideal bir tutum :))). Dördüncüsü de var - ilgilendim :).

Genel olarak, hafta sonu ve oturdu. Bir şeye başlamadan önce, genellikle "uzun süre koşuyorum" (bu durumda sanırım). Şablonu yeniden yapmak için fazla zamanım olmayacak (bunu anlıyorum). Özellikle gösterge sayısı belirli bir rakamı aştığında. Bu yüzden kilit noktalar hemen tasarlanmalıdır. Sonuç olarak, aşağıdaki binadan ilerledim:


- Bunlar yalnızca göstergeler olmalıdır (ve yalnızca Expert Advisor'ın gelecekteki kodu için işlevler değil). Yine de, bilginin görsel algısı bir kişi için (ve özellikle benim için) önemli bir rol oynar ve (daha sonra) uzman kodundan bir gösterge çağırmak böyle bir sorun değildir (forum zaten iCustom hakkında birçok kopyayı kırdı - ne zaman çok fazla fikir var, genellikle her şeyi kendim kontrol etmeyi tercih ederim, "saha testlerimin" sonucu yapacak, muhtemelen hafif bir ek yük var, ama BÜYÜK DEĞİL (Bunu tüm sorumlulukla beyan ederim) ve yaklaşımın evrenselliği açısından ihmal edilebilirler))). Ancak "özel uzmanlar" için :) (her ihtimale karşı) göstergelerdeki hesaplamaların kendileri aynı tipte ayrı bir işleve taşınır (aşağıya bakın).


- Göstergeler, orijinal FSB'deki ile aynı değerleri vermelidir ( aşağıdaki özel madde ). Onlar. FSB'den gelen kod esas alınır ve mümkünse mümkün olduğunca az sonuçlandırılır.


- Kod, IndicatorCounted ile doğru çalışacak şekilde optimize edilmelidir (yani hız için)


- Göstergelerin parametreleri ve değerleri aynı tipte ve tek tip olmalıdır. Kendi başına veri türleri açısından değilim. Miroslav'ın gösterge koduna bakarsanız, hem giriş parametrelerinin hem de çıkış arabelleklerinin iyi bir tek biçimliliğini (tekdüzeliğini) görebilirsiniz. Görev, orijinal resmi korumaktır, böylece kullanıcılar parametreleri belirlerken veya gösterge değerleri alırken gezinmeyi kolaylaştırır.

- Bir önceki paragrafın sonucu - ... mmm (dikkat - bu önemli ). Tüm göstergeleri kullanmanın kilit noktası, bir tür kendi değerlerini üretmeleri değildir. Başardıkları bu SİNYALLER ! Eh, gerçekten, benim için, bir kişi için - fark nedir, orada bazı indekslerin değeri nedir şimdi veya biraz sonra (?!) Hepsi aynı "anlaşılmaz sayılar". Açıktır - bu, "Satın Al" veya "Sat" olduğunda :). Diğer her şey - "net değil"! Miroslav bu fikri çok zarif bir şekilde kullandı ve her göstergede (uzun ve kısa pozisyonlar için) göstergenin kullanımına bağlı olarak (Konum Noktası veya Mantık Durumu olarak) karşılık gelen değeri alan iki tampon oluşturdu. bir pozisyonu açma/kapatma veya bir Evet/Hayır filtresinin değeri (açılma mantığında tümü "Evet" ise - açma, kapama mantığında en az biri "Hayır" ise - kapatma (genellikle RTFM)). Parlak! ;) Alışılmadık yoldan aşağı indim ve bu davranışı taklit ettim . Şu anda, ilk iki gösterge tamponu (değerleri Veri Penceresinde görülebilen) sırasıyla. sırasıyla uzun veya kısa tarafta açık pozisyonlar için filtreler (1/0) veya fiyat değerleri ile istenen tamponlar. Onlar. daha sonra, göstergeleri EA kodunda kullanırken, onun için ne-orada, nerede-orada ve hangi değerlerin belirli bir gösterge oluşturduğu önemli olmayacak - ilk iki tamponun değerlerini analiz etmek yeterli olacaktır. çok basit bir konu için (Evet / Hayır (şartlı olarak) veya doğrudan fiyat etiketini oradan alarak) ... İşte bu kadar! Burada bir nüans var - Ishimoku'da neredeyse% 100 "tökezleyeceğim" (göstergenin kendi arabelleklerinin sayısının neredeyse MT'nin sınır değerine yaklaştığı (8)) - bir düşünelim, reddetmek istemiyorum güzel bir fikir (ilk iki tamponla). Bunları 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...

 

Genel olarak, kısaca (özetler): kalite (FSB uyumluluğu, hatasız vb.), daha fazla kullanım kolaylığı, hız, kod okunabilirliği. Bu sırayla.

Peki, ve (aslında) - ne oldu ... (kısa tarihçe)

- Tüm göstergeler dosya adı önekinde "fsb" değerine sahiptir (örnek: "fsbBlaBlaBla.mq4").


- Göstergeleri rastgele bir sırayla aldım, bu yüzden beni suçlama. Şimdiye kadar, var, yani. Daha fazla tartışma/analiz vb. için - Bence bu yeterli.


- Miroslav, Hareketli Ortalamayı ve mantıksal arabellek değerlerini hesaplamak için (kaynaklara (sayfanın en altına) yerleştirilen) üç harici işlev kullanır. Onlarla başlamalıydım. Tüm işlevler, kitaplık işlevleri (" fsbCommon.mqh ") olarak düzenlenmiş tek bir dosyaya (" fsbCommon.mq4 ") sarılır. Bu operadan (" fsbConstants.mq4 ") başka bir dosya daha var ve bunlar sırasıyla kodda kolaylık sağlamak için sabitler içeriyor. İşlevlerin kendileriyle ilgili özel bir sorun yoktu ("mantık osilatörlerinin" ilk mantığını biraz karmaşıklaştırdım, ek kontroller için (sınır dışı diziler, garantili doğru başlangıç değerleri (tarihte ilk) (Miroslav, bir bu konudaki kodda mantıksal hata).. .. ve uzun bir süre iShift'in MovingAverage'deki davranışını "taklit etmeye" çalıştı, böylece işlev, bu parametrenin herhangi bir makul değeri için ortaya çıkan arabelleğin değerlerini doğru bir şekilde doldurur. (ve yalnızca orijinal orijinal kodda verilen kısıtlamalar için değil) ... sonuç olarak, bu konuyu şimdilik terk ettim, başına bir "sap" koydum ("0" dışında iShift ile işlev çalışmıyor henüz çalışma, ancak henüz gerekli değil))) MovingAverage zahmetli olduğu ortaya çıktı, ancak bir taşla birkaç kuşu öldürür.Tamponu işlevden MT'de bir değer olarak döndürmek mümkün değildir (belki de değil) gerekli) - sonunda ek bir parametre belirdi ( afTarget ) Ayrıca, IndicatorCounted () dikkate alındığında, bir adım daha Parametre, işleme için ilk çubuğun değerinden sorumludur. Eh, son ek parametre, "fiyat sabitini" MT cinsinden ayarlar, buna göre Hareketli Ortalamanın kendisinin değerlerinin mevcut dizi dizilerine göre hesaplandığı veya (eğer değer iAppliedPrice "fiyat sabitleri" MT değerlerinin dışında) - temel alınarak afSource . (dolayısıyla kodun aşırı yüklenmesi) Programlamanın nüansını hemen belirteceğim - duruma göre seçimlerle serpiştirilmiş döngülerin olduğu yerlerde - döngüler seçimlerin içine eklenir ve (genellikle daha mantıklı olan) tersi değildir. Nasıl doğru yapacağımı bilmediğim için değil, ne kadar hızlı olduğunu bildiğim için yaptım :)! (pekala, gelecekte, kodu analiz etmek isteyen herkes bunun üzerinde durmayacağım - rica ederim, ancak "kodun aptallığı hakkında" soruyu sormadan önce (potansiyel olarak) buna neyin sebep olabileceğini biraz düşünün. programlama).


Başka bir nüans MovingAverage ile bağlantılıdır (birisi için bilgilendirici olabilir) - çünkü. Üstel yumuşatma modlarında (Düzleştirilmiş dahil) Hareketli Ortalama değerler doğrudan kendi önceki değerlerine bağlıdır - "başlangıç noktası" seçimi çok önemli hale gelir (daha sonraki hesaplamalar için hangi değerin temel alınacağı). Buna genellikle birkaç yaklaşım vardır. Biri bir önceki dönemin kapanış fiyatını alıyor. Birisi bir önceki dönem için fiyat ortalamasını aldı N... Miroslav ikinci yola gitti. MT açıkça önce gelir. Bu nedenle, grafiğin başında bu iki düzleştirme modundaki önemli tutarsızlıklar (MovingAverage ve diğer her şeyi (" fsbTest.mq4 ")) test etmek için bir boşluk ekledim! Ve MovingAverage'ın kendisinin verilerinin kullanılabilirliği işlevinde benim tarafımdan getirilen kısıtlamalar ÖNCEKİ iFirstBar veya benzer miktarda hesaplanmış değer SONRASINDA iFirst Bar. Çünkü göstergelerin kendileri grafikteki minimum çubuk değeri için bir sabit kullanır (şimdi 2000) - bu herhangi bir durum için yeterli olmalıdır (çünkü henüz 200'den büyük periyotlara sahip parametreler görmedim). Tabii ki, aynı anda birden fazla MA kullanılmadığı sürece ;).


- Bir önceki paragrafa benzetilerek, bu projedeki çalışmamda zaten kullandığım harici alt işlevler için dosyalar oluşturuldu ("st": " stCommon.mq4 ", " stCommon.mqh ", " stConstants.mq4 ")


- Şey, aslında - göstergelerin kendileri. Çok kısa bir ifadeyle (örnek olarak " Çubuk Aralığı " nı alalım):

 //harici int slotType = SLOT_TYPE_LC;
harici int indLogic = INDICATOR_RISES ;    // (INDICATOR_RISES <= indLogic <= INDICATOR_LOWER_LL)
harici int nBar'lar = 1 ;                  // 1 <= nBar <= 200
harici int fSeviye = 0 ;                  // 0 <= fSeviye <= 500
harici bool iPrvs = Doğru ;                // Doğru yanlış

slotType setler tip yuvalar içinde FSB (Pozisyon Noktası veya Mantık Durumu) terimleri . Yalnızca giriş/çıkış filtreleri olabilen değil, aynı zamanda açılış/kapanış fiyatını da ayarlayabilen bu göstergeler - bu parametre, göstergenin mantıksal arabelleklerinde tam olarak ne üreteceğini belirler. fsbConstants.mq4'teki tüm sabitleri görün (orada her şey oldukça açık)

indLogic - aslında, gösterge için mantıksal bir koşul (değere bağlı olarak farklı bir anlamsal yük taşır) slotType )

Parametreler forexsb.com'daki gösterge kaynaklarında göründükleri sırayla ve FSB'nin kendisinde nasıl görüntülendiklerine göre daha da ileri gider. Parametre sınırları yorumlarda belirtilir ve PCheck() alt işlevi çağrılarak init() çağrılırken kontrol edilir.

 çift LPIndBuffer [];            // Uzun pozisyonlar #1
çift SPIndBuffer [];            // Kısa pozisyonlar #2

doubleIndBuffer [ ];              // Göstergenin değerleri #3

doubleIndBufferDD [ ];            // 4 numaralı çizim için ek tampon
doubleIndBufferDU [ ];            // Çizim #5 için ek tampon

Arabelleklerle, küresel düzeydeki her şey gösterge arabellekleri olarak kullanılır (göstergenin kendisine bağlıdır). Sadece istenen mantıksal olanlar (LPIndBuffer[], SPIndBuffer[]) (her zaman ve her zaman bu sırada (#0 - uzun pozisyonlar, #1 - kısa pozisyonlar)), IndBuffer[] - göstergenin kendi verileri. Ama bu durumda, bir renk histogramı kullanıldığı için, bu tampon sadece değerlerin kendisini taşır ve renksel geriverim için iki ek tampon kullanılır (dürüst olmak gerekirse, MT sadece göstergeleri aktararak programlamaya başladı :) ve nasıl yapabilirsiniz? aksi takdirde MT içindeki renk histogramlarının davranışını simüle edin - bunu hiç bulamadım (kim söyleyebilir? Bu mümkünse)). DataWindow'da hiçbir şekilde görüntülenmezler.

AT içinde() her şey her zamanki gibi (parametre değerleri kontrol edilir, göstergenin kendisinin ve endekslerin isimleri ayarlanır, arabellekler eklenir vb.)


Deinit() içinde, boş zamanımda (henüz bir öncelik değil) göstergeyi KAPATMAMA durumunda (ek kolaylık, böylece parametrelerin sıfırlanmaması vb.) mantık eklemeyi düşünüyorum.


Başlat() çok ilkel. Görevi, grafikte yeterli çubuk olup olmadığını kontrol etmek (herhangi bir MA'yı ve genel olarak hesaplamak için) ve başarılı çağrı üzerine göstergenin özel çizimi çağrılan göstergenin kendisini hesaplama işlevini çağırmaktır (gerekirse). bir şekilde özel bir şekilde çizilebilir, bu durumda olduğu gibi -once)


Hesaplamak() - gerçek hesaplamalar. Kod genel olarak Miroslav'ın koduna benzer, IndicatorCounted() ile ilgili optimizasyonlar için istisnalar yapılır. Göstergeyi hesaplamak için ek gösterge arabellekleri gerekiyorsa, bunlar işlevin kendi içinde (statik) ayarlanır (göstergenin dizinlerini boşa harcamamak için) ve BufferSync() işlevi tarafından hizmet verilir. İşte ayrı bir şaka - başlangıçta hesaplamaları bir sabit parametre (iMaxBars) ile sınırlama girişimi vardı. Tarih, yokluk, geleceğe hareket (tırnakların gelmesi, dizilerde SAĞA artış) dizi dizilerinin davranışının "alan testleri" (bölüm 2) (şimdi görsel olarak, grafik temsili hakkındayım) )), ... geçmişe doğru hareket (geçmiş eksik olduğunda (tabloda sola hareket ediyoruz) ve terminal onu sunucudan yükler... ve diziler SOL'a genişler)... Yani. .. Kırıldı. Güzelce yaptım (yapmaya çalıştım) - genişlemenin yönüne bağlı olarak BufferSync () ve dizi yanıtını genişletir. sola veya sağa, boş EMPTY_VALUE değerlerini doldurun. Burada yalnızca MT'nin kendisi normalde dizin dizilerini SOL'a genişletmez. DAİMA onları sağa doğru genişletir ([0] Çubuğunun yanından). Umarım neden bahsettiğim açıktır - tarihte bir sonraki geri atlama sırasında, grafikteki çubukların değeri iMaxBars'ı aştığında (yine atlayarak) - göstergenin değerlerini çizmeyeceği durumlar oldukça mümkündür. iMaxBars'ın solunda, ancak burada "garip veriler" var, iMaxBars'ın solunda kolayca olabilir. Belki kimse onları izlemeyecek ... Ama "güzel değil" (bizim yöntemimiz değil). Ve gerekli olan tek şey, MT'nin kendisinin, tamponları doğru yönde boş değerlerle tamamlamasıdır ... Potansiyel olarak böyle bir durumu yakalamak mümkündür, ancak ... Genel olarak, en başından çiziyoruz. grafik ... _her zaman_. (Eh, bu özel gösterge için mümkün olduğu kadar)


Başka bir nüans, IndicatorCounted() ile ilişkilidir - öyle görünüyor ki - ilahi bir işlev. Hesaplanan çubukların değerlerini döndürün ve size karşı herhangi bir iddia olmayacaktır... OLACAKTIR! Bence suçlanacak olan IndicatorCounted()'in kendisi değil (MQ'daki programcılar gibi), ancak bu işlevin ilahi amacına ulaşmamış bir grup özel gösterge programcısı. Bu nedenle, her zaman az sayıda potansiyel değer döndürmek zorunda kalır. Ya tüm grafiği (IndicatorCounted() == 0) ya da ilkini ((IndicatorCounted() == Çubuklar - 1) veya iki (IndicatorCounted() == Çubuklar - 2) çubuğu yeniden hesaplarız. örneğin, bağlantı kopmuşsa ve tablo birden fazla çubuk ileride "koştuysa" - hepsi bu ... "ağaçlar ayakta öldü" (IndicatorCounted() == 0) - tüm grafiği yeni bir Neden? atlanan çubukların sayısını döndürmek imkansız mıydı (3, 4, ... 5... 10...)? (başlangıçta anladığım kadarıyla bu işlevin amacı buydu) Genel olarak, böyle. ..

... RSI'da "tökezledim". Ve her anlamda. İlk olarak, Miroslav'ın kodunu anlamadım (ona sorular aşağıda olacak). İkincisi, göstergeyi test ederken, MT ve FSB içinde elde edilen değerlerde tutarsızlıklar gördüm! Hayır, hiç de düşündüğün gibi değil ("çarpık bir şekilde dayandı" - peki, kabul et, düşündün;)). Ne yazık ki, mesele şu açıklamalarda görünüyor:

 kayan nokta [] afPos = yeni yüzer [ çubuklar ];
...
yüzer toplam ; _
...

Kısaca konuşmak gerekirse - yüzer ! Biraz düşündükten sonra şimdilik yavaşladım. ilk tez (doğruluk ve kalite) sorgulanabilir hale geldi (ve bu bir önceliktir).


Burada şu akıl yürütme mümkündür: Bir yandan, dalgalanma fena değil, olduğu gibi, gösterge değerlerinin "kabalaştırılması", ticaret stratejisini piyasadaki rastgele artışlara daha az duyarlı hale getirmesi gerekiyor. Öte yandan, örneğin, bazı fLevel'leri (örneğin 1.0) geçerken - kabul edeceksiniz: 0.99998 ve 1.00001 iki büyük farktır :). Ve bu tür tutarsızlıklar var. Ve poz şu anda açılırsa, ancak aslında FSB seviyesi hala 1.0'a ulaşmıyor ve düşüyorsa, o zaman kim suçlanacak? (göstergeleri aktaran :D?!)


Aslında iki çözüm var (şamandıra MT'nin desteklenmediği göz önüne alındığında!):


- MT'nin kendisinde bir kayan noktayı taklit edin (NormalizeDouble(X, Digits + 2) gibi bazı yürek burkan yapılarla) - peki, her yerde değil, ancak her çarpmanın / bölmenin herhangi birine göre olduğunu düşünün


- FSB'deki şamandırayı ikiye katlayın. Burada açıkça sınırlı olan değişikliklerin kapsamını anlamanız gerekir, ancak her yerde dikkatli bir şekilde yürümeniz gerekir. Ve insanlarda oluşturulan stratejilerin potansiyel sonucunun "yüzebileceği". Ve genel olarak, Miroslav'nın buna ihtiyacı var mı? (benim naçizane fikrim, FSB'nin buna ihtiyacı olduğu yönünde, çünkü ekstra hassasiyet kimseye zarar vermedi, ancak hesaplamaların hızında (bu hedef takip edildiyse (?), çünkü daha fazla neden göremiyorum) bu zaman bölümünde gerçekliğin Önemli bir etkisi olmamalıdır.) Bu konuda MQ'daki adamlarla aynı fikirdeyim - çünkü. tamsayılı matematik (bazı Decimal) ile çalışmazsak, en azından mümkün olan maksimum doğrulukla deneyeceğiz. Genel olarak, işte böyle bir ... kolay bir soru değil ...

 

Kısacası - uyku zamanı :). Ayrıntı için özür dilerim (tekrar yapmayacağım, sadece noktaya kadar).


Bir fikir duymak istiyorum - bu konuya devam etmek gerekli mi (ve sonra göstergelerin geri kalanını kürekle "acele ettik")? Hatta bazı sırayla yapabilirim (çünkü hala ilk karışıklık :)), kim, belki, ne yapılması gerekiyor. Zaman, ne yazık ki, genellikle yoksundur (ofiste genel müdür yardımcısı - "gün uçar gider" :D). Onlar. Genelde akşamları vakit buluyorum. Ama günde bir veya iki gösterge sağlayabileceğimi düşünüyorum...



Peki, Miroslav'a sorular - konuyla ilgili ...

1. fMicron değeri nedir? ((yansıma üzerine) koydum 0.000001 , öyle görünüyor, ya da daha az bit derinliği?)


2. bisDescreteValues parametresi nedir (mantık osilatöründe). Bunun anlamını anlıyorum - ama varsayılan değeri nedir? Ve değişiklik hangi koşullara bağlı? (veya diyelim ki - neyle bağlantılı olduğu (FSB arayüzünde veya başka bir yerde))


3. Aslında RSI hakkında, bu nasıl bir yapıdır?:

 için ( int iBar = iFirstBar ; iBar < çubuklar ; iBar ++)
{
afPosMA
[ iBar ] = ( afPosMA [ iBar- _ 1 ] * ( iPeriod- _ 1 ) + afPos [ iBar ]) / iPeriod ;
afNegMA
[ iBar ] = ( afNegMA [ iBar - 1 ] * ( iPeriod- _ 1 ) + afNeg [ iBar ]) / iPeriod ;
}

:)? Motivasyonda bir soru şu: Eğer bana göre görüş değişmiyorsa düzeltilir MA. Kodun tamamı bağlamında - önceden hesaplanmış MA'ya uygulanır ve yalnızca ilk değerin "canlı" kaldığı düzleştirilmiş bir MA oluşturur :). Mantıklı bir soru gibi - burada gereksiz olan nedir? Bu yapı, diğer şeylerin yanı sıra ÇALIŞABİLİR DEĞİL (!) Göstergenin kendisinde (her zaman düzleştirilir) ve buna bağlı olanlarda RSI yumuşatma modlarının seçimi. Veya afPos, afNeg için önceki MA hesaplamaları (parametrelerden doğru modla)?


Klasik RSI'nın düzleştirilmiş ortalama temelinde oluşturulduğu açıktır. Ancak Simple MA ile en azından bir varyasyon vardır ve sonuçta yukarıdaki kodu kaldırmak mantıklı olur, bu da maMethod parametresinin davranışını çalışır hale getirir. Veya bu döngüden önceki MA hesaplamalarını kaldırarak ve tüm göstergelerdeki MA RSI parametrelerini silerek (çünkü zaten hiçbir şeyi etkilemezler!).


Bu kodu kaldırırdım (yukarıdaki) :). (Dönüştürülen göstergede, orijinal işlevselliğe ihtiyacı olan bu bölüm yorumlanmıştır - yorum etiketlerini kaldırın! RSI kodu inceleme için verilmiştir ... biz burada karar verene kadar, onu "kendi sorumluluğumda ve riskimde" kullanırdım :))


4. Daha önce de söylediğim gibi, lojik osilatörlerde başlangıç çubukları üzerinde hareket ederken kritik olmayan bir mantık hatası var. Şimdi düşüncelerimi bir araya getiremiyorum, yarın abonelikten çıkacağım (nerede ve nasıl düzelteceğim).


5. FSB'de şamandıra ile ne yapacağız ? (veya MT'deki eksikliği ile ) :)?


Arşiv, aradığınız dosyaları içerir, klasörlere ayrılmıştır, MT köküne açın (arşiv bir sonraki mesaja gidecektir)


Her şey, herkese iyi şanslar ... yazın :)
 

Mevcut gösterge arşivi (2009-04-15)

Dosyalar:
experts.rar  101 kb
 

Şamandıranın yenmediğini kabul ediyorum - bir çıkış yolu aramanız gerekiyor. Bir eşleşme yazmanız gerekiyor. Ardından bir gösterge kitaplığı oluşturun. Yardımcı olabilirsem, sevinirim.