yardıma ihtiyacım var! Görev çözülmedi, demirin sınırlamalarıyla karşılaşıyorum - sayfa 17
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
Evet, bu formda görev paralelleştirilir - Arama Tarihindeki her değişiklikle, dizi setinin farklı bölümlerinde en iyi Kriter için eşzamanlı bir arama başlatabilirsiniz. Örneğin, bunları 20 parçaya bölün ve görevleri 20 danışmana dağıtın. Ve dosyayı okumalarına, bir anlaşma bulmalarına ve yalnızca en iyi diziyi (##, Kriterler ve dosya konumu) geri göndermelerine izin verin.
Herkese çok teşekkürler!
Diskten okumak oldukça pahalı bir işlemdir - bu algoritmayı birkaç Uzman Danışman üzerinde çalıştırarak, her şey diskten + kısımlarda + farklı konumlardan okuma hızı ile sınırlandırılacak ve bu fikir büyük olasılıkla hız vermeyecektir.
verileri tek bir okumada her şeyi hesaplayabilirsiniz - ana arzu
Diskten okumak oldukça pahalı bir işlemdir - bu algoritmayı birkaç Uzman Danışman üzerinde çalıştırarak, her şey diskten + kısımlarda + farklı konumlardan okuma hızı ile sınırlandırılacak ve bu fikir büyük olasılıkla hız vermeyecektir.
Dağıtılmış bilgi işlemin tek bir iş istasyonunda gerçekleştirilmesi gerektiğini kim söyledi? böyle bir kısıtlama yoktur)) Evet ve yukarıda belirtildiği gibi yardımcı olacak bir RAM diski.
Algoritmayı biraz değiştirmeye ne dersiniz?
1. Bir çırpıda birden fazla sekans nasıl indirilir ve nerede başlayıp nerede bittikleri nasıl anlaşılır
2. Tek bir sırayla tüm işlemler için katsayıların nasıl hesaplanacağı ve cevabın hangi veri yapısında saklanacağı
3. Önceki paragraftaki iki cevabı biraz daha eksiksiz yeni bir cevapla nasıl birleştirirsiniz?
4. 3. noktadan gelen son cevabı gerekli aralıklara nasıl böleriz ( İstenen Tarih = Anlaşma Kapanış Saati + 1'den bahsediyoruz)
RequiredDate aralığının kaç ek parçaya bölüneceğini seçerek biraz farklı bir algoritma elde edebiliriz.
orijinal yazarın algoritmasına kıyasla farklı hatalar alabiliriz.
Numaranın kapasitesi, sistemin kapasitesine göre değil, kayıt kodunun benzersizliğine göre belirlenir. Bunun (sayı kapasitesi) 1 baytın katı olması gerektiği açıktır.
64 bit bence fazla. :)
1.000.000 kayıt varsa, benzersiz bir kayıt kodu için 16 basamak yeterli olmayacaktır (maksimum 65536 kayıt). Bu zaman.
Intel (Itanium), AMD (işletim sisteminden bahsetmedim) 32-bit ve 64-bit işlemcilerin mimarisine bakın. 32/64 - adres veriyolu çözünürlüğü, ancak aynı zamanda, bir bayt belleğe erişirken bile, bir makine döngüsünde bellekten 32/64 bit (4/8 bayt) okunur.
Bu nedenle bellekten 2 bayt veya 8 bayt okumak performans açısından kesinlikle önemsiz olacaktır.
Prensip olarak, bu tür dosya işleme için bir Windows Hizmeti yazabilirsiniz.
Ama yine de bir DBMS kullanma eğilimindeyim.
Algoritmayı biraz değiştirmeye ne dersiniz?
1. Bir çırpıda birden fazla sekans nasıl indirilir ve nerede başlayıp nerede bittikleri nasıl anlaşılır
2. Tek bir sırayla tüm işlemler için katsayıların nasıl hesaplanacağı ve cevabın hangi veri yapısında saklanacağı
3. Önceki paragraftaki iki cevabı biraz daha eksiksiz yeni bir cevapla nasıl birleştirirsiniz?
4. 3. noktadan gelen son cevabı gerekli aralıklara nasıl böleriz ( İstenen Tarih = Anlaşma Kapanış Saati + 1'den bahsediyoruz)
RequiredDate aralığının kaç ek parçaya bölüneceğini seçerek biraz farklı bir algoritma elde edebiliriz.
orijinal yazarın algoritmasına kıyasla farklı hatalar alabiliriz.
Tüm 4 nokta için - DBMS tarafında veri işleme.
"Biraz farklı" algoritmaya gelince, ne demek istediğiniz tam olarak açık değil. Ancak. Bu "biraz farklı" algoritmanın hatasını "yazarın" algoritmasına kıyasla bir şekilde hesaplamak için her iki algoritmanın da uygulanması gerekir. Ve konu, "yazarın" algoritmasını uygulamanın teknik sorunuyla bağlantılı olarak oluşturuldu.
Bu gerçek göz önüne alındığında, bahsettiğiniz hatayı hesaplamak için hangi metodolojiyi kullanacaksınız?
verileri tek bir okumada her şeyi hesaplayabilirsiniz - ana arzu
Diskten okumak oldukça pahalı bir işlemdir - bu algoritmayı birkaç Uzman Danışman üzerinde çalıştırarak, her şey diskten + kısımlarda + farklı konumlardan okuma hızı ile sınırlandırılacak ve bu fikir büyük olasılıkla hız vermeyecektir.
Diyelim ki HDD en yavaş cihaz, bu bir gerçek. Ancak, tüm bu hesaplamaları kullanarak birkaç Uzman Danışman başlatmaktan bahsetmiyoruz. Bana öyle geliyor ki en olası uygulama sinyal üretimi. Diyelim ki Amazon'da gerekli performansa sahip bir bulut sunucusu + MT4 + bu geliştirme = sinyal sağlayıcı.
Tüm 4 nokta için - DBMS tarafında veri işleme.
"Biraz farklı" algoritmaya gelince, ne demek istediğiniz tam olarak açık değil. Ancak. Bu "biraz farklı" algoritmanın hatasını "yazarın" algoritmasına kıyasla bir şekilde hesaplamak için her iki algoritmanın da uygulanması gerekir. Ve konu, sadece "yazarın" algoritmasını uygulamanın teknik sorunuyla bağlantılı olarak oluşturuldu.
Bu gerçek göz önüne alındığında, bahsettiğiniz hatayı hesaplamak için hangi metodolojiyi kullanacaksınız?
yazardan, anladığım kadarıyla (aniden bir şeyler ters gidiyor, çünkü herhangi bir yerde tam olarak neyin gerekli olduğuna dair anlaşılır ve eksiksiz bir açıklama yok), sürümde bu aralıktan seçilen maksimum katsayı ile aralık kesilecek Ben önerdim - bu tür her bir aralığı, birleştirme sırasında katsayının yalnızca bir değerinin sığabileceği N alt aralığa bölmek. N = 5 ile çıkıyor, aralık sadece 0,2 0,4 0,6 0,8 1 oranlarına bölünebilir. N = 5'te maksimum.
Ve yazarın gönderilerinin ne kadar doğru yorumlandığıyla ilgili her şey, çünkü hala tam bir netlik yok.
yazardan, anladığım kadarıyla (aniden bir şeyler ters gidiyor, çünkü herhangi bir yerde tam olarak neyin gerekli olduğuna dair anlaşılır ve eksiksiz bir açıklama yok), sürümde bu aralıktan seçilen maksimum katsayı ile aralık kesilecek Bu tür her bir aralığı, birleştirildiğinde katsayının yalnızca bir değerinin sığabileceği N alt aralığına bölmeyi önerdim. N = 5 ile çıkıyor, aralık sadece 0,2 0,4 0,6 0,8 1 oranlarına bölünebilir. N = 5'te maksimum.
Ve yazarın gönderilerinin ne kadar doğru yorumlandığıyla ilgili her şey, çünkü hala tam bir netlik yok.
Evet, görünüşe göre Maliye Bakanlığı projeyi emretti, spesifik bilgiler yeterli değil. Ancak, herkes tartışmadan kendisi için ilginç bir şey bulabilir. Bunda olumlu bir tartışma görüyorum.
Aralıkların ayrıklaştırılması hakkında fikriniz açık. Ve eğer N=100, 1000... (bu tamamen matematiksel olarak mümkündür), o zaman böyle bir bölünme, performans ve sistem kaynaklarının kullanımı açısından bir ters tepmeye neden olacaktır. Matematiğin yanı sıra fizik de var)
Hafızada dosyanın bir parçası var, üzerinden geçiyoruz ve kriteri hesaplamak için gerekli uzunluğun bir seçimini oluşturuyoruz, sadece aynı sıraya ait anlaşmaları seçiyoruz. Daha sonra bu örneğe göre kriteri hesaplıyoruz. Bu arada, fikir, seçimde özyinelemeyi kullanma fırsatları olduğudur.
Bu nedenle, diğer dizilerden birkaç milyon işlemi sıralamak gerekecek! İşte tam da bundan bahsediyorum.
yeni veri ekleme sorunu - bir şekilde çözün.
Herhangi bir problem olmadığı sürece, sabit miktarda veri vardır.
Bu arada, her dizinin başlangıç yeri biliniyorsa, gerekli tarihler ikili arama ile aranabilir, çünkü işlemler zamana göre sıralanır.
+1, fikir için teşekkürler.
1. Yukarıdaki " Kriter, dizinin son 20 işlemi için ortalama kâr olsun. " temelinde, bu bir kriter olarak anlaşılmalıdır, hareketli kâr beklentisi. Orada başka neler var?
Veritabanında, sıra kimliği ve ilgili hareketli ortalamalar ile bir tablo oluşturun. Uygun olmayan diziler derhal kaldırılmalıdır. Bu, robotun talebi üzerine DBMS düzeyinde eşzamanlı modda bir prosedürle, işlemin robottaki durumunu görüntüleyerek yapılmalıdır.
Diyelim ki, FilterAvgProfit (pProfitValue, pTrades, pDeviation) prosedürü,
pProfitValue istenen kâr olduğunda, pTrades hareketli ortalama kâr için işlem sayısıdır, pDeviation, pProfitValue'dan izin verilen sapmadır.
Sonuç, sıra kimlikleri ve ortalama kâr değerleri ile tamamlanmış bir tablodur.
1 A. Başka hangi kriterler - önemli değil. Hesaplamanın belirli bir uzunluktaki bir dizi işleme dayanması önemlidir.
1b. Bir dizi, N ticaretinin kapanışında kötü bir kriter değerine sahip olduğu için nasıl atılabilir? Ya iyileşirse?
Yalnızca, kriterin asla "bir artı haline gelmediği" açıkça başarısız olan dizileri silmek mümkün olacaktır. Ve onlardan çok fazla olmamalıdır.
4. Anladığım kadarıyla strateji seçme yönüne bakarsanız bu işlemin çok sık yapılmaması gerekiyor (mesela her barda veya emir açmadan hemen önce). Mevcut strateji art arda N adet kaybetmeye yol açıyorsa bu yaklaşımı kullanmak mantıklıdır - o zaman başka bir tane seçebilirsiniz ve "karar vermek" için zaman harcamanız gerekecek, gidecek hiçbir yer yok. Veya böyle bir seçimi haftada bir (piyasanın kapalı olduğu hafta sonları) yapın ve mevcut seçilen stratejiyi onaylayın veya başka bir stratejiye geçin. Tüccar için görüntüleyebilirsiniz - bu koşullarda önerilen en uygun stratejilerin bir listesi. Ardından, piyasanın açılmasıyla ve taze bir zihinle (Pazartesi günü), tüccarın kendisi seçimi onaylayacaktır (veya daha önce, piyasa açılmadan önce ... e-posta ile bildirim vb.).
Eh, bu bir ideoloji meselesi. Şimdi onunla ilgili değil ;)
Bir dizi yapı için bellek ayırırsınız ve şunları elde edersiniz:
Neden bir Ölçüt Değeri dizisine ve bir dizi Dosya İşaretçisi Konumuna ihtiyacınız var? (bir kriter ve son anlaşmayı tutmayı düşünmediniz mi?)
Kriter değerleri dizisi - birkaç en iyi diziyi sıralamak ve seçmek için (gelecek için).
Dosya işaretçi konumları - her dizide aramaya doğru yerden devam etmek için (başka nasıl?).
Doğru mu anladım:
İlk geçiş - 0 ile SearchDate arasındaki aralıkta arama yapın
sonra en iyi kriteri bulun ve SearchDate = Anlaşma kapanış zamanı + 1
şimdi "Ticaret Kapanış Saati" ile SearchDate arasındaki aralıkta arama yapıyorsunuz ???
ve her bir dizi için kriteri hesaplamak için X işleminin bu aralığa uyması gerekli mi?
1. Evet, önce 0'dan SearchDate'e
2. Hayır. RequiredDate kaydırılır ve diziyi işliyoruz (diziye işlemler ekliyoruz), "PreviousProcessedDeal - RequiredDate" aralığındayız.
Garip sonuçlar.
İşte yük altında çalışan sunucu sistemimizden:
Disk çerçeveleri olmadan projeleri çok daha uzun süre topluyoruz.
Karmaşık olmaya başlıyorum.
Muhtemelen, benzer bir görevde kontrol edebilmeniz için bir test komut dosyası oluşturmanız ve bir dosya eklemeniz gerekir.
Normal bir sabit sürücüm var - wdc wd1002FAEX-00Y9A0, teknik özelliklere göre değerlendirildiğinde maksimum hız 126 MB / s:
İncelemeye bakılırsa, bu kadarı sıkılabilir. Belki yanlış bir şey yapıyorum?
Senaryoya bakalım..
ne hakkında konuşuyordu - büyük dosyaları büyük parçalar halinde okumanız gerekiyor, aksi takdirde küçük dosyalar 10 veya daha fazla kat daha uzun olabilir.
Büyük bir parça nasıl okunur?
Bence sorunun çözümü kaynak verileri kodlamak.
Bilgileri kaybetmeden tam işlem bilgileri nasıl kodlanır?
Garip sonuçlar.
İşte yük altında çalışan sunucu sistemimizden:
Disk çerçeveleri olmadan projeleri çok daha uzun süre topluyoruz.
Hafıza hakkında yazmayı unuttum.
DDR3, 1333MHz:
Softperfect RAM Disk 3.4.5, ancak NTFS yaptım (bir fark var mı?)
Ve başka bir ayrıntı - 12000 MB RAM disk ve yalnızca 1-2 GB boş bellek (iş için) kalır.