Hatalar, hatalar, sorular - sayfa 2450

[Stanislav Korotky]

Alexey Navoykov :

Oh teşekkürler, bundan haberim bile yoktu. Doğru, orada var ve makrolar hakkında tökezlemek hakkında söyleniyor. Ancak mutlaka kontrol edeceğiz.

Bu projeyi geliştirmeye devam ediyor musunuz? Bu nedenle potansiyel gerçekten çok büyük, özellikle de dili kendi başına iyileştirme açısından, çünkü MQL'deki pek çok şey uygulanmadı ve çoğu, bir güdük güvertesi (hatalar) ve anladığım kadarıyla geliştiriciler aracılığıyla çalışıyor. , artık dilin kendisinde herhangi bir şeyi geliştirmeyi planlamıyor.

Makroları işlemek için ek uygulamanız gerekir. tüm zincirin başlangıcına daha yakın bir yerde bir katman - makroların dilbilgisini tanımlamak, bunları kaynak kodunda ayrıştırmak ve yorumlamak (her makro için sonuç kaynağını / değerini alın). Karmaşıktır ve uygulama yalnızca bazı MQL programcıları için gereklidir, dolayısıyla geliştirme yoktur.

Ürünlerdeki değişiklikleri tanımlamak için bir karma kullanmaya gelince, bana öyle geliyor ki bu bir seçenek değil (veya hangi kullanım durumundan bahsettiğimiz hakkında hiçbir fikrim yok). Bir tür eski dosya oluşturduktan sonra, içinde yerleşik olan belirli modülün ve kaynak kodunun hangi sürümünün olduğunu anlamak genellikle bir veya iki yıl alır. Bunu yapmak için, görünüşe göre, derleme sürecini sürüm kontrol sistemleriyle bağlamanız gerekiyor. Hash'ler yeterli değil.

[Alexey Viktorov]

Igor Zakharov :

İstem, OnTradeTransaction() tarafından. Aşağıdaki normal davranış mı? Test cihazında kontrol ettim - bu doğru :( Ve "canlı" bir hesapta?

OnTick(), konumları sırayla kapatan bir döngüye sahiptir.

OnTradeTrancaction()'da açık pozisyonların sayısını saymak.

EA şunları yapar: önce kapanış döngüsünü sonuna kadar yürütür, ardından OnTradeTransaction'a geçer ve aynı sırayla hesaplamaları gerçekleştirir.

Başka bir deyişle, yapma

a

onlar. paralel değil seri olarak çalışır.

Yukarıdakiler normalse, OnTradeTransaction()'ın yalnızca bir siparişi açan/kapatan Uzman Danışmanlarda güvenle kullanılabileceği ortaya çıktı. Izgara ya çok simgeliyse (veya bulunduğu yerde çok simgeli ızgara :)) - algoritma bozulur.

Belgelerden alıntı

Terminalden manuel olarak veya OrderSend()/OrderSendAsync() ticaret işlevleri aracılığıyla gönderilen bir ticaret talebi, ticaret sunucusunda birkaç ardışık ticaret işlemi oluşturabilir. Aynı zamanda bu işlemlerin terminale ulaşma sırası garanti edilmez , bu nedenle ticaret algoritmanızı diğerlerinin gelmesinden sonra bazı ticaret işlemlerinin alınması beklentisi üzerine kuramazsınız .

Bu nedenle, her şey sayılacak, ancak beklendiği sırada değil.

OnTradeTrancaction() içindeki pozisyon sayısını neden saymaya karar verdiğinizi açıklayabilir misiniz? Hesaplama uygun şekilde düzenlenmezse, gereksiz işlemlerin olacağı seçeneği göz ardı edilmez. Sonuçta, bir döngüde birkaç pozisyonu kapatırsanız, her pozisyonu kapattıktan sonra tüm pozisyonları yeniden hesaplamanıza gerek yoktur. Döngü bittikten sonra bir kez saymak yeterlidir. Veya OnTradeTrancaction() içinde, IN tipi ile miktar 1 artacak ve OUT tipi ile azalacak şekilde düzenleyin. Ve bu durumda bile, pozisyon tamamen kapanmamışsa, bu dikkate alınmalıdır.

[Igor Zakharov]

Alexey Viktorov :

OnTradeTrancaction() içindeki pozisyon sayısını neden saymaya karar verdiğinizi açıklayabilir misiniz?

Her onay işaretine güveniyorsanız, kaynak yoğundur, özellikle strateji test cihazında fark edilir. Sadece Ticaret etkinliğinde yeniden hesaplamak daha doğru değil mi, yani. Açık pozisyonlar listesinde gerçekten bir şey ne zaman değişir? OnTradeTransaction(), Expert Advisor'ın çalışmasında kullanıcı müdahalesi üzerindeki kontrolü basitleştirir. (örnekler var :)

Bu robotta, şemaya göre ızgaraları kapatma olasılığını test ettim: kârsız + kârlı> X, ardından her ikisini de kapatın (genellikle farklı sembollerde). Ancak başarısızlık elde edilir, çünkü. kapalı olmalarına rağmen, test cihazı bunu bilmiyor ve bir sonraki yinelemeye geçiyor, mevcut olanları zaten kapalı olanlarla hatalı bir şekilde "eşleştiriyor". Onlar. Her kapanıştan sonra bir yeniden hesaplama eklemek zorunda kaldım.

Sayaç sıfırlamalı bir yeniden hesaplamam var ve ilk önce +1 / -1 değil, tüm açık olanlar için

Alexey Viktorov :

Belgelerden alıntı

Katılıyorum, en başından OnTradeTransaction() kullanmak riskliydi.Genel olarak, isteklerin eşzamansız olmadığı durumlarda - sadece ondan kaynaklanan sorunlar olduğunda muhtemelen reddedeceğim.

[Igor Zakharov]

fxsaber :

Çok karakterli bir ızgara için eşzamansızlık iyidir. Bu yüzden ikinci seçeneği seçerdim.

Ben zaten bu yönde düşünüyorum ;)

