Elliot Dalga Teorisine dayalı uzman - sayfa 12

 
Yurixx :
tamsayı :
Yurixx :


Normalleştirilmiş bir osilatör üzerine kurulu basit bir TS hayal edin. Maksimumda - satıyoruz, minimumda - satın alıyoruz. Bu nedenle, başarılı bir şekilde ticaret yapmak için sadece ekstremumu zamanında belirlemek yeterlidir. Basit, değil mi? Ve kesinlikle yeterli. Bu görevi hızlıca (çok hızlı değil) yapabilir misiniz? Ya da en azından sadece yap?


Bunu çok, çok hızlı yapabilirim.


İyi ! Ardından RSI(14,Close) göstergesini EURUSD, M1 üzerine atın ve gecikmeden RSI ekstremumlarını belirleme problemini çözün.

Bitişik uçlar arasındaki RSI değişiminin genliği en az 25 olmalıdır.


Sorunu doğru ve eksiksiz olarak belirtin. Teorik olarak çözülebiliyorsa, pratik olarak da çözülebilir. Sorunun doğru ayarlanmasından sonra hepsi çözülür (ve siz kendiniz yapabilirsiniz). Bu problemde, bir ekstremum belirleme kriteri, değerin 25 birim geri alınmasıdır, yani böyle bir kriter ile gecikmeden ve teorik olarak tanımlanmamıştır. Kritere karar verirseniz - solda 25'ten fazla ve 5'ten fazla, ancak sağda 10'dan az, gecikme daha az olacaktır, ancak daha fazla yanlış sinyal olacaktır.

 
//+------------------------------------------------------------------+
//|                                                     toYurixx.mq4 |
//|                                                                * |
//|                                                                * |
//+------------------------------------------------------------------+
#property copyright "*"
#property link      "*"
 
