Sipariş numaralandırma döngüsünün organizasyonu - sayfa 2
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Fiyat hareket edeceğinden ve her yeni OnTick aramasında, listedeki ilk emirde yeni bir değişiklik şartı yerine getirilmiş olacaktır. Hele modifikasyon 5 saniye sürecekse ;)
Yine, alaka düzeyi sorunu var. Bir sipariş her zaman güncel olacaktır. Gerisi - mümkünse. Seçeneğiniz, tüm siparişlerin güncel olmamasıdır.
Böyle bir "omurga", birden fazla siparişle çalışan bir Uzman Danışmanın mantığını bozacaktır.
Bir düzene sahip sistemlere bir fayda sağlamayıp gerisini mahvediyorsa ne anlamı var?
Ne demek istediğini anlamak isterdim ama işe yaramıyor. "Bekleme süresi geçtiyse işlem ortamını güncelleyin" ilkesinde bir sorun görmüyorum.
Siparişlerle çalışmadan önce fiyata göre hacim ve/veya mesafeye göre sıralama yapmak doğru karardır. Ancak kodu forumdan kopyalayan herkesin onu uygulayacağı varsayılmamalıdır.
Bu anlamda, kodum daha güvenli.
Eh, yeni başlayanlar için yazılmadı. Bunu burada çok iyi tartışıyoruz - su olmadan.
Yine, alaka düzeyi sorunu var. Bir sipariş her zaman güncel olacaktır. Gerisi - mümkünse. Seçeneğiniz, tüm siparişlerin güncel olmamasıdır.
Güncel - ne kadar?
Ne demek istediğini anlamak isterdim ama işe yaramıyor. "Bekleme süresi geçtiyse işlem ortamını güncelleyin" ilkesinde bir sorun görmüyorum.
Algoritmanız listedeki ilk sıraya sabitlendi, hepsi bu.
Bazı durumlarda bu sisteme zarar verebilir (bunu pratikte yaşadım).
Güncel - ne kadar?
Benim versiyonumda, her iki SL de 1.2375'e veya en kötü durumda 1.2374'e değiştirilir. Sonuç: Her iki sipariş için +30 puan.
Örneğinizdeki her adımda, TS'nin herhangi bir ticaret emri olmadan emirlerinin nerede olması gerektiğini bilmesi gerekir. Onlar. Genel olarak TS, siparişlerin şu anda bulunduğu yere bağlanamaz. Sadece nerede durmaları gerektiğini hesaplamakla ve ticaret ortamını ticaret emirleri aracılığıyla saydıklarıyla senkronize etmekle ilgileniyor.
Örneğinizde, TS'nin sonucu, OnTick'in Yüksek bir fiyata gelip gelmediğine bağlıdır. Ve doğru araç tam da bundan önce olmalıdır. Böyle bir fiyat olduğunu görüyor (onTick ile birlikte atlanmış olsa bile), bu da SL'sinin buna göre yerleştirilmesi gerektiği anlamına geliyor. Ve senkronizasyon işini %100 yapacak.
Ve neden ikincisi duruyor deyip duruyorsun anlamıyorum. Senkronizasyon mantığı olmasa bile, yine de sürümünüzdekiyle aynı şekilde değiştirilecektir. OnTick, NewTick olayında değil, normal bir dahili işlev olarak çağrılır.
Örneğinizdeki her adımda, TS'nin herhangi bir ticaret emri olmadan emirlerinin nerede olması gerektiğini bilmesi gerekir. Onlar. Genel olarak TS, siparişlerin şu anda bulunduğu yere bağlanamaz. Sadece nerede durmaları gerektiğini hesaplamakla ve ticaret ortamını ticaret emirleri aracılığıyla saydıklarıyla senkronize etmekle ilgileniyor.
Öyle, biliyor. Ancak senkronizasyon için zamanı yoktur - bir değişiklik yapılırken fiyat daha da ileri gider ve yeni hesaplanan durum ona ilk emri tekrar değiştirmesini söyler. Ve böylece her zaman.
Örneğinizde, TS'nin sonucu, OnTick'in Yüksek bir fiyata gelip gelmediğine bağlıdır. Ve doğru araç tam da bundan önce olmalıdır. Böyle bir fiyat olduğunu görüyor (onTick ile birlikte atlanmış olsa bile), bu da SL'sinin buna göre yerleştirilmesi gerektiği anlamına geliyor. Ve senkronizasyon işini %100 yapacak.
Bağımlı değil (örnekte SL seviyesi hesaplaması yoktu).
Ve senkronizasyon işi yapmayacak çünkü. zamanı olmayacak (yukarıya bakın).
Ve neden ikincisi duruyor deyip duruyorsun anlamıyorum. Senkronizasyon mantığı olmasa bile, yine de sürümünüzdekiyle aynı şekilde değiştirilecektir. OnTick, NewTick olayında değil, normal bir dahili işlev olarak çağrılır.
Her zamanki gibi, anladım.
Ancak modifikasyon devam ederken, fiyat zaten değişmişti ve OnTick'in zorunlu çağrısı zaten yeni fiyatla çalışıyordu, ikinci sipariş ise başlangıç seviyesinde kaldı.
Hata yok. Belki sizin için çok spesifik (ama tekrar ediyorum, hayattan oldukça gerçek) durum.
Öyle, biliyor. Ancak senkronizasyon için zamanı yoktur - bir değişiklik yapılırken fiyat daha da ileri gider ve yeni hesaplanan durum ona ilk emri tekrar değiştirmesini söyler. Ve böylece her zaman.
Verdiğiniz örnek sadece bir ektir. böyle bir mantık altında bir kayıp getirmez. Şimdi benimle bir örnek.
Diyelim ki, istenen geri çekilmeyi açmak için BuyLimits'i yukarı hareketin arkasında izliyoruz. Neredeyse Şanslı-TC. Her seferinde bir sınır dağını sürüklersek, çizginizde bir geri çekilme yakalayamayız.
Eski bir ticaret ortamına dayalı ticaret emirleri vermek garip. Ama inatla (benim gibi) farklı bir bakış açısını savunuyorsun.
Eski bir ticaret ortamına dayalı ticaret emirleri vermek garip. Ama inatla (benim gibi) farklı bir bakış açısını savunuyorsun.
İki kötülükten daha azını seçmelisiniz.
Fiyatı takip eden bir limite sahip bir örnek, elbette, "1 Uzman Danışman = her yönde 1 sipariş" seçeneğinde uygulamak daha iyidir.
Ama genel olarak tüm siparişlerinizi kontrol altında tutmanız daha doğru olur.
Ama genel olarak tüm siparişlerinizi kontrol altında tutmanız daha doğru olur.
Onlar. TS'nin yalnızca mevcut ticaret ortamıyla çalışması gerekliliğini kabul etmiyorsunuz.
Onlar. TS'nin yalnızca mevcut ticaret ortamıyla çalışması gerekliliğini kabul etmiyorsunuz.
Bunun için TS'nin tüm emirleri üzerindeki kontrolü feda etmeniz gerekiyorsa - kesinlikle.
Düşünün: 4 kamyonluk bir filonuz var. Her biri A noktasından B noktasına değerli bir kargo taşıyor. Rotayı kontrol etmeniz gerekiyor.
Hangisini tercih edersiniz: her dakika - bir tanesiyle mi yoksa her 2 dakikada bir - hepsiyle bağlantı kurmayı mı?
İkinci durumda, gecikme biraz daha uzun olacaktır ve onları yönlendirmek için zamanınız yoksa dördünün de küçük bir sapma yapması gerekebilir. Ancak genel olarak, iş için bir kamyon alıp üç kamyonu kaybetmekten daha karlı olacaktır.
Bunun için TS'nin tüm emirleri üzerindeki kontrolü feda etmeniz gerekiyorsa - kesinlikle.
Düşünün: 4 kamyonluk bir filonuz var. Her biri A noktasından B noktasına değerli bir kargo taşıyor. Rotayı kontrol etmeniz gerekiyor.
Hangisini tercih edersiniz: her dakika - bir tanesiyle mi yoksa her 2 dakikada bir - hepsiyle bağlantı kurmayı mı?
İkinci durumda, gecikme biraz daha uzun olacaktır ve onları yönlendirmek için zamanınız yoksa dördünün de küçük bir sapma yapması gerekebilir. Ancak genel olarak, iş için bir kamyonu alıp diğer üçünü kaybetmekten daha karlı olacaktır.
+1.
Siparişler arasında yinelenen bir döngünün analoğu, doğrudan OrderModify'ı çağırmak yerine bir değişiklik komutu oluşturan (tüm parametreleri) ve daha sonra işlenecek olan bir kuyruğa yerleştirir. Buradaki nokta, sorumluluğu (yukarıdaki kodda tek bir döngüye doldurulmuş) çevre analizinin belirli bir nesnesi ile analize dayalı eylemleri gerçekleştirme nesnesi arasında bölmektir.
Belki de bu fikir, siparişler üzerinde yinelenen döngünün analogu, doğrudan OrderModify'ı çağırmak yerine bir değişiklik komutu (tüm parametrelerle) üreten bir yönetici gibi bazı varlıklarda gizlendiğinde, OOP yaklaşımında ortaya çıkmayacaktı. onu bir kuyruğa yerleştirir ve daha sonra işlenir. Mesele, sorumluluğu (yukarıdaki kodda tek bir döngüye doldurulmuş) çevre analizinin belirli bir nesnesi ile analize dayalı eylemleri gerçekleştirme nesnesi arasında bölmektir.
Böyle bir durumdan kaçınmak ancak asenkron siparişlerin yardımıyla mümkün olacaktır.
Aksi takdirde, yürütülecek komutlar listesinde hala bir döngü olacaktır ve bu aslında siparişler arasında bir döngüdür.
Sadece sıra durumunda, siparişle ilgili eski yerine getirilmeyen emrin daha yenileriyle değiştirilmesini sağlamak yine de gerekli olacaktır. Aksi takdirde, kuyruk taşabilir ve kuyruktan gelen siparişler güncelliğini yitirebilir.