[Vladimir Karputov]

Igor Zakharov :

***

Bu robotta, şemaya göre ızgaraları kapatma olasılığını test ettim: kârsız + kârlı> X, ardından her ikisini de kapatın (genellikle farklı sembollerde).

***

Tam olarak bu iki pozisyonu kapatmanız gerektiğini biliyorsanız, o zaman bu pozisyonların biletlerini hatırlamak ve siz onları kapatana kadar kapatmak daha iyidir (DİKKAT: hiçbir süre ve Uyku - kapatmak için emirler verdi, OnTick'ten çıktı, kontrol edildi - orada hala bu biletlerle pozisyonlar - eğer öyleyse, tekrar kapatmaya çalışırız ve OnTick'ten çıkarız.)

[Igor Zakharov]

Vladimir Karputov :

Tam olarak bu iki pozisyonu kapatmanız gerektiğini biliyorsanız, o zaman bu pozisyonların biletlerini hatırlamak ve siz onları kapatana kadar kapatmak daha iyidir (DİKKAT: hiçbir süre ve Uyku - kapatmak için emirler verdi, OnTick'ten çıktı, kontrol edildi - orada hala bu biletlerle pozisyonlar - eğer öyleyse, tekrar kapatmaya çalışırız ve OnTick'ten çıkarız.)

Değerli fikir. Belki öyledir?: OnTick(), biletlerle bir dizi oluşturur ve onu bir kez kapatmaya çalışır ve OnTimer(), daha fazla olup olmadığını kontrol eder ve varsa kapatır.

Keneler arasında birkaç dakika olabilir, bu nedenle görevi zamanlayıcıya aktaracağız.

[Vladimir Karputov]

Igor Zakharov :

Değerli fikir. Belki öyledir?: OnTick(), biletlerle bir dizi oluşturur ve onu bir kez kapatmaya çalışır ve OnTimer(), daha fazla olup olmadığını kontrol eder ve varsa kapatır.

Keneler arasında birkaç dakika olabilir, bu nedenle görevi zamanlayıcıya aktaracağız.

Pozisyon kapatma görevi için TÜM, Uyku ve OnTimer'ı hendek yapardım. Bunu yapardım: kapatmak için ateş emri - OnTick'ten çıkın, bir sonraki onay kontrolünde: gerekli biletlerin bulunduğu pozisyonlar hala hayattaysa - onTick'teki giriş / çıkış boyunca bir daire içinde tekrar kapatmak için ateş emirleri vb.

Mantık şu şekildedir: bir pozisyonu kapatmak en önemli önceliktir, bu nedenle kapanış döngüsü OnTick'in en başındadır. Ve bir dizi kapanış biletinin oluşumu OnTick'in herhangi bir yerinde olabilir - en azından en sonunda.

İgor Zaharov :

***

Keneler arasında birkaç dakika olabilir, bu nedenle görevi zamanlayıcıya aktaracağız.

Yani yapacak bir şey yok - sadece yeni bir onay işareti bekleyin.

[fxsaber]

Igor Zakharov :

OnTick(), biletlerle bir dizi oluşturur ve onu bir kez kapatmaya çalışır, OnTimer() ise daha fazla bilet olup olmadığını kontrol eder ve varsa onları kapatır.

Başka bir seçenek (gerçek - bu kadar), sanal bir ortamda bir danışman başlatmak (ideal bir uygulama var) ve gerçek hayatta sadece sanal olanla senkronizasyon.

[fxsaber]

Vladimir Karputov :

Yani yapacak bir şey yok - sadece yeni bir onay işareti bekleyin.

Örneğin, ağda bir arıza varsa, bir sonraki onay işaretini beklemek kapanma fırsatını kaçırır.

[Vladimir Karputov]

fxsaber :

Örneğin, ağda bir arıza varsa, bir sonraki onay işaretini beklemek kapanma fırsatını kaçırır.

Ağ hatası == bağlantı kesilmesini mi kastediyorsunuz? İnternet yok, bu da hiçbir şeyin kapatılamayacağı veya açılamayacağı anlamına geliyor - burada kaçırılan fırsat nedir?

Ve genel olarak, ticaret sistemi her hapşırmaya karşı çok hassassa (orada bir boşluk veya başka bir şey), o zaman böyle bir ticaret sistemi fırındadır.