L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 2807
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Je l'ai échangée et elle semblait en ordre.
.
.
Votre script consomme près de 9 gigaoctets de RAM sur mon échantillon, mais il semble fonctionner, les fichiers sont sauvegardés. Je ne sais même pas où la mémoire est consommée là, alors que l'échantillon prend un peu plus d'un gigaoctet.
.
J'ai également découvert que les titres du tableau (noms de colonnes) sont enregistrés entre guillemets - comment désactiver cette fonction ?
Que fait ce code ? Pour le rendre plus rapide, vous devriez convertir toutes les colonnes dans le même type de données (float 32, 16 - pas besoin, ce sera plus lent) et calculer le coRRR à travers des tableaux rapides.
si nous parlons de la correction réelle du kaRma
Votre script consomme près de 9 gigaoctets de RAM sur mon échantillon, mais il semble fonctionner, les fichiers sont sauvegardés. Je ne sais même pas où la mémoire est utilisée, alors que l'échantillon prend un peu plus d'un gigaoctet.
Et alors ?
R mauvais probablement)
J'ai aussi trouvé un problème - les titres dans le tableau (noms de colonnes) sont sauvegardés entre guillemets - comment le désactiver ?
Qu'avez-vous fait pour résoudre le problème ?
Et alors ?
R est mauvais, je suppose.)
Qu'avez-vous fait pour résoudre le problème ?
Mauvais/bon est un jugement trop critique.
Il est évident que le code du progiciel n'est pas efficace en termes de mémoire, mais qu'il peut être rapide, ou que le script copie plusieurs fois l'ensemble de la sélection de tableaux.
Et ce que vous avez fait - vous avez trouvé le problème et l'avez signalé à un professionnel dans l'espoir d'obtenir de l'aide.
Que fait ce code ? Pour plus de rapidité, vous devriez convertir toutes les colonnes dans le même type de données (float 32, 16 - inutile, ce sera plus lent) et calculer le nombre de colonnes en utilisant des tableaux rapides.
si nous parlons de la correction réelle du kaRma
Pour autant que je sache, il n'y a pas de concept de types de données différents (int, float, etc.) dans R. Et, cela réduira la taille de la mémoire, mais cela n'affectera pas beaucoup la vitesse. Sur les cartes vidéo, oui, il y aura une augmentation.
D'après ce que j'ai compris, il n'y a pas de concept de types de données différents (int, float, etc.) dans R. Cela réduira la taille de la mémoire, mais n'affectera pas beaucoup la vitesse. Sur les cartes vidéo, oui, il y aura une augmentation.
Tout est là. Cela affectera la vitesse de manière catastrophique. Les images de données sont les bêtes les plus lentes avec le plus de frais généraux.
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.
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.