#property indicator_separate_window
#property indicator_maximum 100
#property indicator_minimum 0
#property indicator_buffers 3
#property indicator_color1 Yellow
#property indicator_color2 DeepSkyBlue
#property indicator_color3 Red
//---- input parameters
extern int       RightMore=5;
extern int       RightLess=10;
extern int       LeftMore=25;
 
 
//---- buffers
double rsi[];
double u[];
double l[];
 
 
//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int init()
  {
//---- indicators
   SetIndexStyle(0,DRAW_LINE);
   SetIndexBuffer(0,rsi);
   SetIndexStyle(1,DRAW_ARROW);
   SetIndexArrow(1,159);
   SetIndexBuffer(1,u);
   SetIndexEmptyValue(1,0.0);
   SetIndexStyle(2,DRAW_ARROW);
   SetIndexArrow(2,159);
   SetIndexBuffer(2,l);
   SetIndexEmptyValue(2,0.0);
 
//----
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator deinitialization function                       |
//+------------------------------------------------------------------+
int deinit()
  {
//----
   
//----
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int start()
  {
   int    limit=Bars-IndicatorCounted();
      for(int i=0;i<limit;i++){
         rsi[i]=iRSI(NULL,0,14,0,i);
      }
      ArrayInitialize(u,EMPTY_VALUE);
      ArrayInitialize(l,EMPTY_VALUE);      
      for(i=Bars-1;i>=0;i--){
         double max=rsi[i];
         int maxb;
         for(int j=i;j<Bars;j++){
               if(rsi[j]>max){
                  max=rsi[j];
                  maxb=j;
               }
               if(max-rsi[i]>RightLess){
                  break;//не состоялся
               }
               if(max-rsi[j]>LeftMore){
                     if(max-rsi[i]>RightMore){//нашли
                        u[maxb]=rsi[maxb];
                     }
                  break;
               }
         }
         
         max=rsi[i];
         for(j=i;j<Bars;j++){
               if(rsi[j]<max){
                  max=rsi[j];
                  maxb=j;
               }
               if(rsi[i]-max>RightLess){
                  break;//не состоялся
               }
               if(rsi[j]-max>LeftMore){
                     if(rsi[i]-max>RightMore){//нашли
                        l[maxb]=rsi[maxb];
                     }
                  break;
               }
         }         
         
      }
      
//----
   
//----
   return(0);
  }
//+------------------------------------------------------------------+
 

Toplam 23.06.2007 01:45 - 23.06.2007 01:08 = Bu sorunu çözmek 37 dakika sürdü ama bu süre içinde kahve de içtim. Ayrıca ekstremumun solundaki ve sağındaki çubukların sayısına göre bir kriter getirmek gerekli olacaktır.

 
Integer :
Yurixx :


İyi ! Ardından RSI(14,Close) göstergesini EURUSD, M1 üzerine atın ve gecikmeden RSI ekstremumlarını belirleme problemini çözün.

Komşu ekstremumlar arasındaki RSI değişiminin genliği en az 25 olmalıdır.


Sorunu doğru ve eksiksiz olarak belirtin. Teorik olarak çözülebiliyorsa, pratik olarak da çözülebilir. Sorunun doğru formülasyonundan sonra hepsi çözülür (ve siz kendiniz yapabilirsiniz). Bu problemde, bir ekstremum belirleme kriteri, değerin 25 birim geri alınmasıdır, yani böyle bir kriter ile gecikmeden ve teorik olarak tanımlanmamıştır. Kritere karar verirseniz - solda 25'ten fazla ve 5'ten fazla, ancak sağda 10'dan az, gecikme daha az olacaktır, ancak daha fazla yanlış sinyal olacaktır.


Elbette, kod için teşekkürler, ancak bu, sizin de anladığınız gibi, bir çözüm değil, o görev değil.

Kendimi çok kısa ifade etmiş olabilirim ama bu aslında oldukça doğru bir ifade. Daha uzun olabilir. Tarihte değil, gerçek zamanlı olarak çalışan bir yerel ekstremumu belirleme prosedürü gereklidir. Tanımlama, çubuğun tamamlanmasından sonra, gösterge tablosunun karşılık gelen noktasının yerel bir uç nokta olup olmadığının belirlenmesi anlamına gelir. Yerel ekstremum, hem sağda hem de solda gösterge değerinde en az 25.0 değişiklik gösteren bir ekstremumdur.

Çubuğun tamamlanması sırasında, varsayılan uç noktanın sağındaki göstergenin gelecekteki değişikliği bilinmediğinden, göstergenin davranışının optimal tahmininden bahsediyoruz. Bu tahmin bir ekstrapolasyon değildir, çünkü uç noktanın sağındaki gösterge değerleri ilgi çekici değildir. Tek koşul, ekstremum koşuldur, yani. gösterge değerlerinin öngörülen miktarda değişeceğini. Tahminin optimalliği istatistiksel anlamda anlaşılır, yani tahminin yeterince yüksek bir güvenilirliğe sahip olması gerekir.

Resmi olarak her şey farklı görünüyor ama sizin için yeni bir şey söylemedim. Bütün bunlar zaten üç kelimeyle "gecikmeden tanımlama".

Yapılandırılmış bir geçmiş üzerinde belirtilen özelliklere sahip ekstremumları aramak için temel bir komut dosyasının hem daha özlü hem de basit bir şekilde yazılabileceği gerçeğine dikkatinizi çekmek istiyorum. İç içe döngüler pahalıdır, büyük dizilerde çok yavaşlar. Bütün bunlar tek geçişte yapılabilir, yani. her yeni çubukta , herhangi bir döngü olmaksızın yalnızca bir yeni değer hesaplayın. Ve komut dosyanızı bir gösterge olarak tasarladığınız için, her yeni çubukta, önceki tüm geçmiş boyunca bir döngü içinde bir döngü sayacaksınız - tahmini sürede Çubuklar*Çubuklar/2 kat artış. Ve zaten bir döngü içinde bir döngü kullanıyorsanız, o zaman döngüye j üzerinden j=i değerinden başlamak mantıklı değildir.

Kodunuzu ayrıntılı olarak ele almadım ve bir grafikte bakmadım, ancak bana öyle geliyor ki önemli bir hata içeriyor - kendi sonucunu değiştiriyor. Örneğin, bazı i'ler için bu nokta bir ekstremum noktasıysa, (i + 1) veya daha ilerisine giderken böyle olmaktan çıkabilir. Ancak bu, koyduğunuz koşulun sonucudur: 5'ten fazla, 10'dan az.

Hikayenin çoğu için önemli değil. Ancak sağ kenar için de önemli bir şey var. Komut dosyanızın sıfır çubuğunun solunda tanımladığı uç nokta, bir sonraki çubukta kaybolabilir. Ve bu iyi değil. :-))

 
Yurixx :


