Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Nell'ultima variante ho fatto un controllo anche per questo. Chiunque ne abbia bisogno può usarlo.
Giusto. Ma come facciamo a sapere che gli algoritmi forniti non lasciano spazi vuoti? Il checksum non lo prova. E nemmeno il numero di elementi. Dopo tutto, la funzione conta gli elementi che c'erano prima che l'array fosse ridimensionato.
In quasi tutti i casi presentati questo viene implementato senza problemi inviando una query con NULL.
C'è un altro requisito per l'algoritmo - il corretto posizionamento degli elementi all'interno dell'array dopo la rimozione degli elementi non necessari. Questo controllo deve essere stato eseguito prima. Poi c'è un controllo della velocità.
Il codice spiega quali restituiscono cosa. Ci sono array mischiati. Ci sono in un'altra serie.
P.S. E solo per la cronaca. La mia funzione ha alcuni controlli, ma non utilizzati. Ma ha già tutto questo e molto di più.
Non sto mettendo in dubbio la professionalità dei partecipanti e dei loro posti. Ho semplicemente sottolineato un difetto nel controllo del checksum e anche la necessità di un'ulteriore verifica della correttezza della disposizione degli elementi nel nuovo array.
Se tutto questo è corretto, ho meritatamente ottenuto il penultimo posto.
Nella mia pratica, raramente penso alla velocità di operazioni specifiche. Sono più interessato alla concisione e alla chiarezza della soluzione. Mi ha sorpreso che questa voce
if(Arr[q]==val){deleted++; q--;}
potrebbe essere lento.
Ma se si aggiunge un altro criterio di valutazione dell'algoritmo - la compattezza della soluzione - sono probabilmente al primo posto.
Se si combinano i due criteri - Velocità e Compressione, e si calcola il punteggio medio dell'algoritmo, allora prendo un posto più alto nella tabella.
La versione di Fedoseyev, però, è ancora più condensata della mia.Tuttavia, se si aggiunge un altro criterio di valutazione degli algoritmi, la compressione delle soluzioni, sono probabilmente al primo posto.
La tua versione del ciclo principale:
e questo è quello di Fedoseyev:
Entrambe le varianti fanno la stessa cosa. Chi è il più conciso?
La tua versione del ciclo principale:
e questo è quello di Fedoseyev:
Entrambi fanno la stessa cosa. Chi è il più conciso?
Lui. Ce l'ha al posto di...
for(;i<sz;i++)
È più succinto).
Lo ha fatto. Ce l'ha al posto di...
Questo è più succinto)).
È lo stesso per il compilatore.
Semplicemente hai un sacco di cose inutili, quindi funziona più lentamente di tutti gli altri (non sto nemmeno considerando la prima opzione del topic).
Il codice di Fedoseyev ha un controllo, un' assegnazione e un incremento in un passaggio del ciclo (non conto i controlli e gli incrementi per l'organizzazione del ciclo).
Al contrario, avete due controlli, una somma di due variabili, tre incrementi e un' assegnazione.
Tutta la speranza è che il compilatore ottimizzi, altrimenti ArraySize viene eseguito ad ogni iterazione.
Tutta la speranza è che il compilatore ottimizzi, altrimenti ArraySize viene eseguito ad ogni iterazione.
Sì, il compilatore sembra controllare che se la dimensione dell'array non cambia nel ciclo, sostituisce indipendentemente questa funzione con un valore e calcola questa funzione solo una volta.
In ogni caso, se lo fai
il tempo di esecuzione della funzione non cambierà.
Quindi per una maggiore compattezza ha senso scriverlo esattamente come l'ha fatto Peter :)
Ma sono d'accordo, personalmente mi brucia anche gli occhi. Sembra che la funzione venga chiamata ogni volta.
Ma sono d'accordo, personalmente mi taglia fuori anche io. Sembra che la funzione venga chiamata ogni volta.
imho è meglio non dare al compilatore una scelta)
Mi permetta di farle una domanda,
se(count>6) { ArrayCopy
più di sei - il valore è ottenuto dalla sensazione scientifica, o c'è una giustificazione?)imho meglio non dare al compilatore una scelta)
Mi permetta di farle una domanda,
se(count>6) { ArrayCopy
più di sei - il valore è ottenuto da una sensazione scientifica di pancia, o qual è il ragionamento dietro?)Sì, è esattamente questo. Il metodo dell'istinto scientifico. In realtà da 5 a 8 secondo le mie osservazioni. Si può automatizzare questo processo autotunando questo numero ogni volta. Dopo tutto, questo numero può essere diverso per diversi processori e sistemi.
Per esempio, se cambiate tutti gli ArrayCopy e ArrayFill nella classe CCanvas secondo questo principio, potete ottenere un bel guadagno nella velocità della tela.