Limpar um conjunto de elementos definidos - página 21

 
Não sei como vai se comportar com
ArraySetAsSeries(array,true);
Na última variante também fiz um cheque para isso. Quem precisar, pode usá-lo.
Arquivos anexados:
 
Реter Konow:

Certo. Mas como sabemos que os algoritmos fornecidos não deixam nenhum espaço em branco? O checksum não o prova. Nem o número de elementos. Afinal, a função conta os elementos que estavam lá antes do redimensionamento da matriz.

Em quase todos os apresentados, isto é implementado sem problemas, enviando uma consulta com a NULL.

A etiqueta Konow:

Há outro requisito para o algoritmo - a colocação correta de itens dentro da matriz após a remoção de itens desnecessários. Esta verificação deve ter sido realizada primeiro. Depois há um controle de velocidade.

O código explica quais devolvem o quê. Há matrizes embaralhadas. Há em outra série.

P.S. E só para que conste. Minha função tem algumas verificações, mas não é utilizada. Mas já tem tudo isso e muito mais.

 

Não estou questionando o profissionalismo dos participantes e de seus lugares. Eu apenas apontei um defeito na verificação do checksum e também, a necessidade de verificação adicional da exatidão da disposição dos elementos da nova matriz.

Se tudo isso estiver correto, eu merecidamente consegui o penúltimo lugar.

Em minha prática, raramente penso na velocidade de operações específicas. Estou mais preocupado com a concisão e a clareza da solução. Foi uma surpresa para mim que esta entrada

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

poderia ser lento.

Mas se você acrescentar mais um critério de avaliação do algoritmo - compacidade da solução - eu provavelmente estarei em primeiro lugar.

Se você combinar os dois critérios - Velocidade e Compressão, e calcular a pontuação média do algoritmo, então eu ocupo um lugar mais alto na tabela.

A versão de Fedoseyev, porém, é ainda mais condensada do que a minha.
 
Реter Konow:

Entretanto, se você acrescentar outro critério para avaliar os algoritmos, Solution Compression, eu provavelmente estarei em primeiro lugar.

Sua versão do laço principal:

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

e esta é a de Fedoseyev:

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

Ambas as variantes fazem a mesma coisa. Quem tem a concisão mais concisa?

 
Nikolai Semko:

Sua versão do ciclo principal:

e esta é a de Fedoseyev:

Ambos fazem a mesma coisa. Quem tem o mais sucinto?

Ele. Ele tem isso em vez de...

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

É mais sucinto).

 
Реter Konow:

Ele tem. Ele tem isso em vez de...

Isto é mais sucinto)).

É o mesmo para o compilador.

Peter simplesmente tem muitas coisas desnecessárias, e é por isso que funciona mais lentamente do que outros (não estou nem mesmo considerando a primeira opção do tópico).

O código de Fedoseyev tem uma verificação, uma atribuição e um incremento em um loop pass (eu não conto verificações e incrementos para organização de loop).

Em contraste, você tem duas verificações, uma soma de duas variáveis, três incrementos e uma atribuição.

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

Toda a esperança é que o compilador otimize, caso contrário o ArraySize é executado a cada iteração.

 
Aleksey Lebedev:

Toda a esperança é que o compilador otimize, caso contrário o ArraySize é executado a cada iteração.

Sim, o compilador parece verificar que se o tamanho da matriz não mudar no laço, ele substitui independentemente esta função por um valor e calcula esta função apenas uma vez.
Em todo caso, se você fizer isso:

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

o tempo de execução da função não mudará.

Portanto, para uma maior compactação faz sentido escrevê-lo exatamente como Peter o fez :)
Mas concordo, pessoalmente, isso também me pica os olhos. Parece que a função será chamada a cada vez.

 
Nikolai Semko:

Mas concordo, pessoalmente, que isso também me corta. Parece que a função será chamada a cada vez.

imho é melhor não dar ao compilador uma escolha)

Deixe-me fazer-lhe uma pergunta,

if(contagem>6) { ArrayCopy

mais de seis - o valor obtido pela intuição científica, ou há uma justificativa?)
 
Aleksey Lebedev:

é melhor não dar ao compilador uma escolha)

Deixe-me fazer-lhe uma pergunta,

if(contagem>6) { ArrayCopy

mais de seis - o valor é obtido pela intuição científica, ou qual é o raciocínio por trás disso?)

Sim, é exatamente isso. O método do pressentimento científico. Na verdade, de 5 a 8 de acordo com minhas observações. Você pode automatizar este processo, autoajustando este número cada vez. Afinal de contas, este número pode ser diferente para diferentes processadores e sistemas.

Por exemplo, se você mudar todo o ArrayCopy e ArrayFill na classe CCanvas por este princípio, você pode obter um bom ganho em velocidade de lona.

Razão: