Borrar una matriz de elementos definidos - página 21

 
No sé cómo se comportará con
ArraySetAsSeries(array,true);
En la última variante también hice una comprobación para ello. Quien lo necesite puede utilizarlo.
Archivos adjuntos:
 
Реter Konow:

Sí. Pero, ¿cómo sabemos que los algoritmos proporcionados no dejan espacios en blanco? La suma de comprobación no lo demuestra. Tampoco el número de elementos. Al fin y al cabo, la función cuenta los elementos que había antes de redimensionar el array.

En casi todas las presentaciones esto se implementa sin problemas enviando una consulta con NULL.

La etiqueta Konow:

Hay otro requisito para el algoritmo: la colocación correcta de los elementos dentro de la matriz después de eliminar los elementos innecesarios. Esta comprobación debe realizarse primero. Luego hay una comprobación de la velocidad.

El código explica qué devuelve qué. Hay matrices barajadas. Hay en otra matriz.

P.D. Y sólo para que conste. Mi función tiene algunos controles, pero no se utiliza. Pero ya tiene todo esto y más.

 

No estoy cuestionando la profesionalidad de los participantes y sus plazas. Simplemente señalé un defecto en la comprobación de la suma de comprobación y también, la necesidad de una verificación adicional de la corrección de la disposición de los elementos en la nueva matriz.

Si todo esto es correcto, he obtenido merecidamente el penúltimo lugar.

En mi práctica, rara vez pienso en la velocidad de las operaciones específicas. Me preocupa más la concisión y la claridad de la solución. Me sorprendió que esta entrada

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

podría ser lento.

Pero si añadimos un criterio más de evaluación del algoritmo -la compacidad de la solución- probablemente esté en el primer lugar.

Si se combinan los dos criterios, velocidad y compresión, y se calcula la puntuación media del algoritmo, entonces ocupo un lugar más alto en la tabla.

La versión de Fedoseyev, sin embargo, está aún más condensada que la mía.
 
Реter Konow:

Sin embargo, si se añade otro criterio para evaluar los algoritmos, la compresión de la solución, probablemente esté en primer lugar.

Su versión del bucle principal:

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

y este es el de Fedoseyev:

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

Ambas variantes hacen lo mismo. ¿Quién es el más conciso?

 
Nikolai Semko:

Su versión del ciclo principal:

y este es el de Fedoseyev:

Ambos hacen lo mismo. ¿Quién es el más conciso?

A él. Lo tiene en lugar de...

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

Es más sucinto).

 
Реter Konow:

Lo ha hecho. Lo tiene en lugar de...

Esto es más sucinto).

Lo mismo ocurre con el compilador.

Simplemente tiene un montón de cosas innecesarias, por lo que funciona más lento que los demás (ni siquiera estoy considerando la primera opción del tema).

El código de Fedoseyev tiene una comprobación, una asignación y un incremento en una pasada del bucle (no cuento las comprobaciones e incrementos para la organización del bucle).

En cambio, tiene dos comprobaciones, una suma de dos variables, tres incrementos y una asignación.

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

Toda la esperanza es que el compilador optimice, de lo contrario ArraySize se ejecuta en cada iteración.

 
Aleksey Lebedev:

Toda la esperanza es que el compilador optimice, de lo contrario ArraySize se ejecuta en cada iteración.

Sí, el compilador parece comprobar que si el tamaño del array no cambia en el bucle, sustituye independientemente esta función por un valor y calcula esta función una sola vez.
En cualquier caso, si haces esto:

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

el tiempo de ejecución de la función no cambiará.

Así que para que sea más compacto tiene sentido escribirlo exactamente como lo hizo Peter :)
Pero estoy de acuerdo, personalmente a mí también me pican los ojos. Parece que la función será llamada cada vez.

 
Nikolai Semko:

Pero estoy de acuerdo, personalmente también me corta el rollo. Parece que la función será llamada cada vez.

En mi opinión, es mejor no dar al compilador la posibilidad de elegir)

Déjeme hacerle una pregunta,

if(count>6) { ArrayCopy

más de seis: ¿el valor se obtiene por intuición científica o hay una justificación?)
 
Aleksey Lebedev:

En mi opinión, es mejor no dar al compilador la posibilidad de elegir)

Déjame hacerte una pregunta,

if(count>6) { ArrayCopy

más de seis - el valor se obtiene por presentimiento científico, o ¿cuál es el razonamiento detrás de él?)

Sí, eso es exactamente. El método de la intuición científica. En realidad de 5 a 8 según mis observaciones. Puede automatizar este proceso autoajustando este número cada vez. Al fin y al cabo, este número puede ser diferente para distintos procesadores y sistemas.

Por ejemplo, si cambias todos los ArrayCopy y ArrayFill en la clase CCanvas por este principio, puedes obtener una buena ganancia en la velocidad del canvas.

Razón de la queja: