yardıma ihtiyacım var! Görev çözülmedi, demirin sınırlamalarıyla karşılaşıyorum - sayfa 14
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
...
Pek çok benzer işlem dizisi vardır, her bir dizi zamana göre sıralanmıştır.
Bir dizi hafızaya sığacak mı?
Bir uzman yazabilirsiniz . Expert Advisor, başlangıçta sıra No.'yu (özellikler penceresindeki parametre) yükler ve bu sıraya göre işlem yapar. Optimizasyon hayır.
Görev tamamen net değil, ancak birçok farklı şeyi hayal edebilirsiniz.
Bir dizi hafızaya sığacak mı?
Bir uzman yazabilirsiniz . Expert Advisor, başlangıçta sıra No.'yu (özellikler penceresindeki parametre) yükler ve bu sıraya göre işlem yapar. Optimizasyon hayır.
Görev tamamen net değil ve birçok farklı şeyi fanatize edebilirsiniz.
Hacim 1 milyon dizinin bulunduğu 20 GB (21 474 836 480 bayt) ise, ortalama bir dizi (~ 21 KB) olarak yaklaşık 21 475 bayt alacağız. Telefonda bile hafızaya sığması gerektiğini düşünüyorum))
A. Bu arada, dağıtılmış bilgi işlem ne olacak? Bunu da düşünmeliydim...
Duraklama için tekrar özür dilerim, bir RAM diski ile deneme yaptım (şimdiye kadar çok başarılı değil). Hepsine sırayla cevap veriyorum.
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.
Bağımsız. Ve tüm diziler arasında bir kerede, onları belleğe yüklemeden bir döngüye nasıl girilir?
Dizileri doğru yerden nasıl okuyacağınızı bulursanız, adımların sayısı azaltılabilir (geçerli analiz edilen tarihten itibaren son X fırsatlar).
Tüm veritabanı 10 satıra sığar mı, sığmaz mı? tüm dosyalar birlikte
Milyon dizi başına 1 dosya (kolaylık olması için her birini 9 satırda yazıyorum).
Ya da bir milyon dosya, önemli değil.
Aşağıdakileri doğru anladım mı:
1) 20 GB'lık bir dosya, zamana göre sıralanmış yaklaşık bir milyon diziden oluşur
2) Her bir dizinin boyutu farklı olabilir ve dizinin içerdiği işlem sayısına bağlıdır.
3) Ortalama olarak bir dizinin boyutu 20/10^6 = 20 Mb'dir, bir diziyi tamamen indireceğimizi garanti edebilir miyiz?
4) K katsayısı yalnızca belirli bir sıradaki işlemlere bağlıdır.
5) Her dizi için K (toplam puan 10^6 adet) bulmalı ve ilk 10'u seçmeliyiz.
Bu tür ciltler olana kadar, her şeyi belleğe yükledim ve gerekli her şeyi sayarak bir döngüde sürdüm.
Sıraladığımız geçmişin her noktasında en iyi sıra seçilmelidir (en iyisi, şu anda en iyi Kriter'e sahip sıradır, kriter son kapatılan anlaşma ile hesaplanır.
Ve diziler arasındaki mesafelerin değerleriyle başka bir dosya oluşturursanız.
Bunu ve devamını anlamadım.
Bu arada, evet, dizi paketlerini hemen indirebilirsiniz.
Kurtarmayacak, herkese ihtiyaç var.
Nerede olduğunu anlamıyorum.
İşte bir kriter - her şey - Tarih1'den Tarih2'ye kadar olan aralıkta.
Yani, aşağıdakiler okunur.
Dosyayı neden Date1'den Date2'ye kadar birçok aralığa bölmüyorsunuz? Kapatılabilecek diziler üzerinde çalışılacak mı?
"Date1 - Date2" aralığı şu anda tüm dizilerin tüm işlemlerini kapsamaktadır.
Ve onu birkaç küçük parçaya bölme fikri oldukça sağlam. Doğru, o zaman parametrelerdeki her değişiklikle diskten bilgi okumanız gerekecek .. Ama bu zaten bir şey.
Görünüşe göre tek bir tarih geçişinin sonuçlarından biri yeni bir tarih.
Evet ama bence herhangi bir sırayla hiçbir işlemin olmayacağı bir nokta bulup ara verebilirsiniz.
Sonra bir sonraki aralığa geçiş olacak. Deneyeceğim.
görev ise:
verilen satır 1 2 3 4 5 6 7 8 9
örneğin 4'lük bir genişlik verildiğinde, genişlik içinde bir değer (örneğin, bir minimum) bulmak için tüm satır boyunca bu genişlikle hareket etmeniz gerekir:
önce 1 2 3 4 sonra 2 3 4 5 sonra 3 4 5 6 sonra 4 5 6 7 sonra .... vb. bulmanız gerekir.
X (işlem sayısı) sabitse (örneğinizde 4) ve başka parametre yoksa - evet. Ve böylece - hayır.
Bu konu hakkında düşünecektim.
Koşullar yukarıda özetlenmiştir, aramıza hoşgeldiniz ;)
Görev oldukça akademik olduğundan (bir programcı işe alırken bir soru gibi görünüyor) ve çoğu kişi buna ilgi gösterdiğinden, neden ilk verileri tanımlama biçimi açısından daha katı bir şekilde formüle etmiyorsunuz ve herkes 20 Gigabayt test verisi üretebilir ve pratik kararlarını sunuyorlar mı?
Sorun yok.
Tüm nitelikleriyle (kronolojik sırayla, diyelim ki 1 yıl için) rastgele işlem dizileri oluşturun: açılış tarihi ve saati, açılış fiyatı, SL, TP, kapanış tarihi ve saati, kapanış fiyatı. Dizileri 1'den milyona kadar numaralandırın.
Görev, tüm dizilerin tüm anlaşmalarından, birbiri ardına (zamanda kesişmeyen) ve belirli bir kritere göre seçilen yeni bir dizi anlaşma yapmaktır.
Kriter, sıradaki son 20 işlemin ortalama kârı olsun.
Sonuç örneği:
yani anlıyorum, kendi kendine yapılan bir test / optimize ediciden mi bahsediyoruz?
Evet, bunun gibi bir şey.
hayır, başka bir şey var.
Bazı komisyoncu / sağlayıcıların işlemlerinin tabanını görmek için. :)
eğer =)
Görevi basitleştirilmiş bir şekilde tekrarlayacağım
Hayır böyle değil. Spesifik bir örnek verdim, gerçek soruna mümkün olduğunca yakın sayılabilir.
Tipik olarak DB. Ama veri toplama olmadan bir yol yok... Dizinin benzersiz niteliklerini (başlangıçtan bitişe tarihler), ortalama kâr değerini K ve varyans D'yi ayrı bir tabloya yazabilir, ardından birbirine yakın olan ilk 10 diziyi arayabilirsiniz. istenilen kriterlere göre Bu alanlarda indeksler varsa, arama çok uzun sürmez (bir milyon kayıtta bile). Ayrıca, gerekli 10 diziyi aldıktan sonra, ilk verileri karıştırabilirsiniz, ancak bu artık bir milyonluk bir arama olmayacak, çünkü sınırlı tarihlerimiz var.
Kriter statik olsaydı...
Ya parametreleri değişirse?
Hala bir gizem olmaya devam ediyor - ne aramalı? tüm işlemlerin sonucu ne olmalıdır? Bir siparişi açma / kapatma konusunda bir karar vermekten bahsediyorsak, böyle bir hacmin işlenmesi oldukça fazla zaman alacaktır.
Evet, o zaman ticaret olacak. Ancak yeniden hesaplamaya yalnızca en son veriler için ihtiyaç duyulacak, tüm tarihi sosislemeye gerek yok.
Henüz başka bir nokta. Anlaşmalardan bahsettiğimize göre, her enstrüman için ayrı ayrı anlaşmalar yapmak mantıklı olabilir mi? EURUSD, USDJPY, vb. için uyarlanmış aynı tipte robotlar yazın.
Bu bir araç...
Bana öyle geliyor ki, bu şekilde yalnızca belirli bir sıranın ticareti için kullanılan stratejiyi (veya bir dizi robot parametresini) belirlemek ve piyasada belirli bir durumda ona gitmek mümkün.
Aynen öyle.
Bir dizi hafızaya sığacak mı?
Bir uzman yazabilirsiniz . Expert Advisor, başlangıçta sıra No.'yu (özellikler penceresindeki parametre) yükler ve bu sıraya göre işlem yapar. Optimizasyon hayır.
Uyacak.
Ancak ihtiyacımız olan sonuç bir (nihai) değil, zamanın her noktasında.
Prensip olarak, bir parametre olarak sayılacak sıra numarasını ve tarihi sağlayarak bulutu kullanabilirsiniz. Ancak bunun dosyayı yeniden hesaplamaktan daha hızlı olması pek olası değildir)
A. Bu arada, dağıtılmış bilgi işlem ne olacak? Bunu da düşünmeliydim...
Paralel olarak neyi sayacağız? Farklı diziler için kriterin anlamı?
Ancak bunun için belleğe yüklenmeleri gerekir. Ve bir süreçten (EA, terminal) veya birkaçından olması önemli değil. 4GB - 8 (veya 12, 16, 20) yerine almak için mi? Ama sonra yine de sonucu "yapıştırmanız" gerekiyor ..
Paralel olarak neyi sayacağız? Farklı diziler için kriter değeri?
Teoride, tüm hikayeleri 100 gruba ayırabilir ve her grup için ayrı ayrı optimal seçimi hesaplayabilirsiniz.
Ardından, her grup için yalnızca grubun en uygun kümesine dahil edilen öyküleri bırakın ve daha az geçmişle bir sonraki adıma geçin. Sonra teorik olarak 100 kez paraleldir.
Ve hafızadan her şey yolunda, grubun boyutu ayarlanabilir
Teoride, tüm hikayeleri 100 gruba ayırabilir ve her grup için ayrı ayrı optimal seçimi hesaplayabilirsiniz.
Ardından, her grup için yalnızca grubun en uygun kümesine dahil edilen öyküleri bırakın ve daha az geçmişle bir sonraki adıma geçin. Sonra teorik olarak 100 kez paraleldir.
Ve hafızadan her şey yolunda, grubun boyutu ayarlanabilir
100 parçadan 100'ünü paralel olarak yüklerseniz yeterli hafıza olmaz =)
Ve sırayla yüklerseniz (her seferinde en iyi seçeneği hatırlayarak), paralelleştirme nerede? Ve makineye her yaklaştığınızda dosya yine de okunacaktır.
Zor bir kısmi yükleme mekanizması icat etmenin mümkün olduğunu düşünüyorum, ancak icat edilmesi gerekiyor.
Örneğin, ilk okuma sırasında, her geçiş için Başlangıç Tarihinden önce kapatılan son anlaşmayı bulun, geri dönün ve X önceki anlaşmayı okuyun, bu anlaşmanın bittiği dosya noktasını hatırlayın.
Bundan sonra, sonuçlara dahil edilen ilk anlaşmayı bulun ve ardından yalnızca yeni verilerle çalışın: dosyayı istediğiniz noktadan yeni geçerli tarihe kadar okuyun ve dizideki anlaşmaları her kaydırdığınızda (sabit bir dizi boyutu elde edersiniz) - X öğeleri).
Bu, hem çoklu okuma problemini (sadece gerekli değildir) hem de hafıza problemini (sadece X milyon işlem sığdırabilirsek) çözecektir.
Bu yönde hareket edeceğim.
Bu arada, ikili dosyalara geçiş, pratik olarak boyut olarak bir kazanç sağlamadı.
Optimize ettiğim metin formatı çok kompakttı: her geçişte bir tarih (ilk işlemi açma) ve geri kalan her şey (hem açılış hem de kapanış) önceki tarihten bir mahsup olarak hatırlandı; SL, TP ve Kapanış Fiyatı da Açık Fiyattan mahsup olarak kaydedildi.
Ve bir ikili biçime geçerken, bu optimizasyon artık mantıklı gelmiyordu: saniye cinsinden bir kayma (uint) tam teşekküllü bir tarih kadar yer kaplıyor (uzun süre reddettim, 2030 benim için yeterli) ve ushort zaten değil yeterli (sadece 18 saat maksimum ofset). Fiyatlara benzer şekilde - mahsup ushort'a dönüştürülebilir, ancak daha sonra taşma kontrolleri eklemeniz gerekir (örneğin, SL = 0 ise) ve kazanç 3 fiyatın tümünde yalnızca 6 bayt olur. yapmamaya karar verdi.
Ama biraz fazladan bilgiyi kaldırdım, sonuç olarak yine de yüzde 20'yi geri kazandım. Orijinal dosyanın (20 GB olan) öngörülen boyutu 7-8 GB'dir, birkaç saat içinde dönüştürülür.
Dizeleri dönüştürmeye giden işlemci zamanı kazandı.