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
Ainsi, si un ordre est fermé, il doit être "rayé" du tableau. Dans de tels cas, j'avais l'habitude de copier le tableau "dans lui-même" et de réduire sa taille d'une unité.
Dans ce cas, j'écrirais un ticket inexistant dans le tableau -1, j'attendrais que tous les ordres aient été fermés et je supprimerais le tableau entier (la taille du tableau devrait être fixée à 1).
Dans cette approche, un élément du tableau de tickets (s'il n'y a pas d'ordre) est vérifié avec une seule condition : if(ArrayOfTicket[i] > 0) ......
imho, c'est plus rapide que de "secouer" constamment le tableau
Dans ce cas, j'écrirais un ticket inexistant dans le tableau -1, attendrais que tous les ordres soient fermés et supprimerais le tableau entier (taille du tableau = 1).
Dans cette approche, un élément du tableau de tickets (s'il n'y a pas d'ordre) est vérifié avec une seule condition : if(ArrayOfTicket[i] > 0) ......
imho, c'est plus rapide que de "secouer" constamment le tableau
Je ne comprends pas... Quelle différence cela fait-il de supprimer élément par élément ou de vérifier les indices des ordres inexistants... le tableau est de toute façon secoué...
De toute façon, comme ils l'ont dit aux infos aujourd'hui, il est impossible de breveter un parfum. Les farines ne sont différentes que par leur couleur, mais elles ont toutes le même goût.
Je ne comprends pas... Quelle différence cela fait-il que vous vouliez supprimer les éléments un par un ou vérifier les index de commandes inexistantes... Le tableau est de toute façon débordé...
De toute façon, comme ils l'ont dit aux infos aujourd'hui, il est impossible de breveter un parfum. Les farines ne sont différentes que par leur couleur, mais elles ont toutes le même goût.
La suppression d'un élément implique la copie des éléments restants du tableau, je ne supprime pas les éléments du tableau, je marque les éléments inexistants (tickets) avec la valeur -1, et je supprime un tableau de tickets lorsqu'il n'y a pas d'ordres de marché.
Quant aux marqueurs de flottaison, c'est tout à fait vrai, cela dépend du problème, en principe, il y a généralement 2 solutions lors de l'optimisation :
- soit ajouter de la complexité à l'algorithme, mais économiser la mémoire et les ressources de calcul du PC
- ou simplifier l'algorithme et économiser des ressources de calcul mais gaspiller de la mémoire
La somme de contrôle n'est pas correcte, s'il y a 0 dans le tableau, il peut y avoir une erreur.
La variante de Nikitin fonctionne justement sur une telle erreur.
La somme de contrôle n'est pas correcte, s'il y a 0 dans le tableau, il peut y avoir une erreur.
La variante de Nikitin fonctionne juste pour une telle erreur.
Oui, vous avez raison. Seul Nikitin a en plus jeté zéro élément. C'est pourquoi son code avait l'air d'être défectueux. En fait, il s'agissait de résoudre la tâche que vous aviez initialement fixée.
Si vous documentez sa vérification des éléments nuls, le résultat est le même :
Là encore, la somme de contrôle tient maintenant compte de l'ordre des éléments, ce qui n'était pas le cas auparavant.
Oui, vous avez raison. Seul Nikitin jetait aussi des éléments nuls supplémentaires. C'est pourquoi son code avait l'air d'être faux. En fait, il s'agissait de résoudre la tâche que vous aviez initialement fixée.
Si vous documentez sa vérification des éléments nuls, le résultat est le même :
Encore une fois, la somme de contrôle prend maintenant en compte l'ordre des éléments, ce qui n'était pas le cas auparavant.
À propos, si l'ordre est très important, vous pouvez ajouter ArraySort à la fin de ma variante et voir si ArraySort est efficace.
Je m'intéresse maintenant à une autre question, à laquelle je ne trouve pas de réponse.
Peut-être que quelqu'un peut expliquer pourquoi cette variante du code de Kuznetsov :
fonctionne plus de deux fois plus vite que celui-ci, qui fait exactement la même chose :
Quelles sont les merveilles du compilateur ?
Est-il possible que pour une telle conception :
while(arr[i]!=x && i<j) i++;
Le compilateur trouve-t-il une commande spéciale de recherche en assembleur pour le processeur ?
Quelqu'un est-il fort en commandes de processeurs modernes ?
A propos, si l'ordre est très important, je peux ajouter ArraySort à la fin de ma version, voyons en même temps l'efficacité d'ArraySort.
Je l'ai essayé. C'est une fonction assez coûteuse. Il est cependant plus facile de le jeter après coup. Tous ceux qui sont nécessaires vont dans une rangée.
Oui, vous avez raison. Seul Nikitin lançait des éléments nuls en plus. C'est pour ça que son code était faux. En fait, c'est la tâche que vous aviez définie au tout début.
Si vous documentez sa vérification des éléments nuls, le résultat est le même :
:
fonctionne plus de deux fois plus vite qu'une autre qui fait exactement la même chose :
l'optimiseur n'est pas pertinent - les comparaisons sont inférieures à la moitié...