MQL'de asenkron ve çok iş parçacıklı programlama - sayfa 16
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
Sana zaten yazdım, sinir ağı kurmaya çalışıyorsun, bu durumda uyumsuzluğa ihtiyacın yok mu?
Ancak basit aktivasyon fonksiyonları üzerine bir sinir ağı kuruyorsunuz, böylece paralellik eksikliği ile karşılaşmamış olursunuz.
Ancak kod, Ulusal Meclis'in küresel modellerini oluşturmaya başlayacak, o zaman uyumsuzluğun güzelliğini anlayacaksınız.
kötü örnek - gerekli değil!
@Roffild , " Modern dünyada, bir programcının belirli bir görev için doğru aracı seçebilmesi için birkaç dil bilmesi gerekir " konusunda zaten yazmıştı.
gerçek bu!
MQL'de MO (NS) için paket seçeneği yoktur - sadece AlgLib - Habré'de bulunan bir örneği düşünmek istiyorum, C# veya Python'u alıp MQL'ye bağlarım - bu kadar, yapmak istediğimi yapıyorum ve kodu MQL'ye taşımamak
Artık programlama dilleri yetenekleri için değil, hazır çerçeveler için ilginç! - MQL'de yeni MO paketleri varsa, başka görevler ve sorunlar da olacaktır!
Not: Bir kez daha parmaklarınızın ucunda, çapraz platform dillerinden Python ve Java'dan doğan "düzeltme fikrine" sarıldınız, dilin taşınabilirliği ve esnekliği için yapılan fedakarlık performansa verilen zarardı, şimdi bu diller performansı artırmak için çeşitli yollarla aşırı büyümüştür, ancak C benzeri dillerde geliştiriciler her zaman maksimum performansa ulaşır ve (çoğu durumda) görevi ayrı iş parçacıklarına bölmeye gerek yoktur (istemci-sunucu görevleri sayılmaz) , veri değişim hızında bir sorun var ve bu farklı bir özellik)
kötü örnek - gerekli değil!
@Roffild , " Modern dünyada, bir programcının belirli bir görev için doğru aracı seçebilmesi için birkaç dil bilmesi gerekir " konusunda zaten yazmıştı.
gerçek bu!
MQL'de MO (NS) için paket seçeneği yoktur - sadece AlgLib - Habré'de bulunan bir örneği düşünmek istiyorum, C# veya Python'u alıp MQL'ye bağlarım - bu kadar, yapmak istediğimi yapıyorum ve kodu MQL'ye taşımamak
Artık programlama dilleri yetenekleri için değil, hazır çerçeveler için ilginç! - MQL'de yeni MO paketleri varsa, başka görevler ve sorunlar da olacaktır!
Not: Bir kez daha parmaklarınızın ucunda, çapraz platform dillerinden Python ve Java'dan doğan "düzeltme fikrine" sarıldınız, dilin taşınabilirliği ve esnekliği için yapılan fedakarlık performansa verilen zarardı, şimdi bu diller performansı artırmak için çeşitli yollarla aşırı büyümüştür, ancak C benzeri dillerde geliştiriciler her zaman maksimum performansa ulaşır ve (çoğu durumda) görevi ayrı iş parçacıklarına bölmeye gerek yoktur (istemci-sunucu görevleri sayılmaz) , veri değişim hızında bir sorun var ve bu farklı bir özellik)
Aşağıdaki şeyleri sürekli görmezden geliyorsunuz:
1. Dış bağlantı kullanan programların dağıtımı Market üzerinden yapılamaz.
2. Harici bağlantılar kullanan programlar, her şeyi doğru bir şekilde bağlamak için kullanıcının "profesör" olmasını gerektirir. Böyle bir programı kullanma talimatı bir ayak örtüsüdür.
3. Dış bağlantılar kullanan programlar yalnızca kişisel kullanım için uygundur ve bu da yaratımlarının anlamını önemli ölçüde daraltır.
4. Kişisel kullanıma yönelik programlar, satışa yönelik programlardan daha düşük kalitededir, çünkü kendiniz için her istediğinizi yapabilirsiniz... ve AYNI ANDA BİRDEN ÇOK DİLDE AYNI UZMAN OLMAK MÜMKÜN DEĞİLDİR. Beşinciden onuncuya kadar bazı dilleri bileceksiniz ve bu ürünün kalitesini etkileyecektir.
5. Eşzamansız ve çoklu kullanım gerektiren birçok görev vardır. MQL programları henüz bu görevler için gelişmemiştir, ancak bu, onlar için çabalamamaları gerektiği anlamına gelmez.
...
Bir iş parçacığında eşzamansızlığa ulaşan şey.
Hayır, peki, çoklu iş parçacığı olmadan eşzamansızlık gerçekten bir tür oyundur, en az bir ek iş parçacığına ihtiyacınız vardır. EventLoop'unuzun yüklenebilir göstergeler aracılığıyla yapılabileceğini düşünüyorum. Örneğin, soketler aracılığıyla uzman göstergeler arasındaki iletişim. Bir görev belirdi, gösterge alındı, görev gönderildi, gösterge tamamlandığına dair rapor verildi, uzmandan görev durumu istendi, gösterge silindi. Koltuk değnekleri aracılığıyla, ancak yine de çok iş parçacıklı.
Evet, bu makale çok iyi, tek bir çözüm için, bu yaklaşımdan başka bir şeyi bükmeyi düşünün.
Benim durumumda, yön için Andrey sayesinde görevimin yönüne karar verdim.
Bir makaleyi okumanız zaten iyi.
İş parçacığı değil, EventLoop tarafından kontrol edilen geri arama işlevleri aracılığıyla aramaları engellemez.
Bir iş parçacığında eşzamansızlığa ulaşan şey.
Bunu belgelerde bulmamayı nasıl başardınız?
Belki okuyabilirsiniz?
Aşağıdaki şeyleri sürekli görmezden geliyorsunuz:
sizinle farklı görevlerimiz var, yazılım yazarken 2 büyük aşama olduğunu hesaba katmıyorsunuz: yazılım geliştirme ve uygulamanın kendisi.
Yazılım geliştirme hazır çözümler gerektirir - bu, geliştirme sırasında yazılımın görevlerini planlandığı gibi yerine getiremeyeceği ortaya çıkarsa - bu çöp. Ve uygulamanın kendisi zaten belirli bir platformun yetenekleri altında mekanik bir çalışmadır.
5. Eşzamansız ve çoklu kullanım gerektiren birçok görev vardır. MQL programları henüz bu görevler için olgunlaşmamıştır, ancak bu, onlar için çaba göstermemeleri gerektiği anlamına gelmez.
Tamam, şimdi seninle gidelim:
ticaret terminalinin neden buna ihtiyacı var sorusuna cevap verin.
Bir makaleyi okumanız zaten iyi.
Bunu belgelerde bulmamayı nasıl başardınız?
Belki okuyabilirsiniz?
Bulunmadığını hayal et.
Geri arama ve eventloop araması, belgelerde benzer bir şey bulamıyor.
Sakıncası yoksa, gereksiz alaycılık olmadan bir bağlantı verin.
1. Sizinle farklı görevlerimiz var, yazılım yazarken 2 büyük aşama olduğunu dikkate almıyorsunuz: yazılım geliştirme ve uygulamanın kendisi.
Yazılım geliştirme hazır çözümler gerektirir - bu, geliştirme sırasında yazılımın görevlerini planlandığı gibi yerine getiremeyeceği ortaya çıkarsa - bu çöp. Ve uygulamanın kendisi zaten belirli bir platformun yetenekleri altında mekanik bir çalışmadır.
Tamam, şimdi seninle gidelim:
2. Ticaret terminalinin buna neden ihtiyacı olduğu sorusunu yanıtlayın.
1. Tek yaptığım gelişmek. 6 yıllık sürekli gelişimde bunun ne olduğunu anlamamam pek olası değil. )) Diğer programların bağlamından koparılmış veya herhangi bir programdan soyutlanmış hazır yabancı çözümlerin son derece uzmanlaşmış bir kodun yapısına iyi entegre olmadığını ve korkunç bir salata sosu olabileceğini düşünüyorum, ancak sırayla işe yaramaması için denemeniz gerekir. Aynı zamanda, işçilik maliyetleri kendi çözümünüzü geliştirmekten daha yüksektir ve kodun nihai kalitesi daha düşüktür. Geliştirme potansiyelinden bahsetmiyorum bile. Bu gelişme gerçeğidir. Ancak bunun bizim sorumuzla ilgisi yok. Genel olarak, burası neresi?
2. Yanlış soruyu soruyorsunuz. Asıl soru, "Son kullanıcının buna neden ihtiyacı var?". Daha sonra, kullanıcıya her zaman birkaç fırsat sunulur. Bu nedenle, ilgisini kaybetmemesi için eklenmeleri gerekir. Olasılıklar tükenirse ve teknik sınırlamalar nedeniyle yenileri eklenmezse, kullanıcı ayrılır. Kullanıcıları terminalde tutmak için yeteneklere ihtiyaç vardır ve bunun için programların dağıtımına ihtiyaç vardır. Bu nedenle dağıtılamayan yazılımlar, hangi dilleri kullanırlarsa kullansınlar topluluk için anlamsızdır.
Aslında sadece kendi ihtiyaçlarınıza bakarsınız ve diğer kullanıcıların ihtiyaçlarını dikkate almazsınız. Bu toplulukta iş yapmıyorsunuz ve yapmak istemiyorsunuz ve sadece piyasada para kazanma motivasyonunu yayınlıyorsunuz. Ve piyasada hiç program olmadan kazanabilirsiniz.
kötü örnek - gerekli değil!
@Roffild , " Modern dünyada, bir programcının belirli bir görev için doğru aracı seçebilmesi için birkaç dil bilmesi gerekir " konusunda zaten yazmıştı.
gerçek bu!
MQL'de MO (NS) için paket seçeneği yoktur - sadece AlgLib - Habré'de bulunan bir örneği düşünmek istiyorum, C# veya Python'u alıp MQL'ye bağlarım - bu kadar, yapmak istediğimi yapıyorum ve kodu MQL'ye taşımamak
Artık programlama dilleri yetenekleri için değil, hazır çerçeveler için ilginç! - MQL'de yeni MO paketleri varsa, başka görevler ve sorunlar da olacaktır!
Not: Bir kez daha parmaklarınızın ucunda, çapraz platform dillerinden Python ve Java'dan doğan "düzeltme fikrine" sarıldınız, dilin taşınabilirliği ve esnekliği için yapılan fedakarlık performansa verilen zarardı, şimdi bu diller performansı artırmak için çeşitli yollarla aşırı büyümüştür, ancak C benzeri dillerde geliştiriciler her zaman maksimum performansa ulaşır ve (çoğu durumda) görevi ayrı iş parçacıklarına bölmeye gerek yoktur (istemci-sunucu görevleri sayılmaz) , veri değişim hızında bir sorun var ve bu farklı bir özellik)
Igor, bazen kendinle çelişiyorsun.
En son mql hesaplama hızının C++ hızıyla karşılaştırılabilir olduğunu yazdığınızda
Tamam, bu doğru ve birçok insan bunu biliyor.
Ama sonra, yavaş dillere koyduğunuzda, hesaplamaları aktarmak için üçüncü taraf çerçeveleri bağlamanın bir örneğini veriyorsunuz.
Ve paketlerin üçüncü taraf bağlantısı için kampanya yürütüyorsunuz. Yani, hazır bir çerçeve uğruna hızı feda mı ediyorsunuz?
Ve böylece, Peter'ın yazdığı gibi, programınızın taşınabilirliğini sıkı bir şekilde kaybedersiniz.
Buz solüsyonu değil. Kişisel kullanım için evet, toplu çözümler için hayır.
Bulunmadığını hayal et.
Geri arama ve eventloop araması, belgelerde benzer bir şey bulamıyor.
Sakıncası yoksa, gereksiz alaycılık olmadan bir bağlantı verin.
Arama yapmak değil, her şeyi okumak gerekiyor. Orada sizin için birçok sürpriz olduğuna eminim.
Bağlantılar olmayacak.
Kendileri bir şeyler yapmaya çalışanlara bile burada bir kereden fazla yardım ettim.
Ne yaptın?
Sadece forumda dilini mi kaşıdın?
Pekala, sana bu konuda yardım edeceğim.