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 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 :
2018.11.1413:50:34.481 ArrayDeleteValue (BTCUSD,M15) вариант Pastushak: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 133765 микросекунд
2018.11.1413:50:34.486 ArrayDeleteValue (BTCUSD,M15) вариант Korotky: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 2330 микросекунд
2018.11.1413:50:34.489 ArrayDeleteValue (BTCUSD,M15) вариант Fedoseev: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 1840 микросекунд
2018.11.1413:50:34.492 ArrayDeleteValue (BTCUSD,M15) вариант Semko: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 777 микросекунд
2018.11.1413:50:34.497 ArrayDeleteValue (BTCUSD,M15) вариант Pavlov: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 2818 микросекунд
2018.11.1413:50:34.503 ArrayDeleteValue (BTCUSD,M15) вариант Nikitin: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 3922 микросекунд
2018.11.1413:50:34.510 ArrayDeleteValue (BTCUSD,M15) вариант Vladimir: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 4239 микросекунд
2018.11.1413:50:34.519 ArrayDeleteValue (BTCUSD,M15) вариант Peter: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 7307 микросекунд
2018.11.1413:50:34.522 ArrayDeleteValue (BTCUSD,M15) вариант Kuznetsov: Контрольная сумма = 7185.677992388435; элементов - 998993; время выполнения = 683 микросекунд
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 :
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.
Nikolai Semko:
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 :
Presque toutes les fonctions peuvent y être adaptées. Voici mon dernier (qui était purement expérimental, mais qui semble être l'un des moins chers).
template<typename T>
int arrayFilter(T &data[],const T value=NULL)
{
int s, _s = s = ArraySize(data);
bool result = false;
for(int i=0, j=0; i<_s; i++)
{
if( data[i] == value || data[i] == NULL )
{
result = true;
s--;
continue;
}
if( result )
data[j] = data[i];
j++;
}
if(s < _s)
ArrayResize(data, s);
return s;
}
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é...