L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 2808

Nouveau commentaire
 
Aleksey Vyazmikin #:

Votre script fonctionne depuis plus d'un jour et n'a pas encore créé un seul fichier sur la base des résultats du screening. Je ne sais pas, il est peut-être temps de l'éteindre ?

Cela dépend du zhekez et de la taille de l'échantillon. Si votre processeur est multicœur, parallélisez l'exécution. Voici une variante de l'exécution parallèle

##----parallel--------------------------
library("doFuture")
registerDoFuture()
plan(multisession)
require(foreach)
bench::bench_time(
foreach(i = 1:length(cor.test.range))%dopar%{
    get.findCor(dt, cor.coef = cor.test.range[i])
}-> res
)
#  process     real
# 140.62 ms    2.95 m
#
 bench::bench_time(
for(i in 1:length(cor.test.range)){
    paste0("train1_" , cor.test.range[i]*10 , ".csv") %>%
        paste0(patch , .) %>% fwrite(res[[i]], .)
}
)
#  process    real
# 156 ms   157 ms

Quatre fois plus rapide que l'exécution en série. Matériel et logiciel

sessionInfo()
#  AMD FX-8370 Eight-Core Processor
#  R version 4.1.3 (2022-03-10)
#  Platform: x86_64-w64-mingw32/x64 (64-bit)
#  Running under: Windows 10 x64 (build 19044)
#
#  Matrix products: default
#
#  locale:
#     [1] LC_COLLATE=Russian_Russia.1251  LC_CTYPE=Russian_Russia.1251    LC_MONETARY=Russian_Russia.1251
# [4] LC_NUMERIC=C                    LC_TIME=Russian_Russia.1251
#
#  attached base packages:
#     [1] stats     graphics  grDevices utils     datasets  methods   base
#
#  other attached packages:
#     [1] doFuture_0.12.2 future_1.28.0   foreach_1.5.2   fstcore_0.9.12  tidyft_0.4.5
#
#  loaded via a namespace (and not attached):
#     [1] Rcpp_1.0.9        codetools_0.2-18  listenv_0.8.0     digest_0.6.30     parallelly_1.32.1 magrittr_2.0.3
# [7] bench_1.1.2       stringi_1.7.8     data.table_1.14.4 fst_0.9.8         iterators_1.0.14  tools_4.1.3
# [13] stringr_1.4.1     import_1.3.0.9003 parallel_4.1.3    compiler_4.1.3    globals_0.16.1

Bonne chance

 
Maxim Dmitrievsky #:

tout est là. La vitesse sera catastrophiquement affectée. Les images de données sont les bêtes les plus lentes avec des frais généraux importants.

Il ne s'agit pas de cartes vidéo, il s'agit de comprendre que de telles choses ne comptent pas à travers les images de données dans un état sobre.

Qu'entend-on par "images de données" ? Expliquez-le aux ignorants dans ce langage.

 
mytarmailS #:

Conseil : Est-il nécessaire d'utiliser des vecteurs de 100 000 observations pour voir la corrélation entre eux ?

Je recherche des vecteurs fortement corrélés, c'est-à-dire dont la corrélation est supérieure à 0,9.

Je ne sais pas si c'est nécessaire ou non - vous devriez expérimenter. L'échantillon n'est pas stationnaire - pendant la moitié de l'échantillon, il n'y avait pas de corrélation, puis bang, puis elle est apparue.

De plus, j'ai essayé tous les coefficients par pas de 0,1.

mytarmailS #:
De rien.

Est-ce le cri de l'âme ?

 
Vladimir Perervenko #:

Cela dépend du zhekez et de la taille de l'échantillon. Si le processeur est multicœur, il faut paralléliser l'exécution. Voici une variante de l'exécution parallèle

Elle est 4 fois plus rapide que l'exécution en série. Matériel et logiciel

Bonne chance

Le parallélisme n'augmente donc pas la consommation de mémoire vive ?

Bien que le code de mytarmailS soit plus gourmand en RAM, il est 50 fois plus rapide, il y a peut-être des limitations des bibliothèques que vous utilisez - le script a fonctionné pendant plus de 30 heures et n'a pas créé un seul fichier.

Merci pour ces exemples de codes compliqués - en R, je suis plutôt un simple consommateur, je n'arrive pas à savoir ce qu'il faut corriger dans le script principal.

 
mytarmailS #:
Voulez-vous dire que pour chaque type de données, il devrait y avoir une méthode pour calculer corr ?

matrix est un type de données intégré à R, il a quelque chose comme matrix.corr() vector.

 
Aleksey Vyazmikin #:

Qu'entend-on par "dataframes" ? Expliquez aux ignorants de ce langage.

Il s'agissait plutôt d'un message aux auteurs de R :) il s'agit de tableaux permettant un affichage pratique des données et quelques manipulations typiques telles que l'extraction de sous-échantillons (comme en SQL).

Ils ne sont pas conçus pour être utilisés en boucle sur des données aussi volumineuses que les vôtres, ce qui serait 20 à 100 fois plus lent que des tableaux. Par mémoire, vous avez déjà compris par vous-même.

Je pense que tout va bien ici :

#  чтобы прочитать как работает функция и примеры  ?caret::findCorrelation
#  находим колонки которые не коррелированы с порогом корреляции 0,9    "cutoff = 0.9"
not_corr_colums <- caret::findCorrelation(as.matrix(df), cutoff = 0.9, exact = F,names = F)

Je ne sais pas si le type intégré "matrix" est rapide, mais il utilise le caret, qui peut également ralentir. Le type intégré n'a pas d'opération vectorielle pour calculer la corrélation ou quelque chose comme ça.

 
D'où viennent ces pensées ?
 
mytarmailS #:
D'où viennent ces pensées

pourquoi ralentir un type intégré au lobe gauche, qui devrait avoir son propre calcul du corr, aussi vite que possible pour lui ?

 
Maxim Dmitrievsky #:

Pourquoi ralentir un type intégré qui devrait avoir son propre calcul de Korr aussi rapide que possible ?

La librairie ne prend-elle pas en compte le type ? Le type de données est comme des données pour les calculs les moins chers. La même matrice devrait être conçue pour les calculs.

 
mytarmailS #:
Comment devenir plus intelligent dans le futur sans devenir plus stupide dans le passé ? Algorithmiquement... sans créer des téraoctets de connaissances.

Ce n'est pas le cas.

1...280128022803280428052806280728082809281028112812281328142815...3399
Nouveau commentaire