Sipariş numaralandırma döngüsünün organizasyonu - sayfa 4

Yeni yorum
 
fxsaber :

O olmayacak çünkü. güçlü değil.


İlk olarak, ideal ticaret koşullarının bulunduğu testçi için TS yazılır. Her şey yolundaysa, savaş versiyonunu gerçek hayatta test cihazında gördüklerine mümkün olduğunca yakın olacak şekilde yazmaya çalışırlar. Bir TS yazmaya yönelik diğer yaklaşımlar, bir fikrin algoritmalaştırılması değil, belki de olabilir.

O halde temel soru şudur: Test cihazına en yakın savaş durumu hangisidir? Fikrimi dile getirdim (ve bir örnek verdim), seninkini duydum.

En doğru çeviri sorunuyla da karşılaştım.   testten bir uzmanın ticaret mantığı   gerçek bir hesapta çalışmak için strateji test cihazındaki (MT4) keneler üzerinde.

Akıl yürütmem:

Uzman test cihazında çalışır   sadece ideal ticaret koşullarında değil, aslında farklı bir modda - gerçek zamanlı olarak, yani.   tek bir tıklamayla, orada TS'yi hesaplamayı ve bir emir göndermeyi ve buna bir yanıt almayı başarır, ancak bir ticaret hesabında gerçek kullanımla, artık durum böyle değil. Şekline dönüştü   iki farklı robotumuz var   - biri gerçek zamanlı, diğeri değil. Gönder/değiştir   sipariş (bir tane bile!)   gerçek hesaba   = ping + yürütme süresi vb. = en iyi 100-500ms ve şu anda keneler var ve bunların sayılması gerekiyor - ve duruyoruz, bekliyoruz ... ve sonra rastgele bir sırayla akışa doğru şişiyoruz (fiyat bu süre boyunca göreceli olarak nereye gitti) kene ortalamalarımıza   x.z.   + Muhtemelen en hızlı ve genellikle en önemli kenelerden bazılarını kaçırdık).   Sonuç olarak, test cihazında geri aldığımız stratejimizden hiçbir şeyin kalmadığı ortaya çıktı.

Böylece, yansıma üzerine, aşağıdakileri buldum:

  1.   Savaş modunda, Expert Advisor'daki ticaret mantığı devre dışı bırakılır ve esasen bir fotokopi makinesi olarak çalışır.
  2. İşlem sistemi indikatöre aktarılarak açma ve kapama komutları üretir ve bu komutların Expert Advisor tarafından yürütülmesini beklemez, sadece yürütür.   içine gömülü araç ideal   koşullar, neredeyse bir test cihazında olduğu gibi. Bildiğim kadarıyla, teknik olarak mümkün olduğundan şüpheli olsam da gösterge keneleri atlamamalı - ama en azından başlangıçta bu özelliğe sahip olan ve belgelerde açıklanan Expert Advisor'dan daha az kene atlamalı. + Hesap hatalarını ayırarak bile TS daha az olmalıdır. TS'nin mantığına ikincil olan herhangi bir işlem için iş kesintisi yoktur.
 
zenz :

Böylece, yansıma üzerine, aşağıdakileri buldum:

  1.   Savaş modunda, Expert Advisor'daki ticaret mantığı devre dışı bırakılır ve esasen bir fotokopi makinesi olarak çalışır.
  2. İşlem sistemi indikatöre aktarılarak açma ve kapama komutları üretir ve bu komutların Expert Advisor tarafından yürütülmesini beklemez, sadece yürütür.   içine gömülü araç ideal   koşullar, neredeyse bir test cihazında olduğu gibi. Bildiğim kadarıyla, teknik olarak mümkün olduğundan şüpheli olsam da gösterge keneleri atlamamalı - ama en azından başlangıçta bu özelliğe sahip olan ve belgelerde açıklanan Expert Advisor'dan daha az kene atlamalı. + Hesap hatalarını ayırarak bile TS daha az olmalıdır. TS'nin mantığına ikincil olan herhangi bir işlem için iş kesintisi yoktur.

Evet, aynı yaklaşımı kullanıyorum - kendi açık siparişleri olan bir tür dahili ideal test cihazı ve bu sanal siparişleri gerçekleştirmeye çalışan bir fotokopi makinesi. Böyle bir şema, birçok ağır tuzağı kolaylıkla atlar.


MT5'te daha kolay çünkü. orada bir kene geçmişi talep edebilirsiniz. Ve birkaç enstrüman için.

 
Stanislav Korotky :

Bu zamanla ilgili değil, mantıkla ilgili (zamanla ilgili - bu başka bir başlıkta ;-)). Senin mantığın (ve benimki, çünkü araba benzetmesi de dahil olmak üzere her şeye katılıyorum), çevreyi "tek bir hamlede ve bütünüyle" analiz etmektir, parçalar halinde değil. Herhangi bir yan etkinin işlenmesi bir sonraki çağrıya kadar ertelenir, çünkü. bu etkiler yeni ticaret ortamına eklenecektir.

Zaman için bir düzeltme olmasaydı, o zaman her iki mantık (hem benim hem de fxsaber) aynı olurdu - tüm siparişler birkaç hatadan sonra bile her onay işaretinde işlenirdi.

Görev, tam olarak anlık olmayan uygulama ile gerçekliği, test sırasında elde edilen ideal modele yaklaştırmaktır.

 
fxsaber :

Evet, aynı yaklaşımı kullanıyorum - kendi açık siparişleri olan bir tür dahili ideal test cihazı ve bu sanal siparişleri gerçekleştirmeye çalışan bir fotokopi makinesi.

Yaklaşımınızı gerçekleştirirseniz (bir döngüde, gerçeklikle başarılı bir şekilde senkronize olana kadar ilk sırada kalırsanız), diğer siparişleri gözden kaçırma (veya daha sonra işleme koyma) ile aynı sorunla karşılaşabilirsiniz. Ama bu aynı, sözde tamamlanmış, konuyla ilgili)

 
Andrey Khatimlianskii :

Yaklaşımınızı gerçekleştirirseniz (bir döngüde, gerçeklikle başarılı bir şekilde senkronize olana kadar ilk sırada kalırsanız), diğer siparişleri gözden kaçırma (veya daha sonra işleme koyma) ile aynı sorunla karşılaşabilirsiniz. Ama bu aynı, sözde tamamlanmış, konuyla ilgili)

Ticaretimiz böyle!

 
fxsaber :

Bir OOP örneği bekliyorum. Ve bunu bir döngü şeklinde aynı omurga olarak görüyorum. İlk önce neyin değiştirilmesi gerektiğini belirleyeceği ve daha sonra verilmiş kararlara göre mantık değişmeyecek.

Özellikle bu görev için bir örnek yazmayacağım. Ancak yaklaşımın basitleştirilmiş bir konsepti blogumda görülebilir. Orada, kuyruk derinlemesine analiz edilmez, sadece boşluk olup olmadığı kontrol edilir. İsteyen geliştirebilir.

Mantıkla, "bir grup siparişi değişen fiyatlara uyacak şekilde değiştirme" görevinin tamamını kastediyorsak, o zaman sadece bir tane var. Soru, uygularken daha önemli olan şey: tüm siparişleri değiştirmek mi, yoksa en son fiyatları değiştirmek mi? Tercihlere bağlı olarak, buradaki mantık zaten farklı olacaktır. Basit bir döngü, tüm siparişlerin güncellenmesini sağlar ve ben bu seçeneği destekliyorum. Daha önce de belirtildiği gibi, OOP, görevin sorumluluk bloklarına bölünmesi konusunda görünürlük sağlar ve bu ayrıştırmaya dayalı olarak, "tüm siparişler", "fiyat uygunluğundan" daha önemlidir. Bu, fiyatların sürekli değiştiği ve sadece ara sıra siparişlerin olduğu düşünüldüğünde bile açıktır. Onlar daha önemli.

 
Stanislav Korotky :

OOP, görevin sorumluluk bloklarına bölünmesi konusunda görünürlük sağlar ve bu ayrıştırmaya dayalı olarak , "tüm siparişler", "fiyat uygunluğundan" daha önemlidir.

Bu ayrışmaya dayanarak, yalnızca bölme izler. Böyle bir OOP ile "fiyat uygunluğu", kuyrukta bir yer ayarlanarak elde edilir.
 
fxsaber :
Bu ayrışmaya dayanarak, yalnızca bölme izler. Böyle bir OOP ile "fiyat uygunluğu", kuyrukta bir yer ayarlanarak elde edilir.

Bu bir tür "felsefe" gitti. İşlem, alternatifte önerildiği gibi tik akışıyla değil, sırayla gerçekleştirilir. Genel olarak, bu tartışmadan elendim. Tüm argümanlar zaten verildi.

 
Stanislav Korotky :

Genel olarak, bu tartışmadan elendim. Tüm argümanlar zaten verildi.

Bu şekilde bitirmek zaten bir trend.

 
fxsaber :

Sadece MT4'ü değil, diğer platformlarla birlikte MT5'i de ilgilendiren aşağıdaki konuya değinilecektir. Ancak kolay algılanması için mantık MQL4'te yazılacaktır, yani bu başlıkta.

Çoğu zaman, siparişleri değiştirmenin / silmenin omurgası (herhangi bir et büyür) aşağıdaki mantığa gelir

Ve şimdi yaklaşım nadir, ama çok daha doğru

Bir ticaret talebi gönderdikten sonra, ticaret ortamı değişir, bu nedenle ticaret sunucusunun yanıtından hemen sonra TS'nin tüm ticaret mantığını sıfırdan yürütmeniz önerilir.

Döngü, en tehlikeli programlama tekniklerinden biridir. Analiz edilmesi neredeyse imkansız olan garip, nadiren tezahür eden hatalarla doludur.

Döngü yapmak yerine tam tersini yapmanız, kullanıcı iş parçacığını olabildiğince çabuk tamamlamaya çalışmanız gerekir. Gerçekten "nabzı tutmak" istiyorsanız - OnTradeTransaction'ı MT5'te analiz edin. MT4 genellikle bu tür tuhaflıklar için kötüdür, çünkü dedikleri gibi basitlik hırsızlıktan daha kötüdür.

1234567891011...15
Yeni yorum