yardıma ihtiyacım var! Görev çözülmedi, demirin sınırlamalarıyla karşılaşıyorum - sayfa 11
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
Yurchik, dosya işleme, sıkıştırma vb. Tamamen SQL ve robot/gösterge mantığıyla çalışır. Bir çok veritabanı ile çalıştım, tek sorun MQL ve SQL arkadaşlığı yapmaktı))), herhangi bir dizi ve yapı olmadan güzel bir çözüm yaptım.
Genelde, tekerleği yeniden icat etmeyi değil, problemleri optimal araçlar kullanarak çözmeyi tercih ederim.
Zhenya evet, seni anlıyorum ...
tercih ettiğim şey bu
... özellikle hazır profesyonel bir araç varsa ... güzelce entegre etmek daha iyidir
İşte tartışma! Herkese katıldığınız için teşekkürler!
Hep birlikte cevaplayacağım, hiçbir şeyi (ve kimseyi) kaçırmamaya çalışacağım.
1. Перейти на x64
Terminal sürümünü belirtmediğimi anlamam uzun sürmedi. Ben 4. ile çalışıyorum ve bu Uzman Danışmanı henüz 5.'ye devretmeyeceğim. MT4, ne yazık ki, yalnızca 32 bit .
32-bit Windows 8 / 8.1'de 4 GB bellek sınırlamasını kaldırıyoruz - bu yardımcı olmayacak, sistemim zaten x64.
2. Parçalara ayırın / parçalar halinde okuyun / küçük blokları yükleyin
Görevin şartlarına göre çalışmayacaktır.
Aşağıda daha fazla ayrıntı vermeye çalışacağım, belki bu sorunu daha iyi anlamamıza yardımcı olur.
3. Daha fazla bellek satın alın / güçlü bir sunucu veya bulut kiralayın / her şeyi bir SSD'ye taşıyın
Tabii ki boş slotlara 16 GB daha bellek koyacağım ama bu bir seçenek değil.
Bu hacim sınır değildir ve kapasitelerin genişletilmesi, sorunun yalnızca belirli bir durumunu çözecektir.
Buna yalnızca %100'ün algoritmik olarak sıkıştırıldığına dair bir güven olduğunda başvurulması gerektiğini düşünüyorum.
4. Verileri sıkıştır
Şimdi yaptığım şey bu.
Metin önbelleği (20 GB) 2 kat küçüldü ve muhtemelen biraz daha küçülecek.
Bu, bellekteki veri miktarıyla ilgili sorunu çözmez, ancak onu diğer bazı çözümlere (RAM diski) yaklaştırır.
Ayrıca ikili çeviri yapacağım, okumayı hızlandıracak ve sesi azaltacaktır.
http://www.nanex.net/historical.html adresindeki ustaların nasıl sıkıştırıldığı belli değil . Veri yapıları oldukça gereksizdir.
5. Kullanmadan önce verileri sıkıştırın/kodlayın ve istenen parçayı açın/kodunu çözün
Bir seçenek olarak kabul edildi.
Ama içimden bir ses bunun da uzun süreceğini söylüyor (burada işlemciyle karşılaşıyoruz).
6. Hesaplamayı harici bir programa aktarın (Matlab/R/etc)
İstemiyorum, birçok nedeni var.
MT ile iyi entegre edilmiş bir ortamda olmadığı sürece. Ancak programı / ortamı incelemek ve / veya üçüncü taraf bir geliştiriciden bir çözüm sipariş etmek yine de zaman alacaktır. Bu, geliştirme aşamasında uygunsuz ve maliyetlidir (ve bende var).
Genel olarak, tüm artıları ve eksileri ile sanal alanda kalmaya çalışırken.
Bunun nasıl yardımcı olabileceğini anlamıyorum.
Yine de ana dosyadan tekrar tekrar veri almanız gerekiyor (sürekli olarak yeniden okuyorsunuz).
8. DB'yi kullanın
Aşağıdakileri göz önünde bulundurarak çok cazip bir seçenek:
Ama dezavantajları da var:
- Benim için nispeten yeni bir ortam (sıkı çalışmadı, yalnızca temel sorgular);
- Tek bir istemci makinede kurulumun karmaşıklığı (bağımsız sürüm);
- başka bir şey olmalı..
Genel olarak, diğer seçenekler işe yaramazsa, büyük olasılıkla buna geri döneceğim.9. Yeni ve belirsiz terimleri anlayın ve test edin
Bu sadece gelecek için kendime bir not ve/veya yazarlardan ek bilgi talebidir ;)
Keşfedilmemiş: Dosya eşleme, karma tabanlı çözümler, B-ağaçları.
10. Tüm önbellekleri olan terminali sanal bir RAM diskine aktarın
Şimdiye kadar, bu (işçilik maliyetleri / sonuç açısından) en umut verici seçenek.
SoftPerfect'ten yüklü RAM Disk , önbelleği sıkıştırmayı bitirin, dosyanın sürekli okunması için kafiyeyi yeniden yazın ve performansı kontrol edin.
11. Görevi doğru ayarlayın =)
Özellikle arka plan bilgisinin azlığı göz önüne alındığında çok iyi bir tavsiye.
Söz verdiğim gibi, daha fazla ayrıntı vermeye çalışacağım.
Pek çok benzer işlem dizisi vardır, her bir dizi zamana göre sıralanmıştır.
Farklı dizilerdeki işlemler farklıdır, zaman içinde (ve her dizide kendi yolunda) eşit olmayan bir şekilde dağıtılır. İşlemler değişiklik gösterir. Ancak her şey Date1'den Date2'ye kadar olan aralıktadır.
Görev, D1'den D2'ye M dakikalık bir adımla (veya daha iyisi, özellikle tüm dizilerin işlem noktalarına göre) geçmek, K kriterine göre diğerlerinden daha iyi bir dizi bulmaktır (ayrı bir görev sadece en iyi diziyi bulmak için, ancak tüm seti kritere göre sıralamak ve ilk 10'u görüntülemek için - ancak bu isteğe bağlıdır, henüz gerekli değildir).
Kriter K, kendisine karşılık gelen dizinin önceki X işlemi temelinde hesaplanır, hesaplamalarda X işlemlerinin her biri hakkında neredeyse tüm bilgiler kullanılır (örneğin sadece kâr yeterli değildir).
Kriter (K), işlem sayısı (X) ve sonuçları etkileyen diğer parametreler kullanıcı tarafından değiştirilir. Onlar. algoritmaya "bağlı" olamaz.
Bunun gibi bir şey.
Teoride, dosyayı tüm dizilerdeki tüm işlemler için doğrusal olacak şekilde yeniden yapılandırabilirsiniz.
Ancak tüm bilgileri belleğe koymadan bunu nasıl yapabilirim? Ve eğer bir dizinin anlaşmaları tüm dosyaya "bulaşmışsa", Kriter nasıl yeniden hesaplanır?
Şimdi, umarım, görev açıktır.
Katılım, tartışma, sorular, bağlantılar ve özel cevaplar için bir kez daha derin şükranlarımı sunuyorum:
TheXpert , Urain , sergeev , elugovoy , anonim ,et , ALXIMIKS , IvanIvanov , Integer , C-4 , marketeer , barabashkakvn , Silent , GT788 , papaklass , grizzly_v , artemiusgreat , Candi YuraZ , Candi YuraZ , sunucu
Teşekkür ederim!
İşte tartışma! Herkese katıldığınız için teşekkürler!
....Aşağıdakileri göz önünde bulundurarak çok cazip bir seçenek:
Ama dezavantajları da var:
- Benim için nispeten yeni bir ortam (sıkı çalışmadı, yalnızca temel sorgular);
- Tek bir istemci makinede kurulumun karmaşıklığı (bağımsız sürüm);
- başka bir şey olmalı..
Genel olarak, diğer seçenekler işe yaramazsa, büyük olasılıkla buna geri döneceğim.SQL'e doğru gidersek
Bu, geliştirme aşamasında oldukça yavaş olabilir.
Bu seçeneği seçerseniz, tüm iş mantığını saklı yordamlarla oluşturmak daha iyidir.
sunucuya bir istek göndermek ve tamamen hazır bir sonuç almak için uzmana yalnızca iki işlev bırakarak
sunucudaki tüm hesaplamalar
Aslında, internette bir SQL sunucusunun nasıl kurulacağına dair birçok açıklama bulabilirsiniz.
( örneğin ORACL,SYBASE + CENTOS ) ORACL,SYBASE,MS SQL+WINDOWS ayrı makine
ORACL - öğrenmesi biraz daha zor - daha az uzman, daha az literatür
MS SQL - belki de web'deki en fazla bilgi ve daha fazla literatür
belirli bir zorluk olmayacak - internette mağazada çok fazla açıklama var daha fazla kitap var
MSSQL 2012, parametrelerinde ORACL'e yaklaştı - zaten 2014 var
SQL + LINUX paketinin seçimi genellikle endüstriyel operasyonda seçilir - ve LINUX bilgisi yoksa, WINDOWS almak daha iyidir
komposter :
Pek çok benzer işlem dizisi vardır, her bir dizi zamana göre sıralanır.
Farklı dizilerdeki işlemler farklıdır, zaman içinde (ve her dizide kendi yolunda) eşit olmayan bir şekilde dağıtılır. İşlemler değişiklik gösterir. Ancak her şey Date1'den Date2'ye kadar olan aralıktadır.
Görev, D1'den D2'ye M dakikalık bir adımla (veya daha iyisi, özellikle tüm dizilerin işlem noktalarına göre) geçmek, K kriterine göre diğerlerinden daha iyi bir dizi bulmaktır (ayrı bir görev sadece en iyi diziyi bulmak için, ancak tüm seti kritere göre sıralamak ve ilk 10'u görüntülemek için - ancak bu isteğe bağlıdır, henüz gerekli değildir).
Kriter K, kendisine karşılık gelen dizinin önceki X işlemi temelinde hesaplanır, hesaplamalarda X işlemlerinin her biri hakkında neredeyse tüm bilgiler kullanılır (örneğin sadece kâr yeterli değildir).
Kriter (K), işlem sayısı (X) ve sonuçları etkileyen diğer parametreler kullanıcı tarafından değiştirilir. Onlar. algoritmaya "bağlı" olamaz.
Bunun gibi bir şey.
Teoride, dosyayı tüm dizilerdeki tüm işlemler için doğrusal olacak şekilde yeniden yapılandırabilirsiniz.
Ancak tüm bilgileri belleğe koymadan bunu nasıl yapabilirim? Ve eğer bir dizinin anlaşmaları tüm dosyaya "bulaşmışsa", Kriter nasıl yeniden hesaplanır?
Şimdi, umarım, görev açıktır.
Geleneksel olarak sabahları fren yaparım :).
Bir dizi belleğe sığacak mı, yoksa bu zaten bir sorun mu?
İlki ise, kullanıcı kriterleri ve parametreleri değiştirdiğinde diskten çoklu okuma ne zaman gerçekleşir?
Eğer öyleyse, vardiya bazı subjektif nedenlerle bir algoritmaya göre mi yoksa manuel olarak mı gidiyor?
Geleneksel olarak sabahları fren yaparım :).
Bir dizi belleğe sığacak mı, yoksa bu zaten bir sorun mu?
İlki ise, kullanıcı kriterleri ve parametreleri değiştirdiğinde diskten çoklu okuma ne zaman gerçekleşir?
Eğer öyleyse, vardiya bazı subjektif nedenlerle bir algoritmaya göre mi yoksa manuel olarak mı gidiyor?
Bir milyon dizi.
Daha sonra her birinde istenen tarihe sahip bir nokta bulunur ve önceki tarih analiz edilir.
Ve dizilerin en iyisi seçilir.
Ve "tarihin" bir sonraki noktasına geçiş var.
Son kullanıcıları bir DBMS kurulumuyla karıştırmak istemiyorsanız, birkaç (yaklaşık bir düzine) tipik K kriterini (örneğin, onları muhafazakar ticaret, agresif ticaret vb. olarak adlandırın) sentezleme seçeneği olduğunu düşünüyorum. ) ve aslında bunları bir algoritmaya dikin, tüm diziler için bir kez hesaplayın, seçilen göstergeyi zamanla değiştirin ve ardından tek boyutlu vektörlerle çalışın.
Diyelim ki sadece 2 kriter var.
Ancak kriteri ayarlayan birkaç parametre vardır ve her biri farklı değerler alabilir.
Her parametrenin birkaç değerini almak çok zor olsa bile, tek boyutlu bir vektör değil, 3 veya 4 boyutlu bir dizi elde edeceksiniz.
O zaman kesinlikle yeterli hafıza yok =)
Bir milyon dizi.
Daha sonra her birinde istenen tarihe sahip bir nokta bulunur ve önceki tarih analiz edilir.
Ve dizilerin en iyisi seçilir.
Ve "tarihin" bir sonraki noktasına bir geçiş var.
Tüm dizi belleğe yüklenir. Sonra içinde "gerekli tarihi olan bir nokta var ve önceki tarih analiz ediliyor". Kriter değeri en iyi başarı ile karşılaştırılır. Daha iyiyse, kriter hatırlanır ve en iyi sıralama hakkında bilmeniz gerekenler. Ardından, işlenen sıranın yerine bir sonraki yüklenir. Ve böylece milyonlarca kez.
Dosya sırayla ve yalnızca bir kez okunur.
Sorun nedir?
Tüm dizi belleğe yüklenir. Sonra içinde "gerekli tarihi olan bir nokta var ve önceki tarih analiz ediliyor". Kriter değeri en iyi başarı ile karşılaştırılır. Daha iyiyse, kriter hatırlanır ve en iyi sıralama hakkında bilmeniz gerekenler. Ardından, işlenen sıranın yerine bir sonraki yüklenir. Ve böylece milyonlarca kez.
Dosya sırayla ve yalnızca bir kez okunur.
Sorun nedir?
O gibi.
Ardından "gerekli tarih", seçilen diziden işlemin kapanış noktasına kaydırılır ve algoritma tekrarlanır.
Ve böylece bir milyon kez daha =)
O gibi.
Ardından "gerekli tarih", seçilen diziden işlemin kapanış noktasına kaydırılır ve algoritma tekrarlanır.
Ve böylece bir milyon kez daha =)
Ama diziler birbirinden bağımsız mı? O zaman neden bir kez yüklenen dizideki tarihlerde bir kerede bir döngü yapmak imkansız? Bu arada, bazı etkili tekrarlayan algoritmalara geçmek mümkün olabilir, ancak bu ne kadar şanslı. Milyonda milyon boyutu kalacak ve dosya bir kez okunacak.
Genel olarak, elbette, bir sonraki yinelemede adım sayısının aynı kaldığı bir problem (yani, hesaplamalar ilerledikçe arama alanı daralmaz) özellikle sağlam görünmez. Ama bu tabi ki subjektif.