1. Elbette, kod için teşekkürler, ancak sizin de anladığınız gibi, bu bir çözüm değil, o görev değil.

Kendimi çok kısa ifade etmiş olabilirim ama bu aslında oldukça doğru bir ifade. Daha uzun olabilir. Tarihte değil, gerçek zamanlı olarak çalışan bir yerel ekstremumu belirleme prosedürü gereklidir. Tanımlama, çubuğun tamamlanmasından sonra, gösterge tablosunun karşılık gelen noktasının yerel bir uç nokta olup olmadığının belirlenmesi anlamına gelir . Yerel ekstremum, hem sağda hem de solda gösterge değerinde en az 25.0 değişiklik gösteren bir ekstremumdur.

Çubuğun tamamlanması sırasında, varsayılan uç noktanın sağındaki göstergenin gelecekteki değişikliği bilinmediğinden, göstergenin davranışının optimal tahmininden bahsediyoruz. Bu tahmin bir ekstrapolasyon değildir, çünkü uç noktanın sağındaki gösterge değerleri ilgi çekici değildir. Tek koşul, ekstremum koşuldur, yani. gösterge değerlerinin öngörülen miktarda değişeceğini. Tahminin optimalliği istatistiksel anlamda anlaşılır, yani tahminin yeterince yüksek bir güvenilirliğe sahip olması gerekir.

Resmi olarak her şey farklı görünüyor ama sizin için yeni bir şey söylemedim. Bütün bunlar zaten üç kelimeyle "gecikmeden tanımlama".

2. Değiştirilmiş bir geçmiş üzerinde belirtilen özelliklere sahip ekstremumları aramak için temel bir komut dosyasının hem daha özlü hem de basit bir şekilde yazılabileceği gerçeğine dikkatinizi çekmek isterim. İç içe döngüler pahalıdır, büyük dizilerde çok yavaşlar. Bütün bunlar tek geçişte yapılabilir, yani. her yeni çubukta, herhangi bir döngü olmaksızın yalnızca bir yeni değer hesaplayın. Ve komut dosyanızı bir gösterge olarak tasarladığınız için, her yeni çubukta, önceki tüm geçmiş boyunca bir döngü içinde bir döngü sayacaksınız - tahmini sürede Çubuklar*Çubuklar/2 kat artış. Ve zaten bir döngü içinde bir döngü kullanıyorsanız, o zaman döngüye j üzerinden j=i değerinden başlamak mantıklı değildir.

3. Kodunuzu ayrıntılı olarak ele almadım ve grafikte bakmadım, ancak bana öyle geliyor ki önemli bir hata içeriyor - kendi sonucunu değiştiriyor. Örneğin, bazı i için bu nokta bir ekstremum noktasıysa, o zaman (i + 1) veya daha ilerisine giderken böyle olmaktan çıkabilir. Ancak bu, koyduğunuz koşulun sonucudur: 5'ten fazla, 10'dan az.

Hikayenin çoğu için önemli değil. Ancak sağ kenar için de önemli bir şey var. Komut dosyanızın sıfır çubuğunun solunda tanımladığı uç nokta, bir sonraki çubukta kaybolabilir. Ve bu iyi değil. :-))

1. Görev, ekstremumları tanımlamaktı, görünümlerinin TAHMİNİ değil. Kısacası, ucuz bir gösteriş .... onlar tahmin edemezdi. ... Bu aynı şey, bana kaseyi ver ki hiç geyik olmasın ve %1000. Bu tam olarak hakkında yazdığım şeydi, görevin önce tek bir teorik çözümü olmalı, sonra kodda uygulanıyor. Ancak tahminin kesin bir çözümü yoktur.

Tanımlama, çubuğun tamamlanmasından sonra, gösterge tablosunun karşılık gelen noktasının yerel bir uç nokta olup olmadığını belirlemek anlamına gelir - Tanrı'nın armağanını sahanda yumurta ile karıştırmayın - tanımlama ve tahmin.

"gecikme olmadan tanımlama" - yine. Gecikme olmaksızın tanımlama, durumun benzersiz olarak tanımlandığı ilk anda tanımlama anlamına gelir.

2. Gösterin ve göreceğiz.

