Effacement d'un tableau d'élément(s) défini(s) - page 21

[Konstantin Nikitin]

Je ne sais pas comment il se comportera avec les éléments suivants

ArraySetAsSeries(array,true);

Dans la dernière variante, j'ai fait un chèque pour cela aussi. Ceux qui en ont besoin peuvent l'utiliser.

[Konstantin Nikitin]

Реter Konow:

Bien. Mais comment savoir si les algorithmes fournis ne laissent pas d'espaces vides ? La somme de contrôle ne le prouve pas. Le nombre d'éléments non plus. Après tout, la fonction compte les éléments qui étaient là avant que le tableau ne soit redimensionné.

Dans presque toutes les présentations, cela est mis en œuvre sans problème en envoyant une requête avec NULL.

Le tag Konow:

Il y a une autre exigence pour l'algorithme - le placement correct des éléments dans le tableau après avoir supprimé les éléments inutiles. Cette vérification doit avoir été effectuée au préalable. Ensuite, il y a un contrôle de la vitesse.

Le code explique lesquels retournent quoi. Il y a des matrices mélangées. Il y en a dans un autre tableau.

P.S. Et juste pour info. Ma fonction a quelques contrôles, mais n'est pas utilisée. Mais il possède déjà tout cela et plus encore.

[Реter Konow]

Je ne remets pas en cause le professionnalisme des participants et de leurs lieux. J'ai simplement signalé un défaut dans la vérification de la somme de contrôle et aussi, la nécessité d'une vérification supplémentaire de l'exactitude de la disposition des éléments dans le nouveau tableau.

Si tout cela est correct, j'ai mérité l'avant-dernière place.

Dans ma pratique, je pense rarement à la vitesse des opérations spécifiques. Je suis plus préoccupé par la concision et la clarté de la solution. J'ai été surpris de constater que cette entrée

if(Arr[q]==val){deleted++; q--;}

pourrait être lent.

Mais si vous ajoutez un critère supplémentaire d'évaluation des algorithmes - la compacité de la solution - je suis probablement à la première place.

Si l'on combine les deux critères - vitesse et compression - et que l'on calcule le score moyen de l'algorithme, je prends une place plus importante dans le tableau.

La version de Fedoseyev, cependant, est encore plus condensée que la mienne.

[Nikolai Semko]

Реter Konow:

Toutefois, si vous ajoutez un autre critère d'évaluation des algorithmes, la compression des solutions, je suis probablement en première place.

Votre version de la boucle principale :

for(int a1=0; a1<ArraySize(Arr); a1++)
     {
      if(deleted)Arr[q]=Arr[q+deleted];
      if(Arr[q]==val)
        {
         deleted++; 
         q--;
        }
      q++;
     }

et c'est celui de Fedoseyev :

for(;i<sz;i++)
     {
      if(a[i]!=v)
        {
         a[j]=a[i];
         j++;
        }
     }

Les deux variantes font la même chose. Qui est le plus concis ?

[Реter Konow]

Nikolai Semko:

Votre version du cycle principal :

et c'est celui de Fedoseyev :

Les deux font la même chose. Qui a le plus de concis ?

Lui. Il l'a au lieu de...

for(int a1=0; a1<ArraySize(Arr); a1++)

for(;i<sz;i++)

C'est plus succinct.)

[Nikolai Semko]

Реter Konow:

Il l'a fait. Il l'a au lieu de...

C'est plus succinct.))

C'est la même chose pour le compilateur.

Vous avez simplement beaucoup de choses inutiles, ce qui fait qu'il fonctionne plus lentement que tous les autres (je ne considère même pas la première option du sujet).

Le code de Fedoseyev a un contrôle, une affectation et un incrément dans un passage de boucle (je ne compte pas les contrôles et les incréments pour l'organisation de la boucle).

En revanche, vous avez deux contrôles, une somme de deux variables, trois incréments et une affectation.

[Aleksey Lebedev]

for(int a1=0; a1<ArraySize(Arr); a1++)

Tout espoir est que le compilateur optimise, sinon ArraySize est exécuté à chaque itération.

[Nikolai Semko]

Aleksey Lebedev:

Tout espoir est que le compilateur optimise, sinon ArraySize est exécuté à chaque itération.

Oui, le compilateur semble vérifier que si la taille du tableau ne change pas dans la boucle, il remplace indépendamment cette fonction par une valeur et calcule cette fonction une seule fois.
En tout cas, si vous faites ça :

const int size=ArraySize(Arr);
for(int a1=0; a1<size; a1++)

le temps d'exécution de la fonction ne change pas.

Pour plus de compacité, il est donc logique de l'écrire exactement comme Peter l'a fait :)
Mais je suis d'accord, personnellement ça me pique les yeux aussi. On a l'impression que la fonction sera appelée à chaque fois.

[Aleksey Lebedev]

Nikolai Semko:

Mais je suis d'accord, personnellement, ça me coupe aussi. On a l'impression que la fonction sera appelée à chaque fois.

Il est préférable de ne pas laisser le choix au compilateur.)

Laissez-moi vous poser une question,

if(count>6) { ArrayCopy

plus de six - la valeur est-elle obtenue par une intuition scientifique, ou y a-t-il une justification ?)

[Nikolai Semko]

Aleksey Lebedev:

il est préférable de ne pas donner le choix au compilateur)

Laissez-moi vous poser une question,

if(count>6) { ArrayCopy

plus de six - la valeur est obtenue par une intuition scientifique, ou quel est le raisonnement derrière ?)

Oui, c'est exactement ça. La méthode de l'intuition scientifique. En fait, de 5 à 8 selon mes observations. Vous pouvez automatiser ce processus en réglant automatiquement ce nombre à chaque fois. Après tout, ce nombre peut être différent pour différents processeurs et systèmes.

Par exemple, si vous modifiez tous les ArrayCopy et ArrayFill de la classe CCanvas selon ce principe, vous pouvez obtenir un gain de vitesse appréciable pour le canevas.