yardıma ihtiyacım var! Görev çözülmedi, demirin sınırlamalarıyla karşılaşıyorum - sayfa 16

 
komposter : Böyle bir dosya verildiğinde, bir sıradaki son X işlemi için kriter nasıl hesaplanır?


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 özyineleme kullanma fırsatları olduğudur.

Yoksa soruyu anlamadım?

PS Tabii ki, bir örnek oluştururken dosya üzerinden geri gitmeniz gerekiyor.

 
Candid :

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 özyineleme kullanma fırsatları olduğudur.

Yoksa soruyu anlamadım?

PS Tabii ki, bir örnek oluştururken dosya üzerinden geri gitmeniz gerekiyor.

yeni veri ekleme sorunu - bir şekilde çözün.

Neden beyaz çorapları bir sepete, siyahları diğerine dağıtmak ve sonra orada kim ve ne kadar olduğunu sormak daha kolaysa, neden birçok kez beyaz çorap seçiyorsunuz.

 
komposter :

Bir parça okunuyor. Yığın boyutu, belirli bir sıradaki Arama Tarihinden önceki anlaşmaların sayısına göre belirlenir.

Bu arada, her dizinin başlangıç yeri biliniyorsa, istenen tarihler ikili arama ile aranabilir, çünkü işlemler zamana göre sıralanır.
 
ALXIMIKS :

yeni veri ekleme sorunu - bir şekilde çözün.

Neden beyaz çorapları bir sepete, siyahları diğerine dağıtmak ve sonra kimin ve ne kadar olduğunu sormak daha kolaysa, neden defalarca beyaz çorap seçiyorsunuz.

Fazla veri de kötü :)

Sorun, burada seçilenlerin beyazlar ve siyahlar değil, yerel olarak daha beyaz olanlar olmasıdır. Bu nedenle, küresel emisyonun hesaplanması yardımcı olmaz. Bu arada, bu konuya sadece kriterin sürekli hesaplanması önerisiyle başladım.

Not Bu arada, hiç kimse birkaç dosyayı birlikte işlemekle uğraşmıyor - sadece her biri için önbelleğin daha az yapılması gerekecek. Ancak önbellek boyutu açısından bir marj var gibi görünüyor.

Yani, yeni veriler basitçe başka bir dosyada toplanabilir.

PPS Bu arada, dosyayı birkaç küçük sıralama problemine bölmek daha kolay olacaktır.

 
komposter :

1. Kriter statik olsaydı... Ya parametreleri değişirse?

2. Evet, o zaman ticaret olacak. Ancak yeniden hesaplamaya yalnızca en son veriler için ihtiyaç duyulacak, tüm tarihi sosislemeye gerek yok.

3. Bu bir araçtır...

4. Kesinlikle.

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 karşılık gelen hareketli ortalamalar ile bir tablo oluşturun. Uygun olmayan diziler derhal silinmelidir. 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.

Benzer şekilde, her bir kriter için saklı yordamlar yazabilirsiniz.

2. Verileri kısmen atarsanız (1 milyon değil "yeni veri" kullanın), bu performans artışı sağlayacaktır.

3. Üretimden tam olarak belli değildi. Şimdi tamam.

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, böyle bir yerde.

 

Память выделяется однократно для массива структур последовательностей.

Dizinin yapısı şunları içerir: #, [X] dizisindeki tüm anlaşmaların yapı dizisi, Ölçüt Değeri, Dosya İşaretçisinin Konumu.

Sonraki adım, yalnızca yapının öğelerini doldurmaktır (anlaşma dizileri dahil). Dizideki fırsatlar kaydırılır, bu nedenle bellekteki her dizide her zaman yalnızca X anlaşma vardır.

Bir dizi yapı için bellek ayırırsınız ve şunları elde edersiniz:

dizi No.,

[X] dizisindeki tüm anlaşmaların yapı dizileri dizisi,

dizi Ölçüt Değeri,

Dosya İşaretçisi Konumları dizisi.

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?)

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?

 
komposter :

Araştırma sonuçlarımı paylaşıyorum.

7529 MB'lık bir ikili önbellek dosyası şunları okur:

  • sabit sürücüden: 212,3 saniyede (35,46 MB/sn)
  • RAM diskten: 88.1 saniyede (85.46 MB/sn)
Sabit diskimin en yaygın olmasına rağmen (bellek yüksek hızlı olmasa da) farkı kozmik olarak adlandırmak zor.

Sonuç: RAM disk kullanarak büyük bir dosyayı okumadaki hızlanma yaklaşık 2,5 kattır.

Garip sonuçlar.

İşte yük altında çalışan sunucu sistemimizden:

  • SSD ile: Saniyede 200 Mb, NTFS
  • RAM ile: Saniyede 2000-2500 Mb, FAT32, Softperfect RAM Disk 3.4.5

Disk çerçeveleri olmadan projeleri çok daha uzun süre topluyoruz.

 
Renat :

Garip sonuçlar.

İşte yük altında çalışan sunucu sistemimizden:

  • SSD ile: Saniyede 200 Mb, NTFS
  • RAM ile: Saniyede 2000-2500 Mb, FAT32, Softperfect RAM Disk 3.4.5

Disk çerçeveleri olmadan projeleri çok daha uzun süre topluyoruz.

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.
 
papaklass :

Bence sorunun çözümü kaynak verileri kodlamak.

Orijinal verilerin çoklu okunmasından kurtulmak mümkün değilse, çoklu okuma için kabul edilebilir bir formata dönüştürülmeleri gerekir.

Bir seçenek, her girişi 16 bitlik bir sayıya dönüştürmektir. Orijinal kaydın her alanına belirli sayıda bit tahsis edin. Örneğin:

sayının en anlamlı basamağı:

- "0" işlemin olumsuz sonucu anlamına gelir;

- "1", işlemin olumlu sonucu anlamına gelir.

en az anlamlı rakam:

- "0" bir SATIN AL anlaşması anlamına gelir;

- "1" bir SATIŞ anlaşması anlamına gelir.

vb.

Böylece, birçok alanla kaynak dosyayı tekrar tekrar okumak yerine, iş, önemli bir hızlanma sağlaması gereken bir sayısal alanın tekrar tekrar okunmasına indirgenir.

Genel olarak, kaynak dosya, içindeki bilgiler görsel olmayan bir biçimde görünse de, hemen kodlanmış bir biçimde oluşturulabilir.

Yalnızca "16" bit'te değil, 64 bit'te Andrey bir x64 işlemciye sahiptir, bu nedenle belleğe erişirken minimum birim birimi 64 bittir. Bellekten okunan en az bir bayt, işlemci hala 8 bayt (iki çift kelime) okuyacaktır.

 
komposter :

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!

O başka bir konu))