Bars*Bars/2 kez - açıkçası nasıl çalıştığını bile anlamıyorsunuz veya break ifadesinin anlamını bilmiyorsunuz;

o zaman döngüyü j=i değerinden j üzerinden başlatmanın bir anlamı yok - ama o zaman ne olacak? Bu sizin için en ilginç soru!

Kodunuzu ayrıntılı olarak ele almadım ve bir grafikte bakmadım, ancak bana öyle geliyor ki önemli bir hata içeriyor - kendi sonucunu değiştiriyor.

3. Lütfen okumalarını yalnızca sıfır, henüz oluşturulmamış çubuğa bağlı olarak değiştirdiğini unutmayın. Ayrıca tüm göstergeler, sıfır çubuğundaki değere göre son değerini değiştirir. Fraktal göstergesini hiç gördünüz mü (MT'de yerleşik (Ana menü - Göstergeler - Bill Williams - Fraktallar )) - bakın, bu çok ilginç ve heyecan verici ve belki bir gün sizin için yararlı olabilir. Göstergeleri programlarken sıfır çubuğundaki değişiklikleri hesaba katmak, göstergeleri yazan bir programcı için en azından bir görgü kuralıdır, hatta onları programlamak için sarsılmaz bir kuraldır. İlk çubuk, kural olarak, yetersiz deneyimle sınırlıdır ve göstergenin çalışma göstergesi yazarlarının özüne derinlemesine inmez.

Ve genel olarak, algoritmanın ideal olduğunu söylemedim, hızlanması için büyük bir rezerv var, göstergeyi yalnızca yeni bir çubuk için hesaplamak için bir sınırlama yapabilirsiniz. Ancak başlangıç için, görev yalnızca gösterge değerini belirli bir değere değiştirme kriteri ile ekstremumu belirlemekti ve kavramların ikamesiyle ucuz gösterişlerinizi hesaba katmazsanız çözüldü. tanımlama ve tahmin .

 
Integer :

...ucuz gösteriş ....


Nasıl istersen. :-)

tamsayı :

Bir kişi neye ihtiyacı olduğunu bildiğinde, çok hızlı bir şekilde yapılır.

Görünüşe göre, "bir kişi neye ihtiyacı olduğunu bilir" ve "tek bir teorik çözüm" kavramlarının yerini almıştır. Bu arada, kavramlarınız.

 
Güzel konu, buhar tükendiği için üzgünüm.
Profesyonel programcılar için DLL'yi Elliottician ürünlerinden almalarını tavsiye ederim. Kreasyonlarını VisualWasik'te yazarlar, ancak kütüphaneler, yüksek, yakın, vb. gibi olağan kavramları kullanan dalgaların ve kalıpların tanımlarını içerir. Özellikle RET'in en son sürümleri Forex için bir eklenti içerdiğinden. Ve son 15 yıldır dalga tabanlı bir DLL'yi demonte etmek çok cezbedici!
 
Bookkeeper :

soru: Stratejiyi gerçek hayatta olmayan riskli, agresif bir pipsota uyarlamak mümkün mü?

Ama sadece demo için mi? Soru bundan ibaret değil. Yüzsüz bir şekilde girişle veya tüm uyuşturucu ile mümkündür.

Mümkün olduğunu düşünüyorum, uygulamayı kontrol edin.

Depoyu bir haftada %900 arttırdım.

Samimi olarak,

Alex Niroba

Dosyalar:
statement.zip  9 kb
 
NYROBA >> :

Mümkün olduğunu düşünüyorum, uygulamayı kontrol edin.

Depoyu bir haftada %900 arttırdım.

Samimi olarak,

Alex Niroba

hmm ... uzun hikaye gerçi.

;)

 
divenetz >> :
Хорошая тема, жаль выдохлась.
Для профпрограммистов я бы порекомендовал поковырять DLL от продуктов Elliottician. Они пишут свои творения на ВижуалВасике, но в библиотеках есть описание волн и патернов обычными понятиями high, close и пр. Тем более что последние версии RET содержат плагин для Forex. А разобрать DLL с базой волн за последние 15 лет - очень заманчиво!

RET saçmalık. Modern75.nls dosyasını ElWave'den sökmek daha iyidir (özellikle dosya açık olduğu için). RET, banal winwaves32 ile hemen hemen aynıdır.

Neden: