Libreria di classi generiche - bug, descrizione, domande, caratteristiche d'uso e suggerimenti - pagina 9

 
Regex Konow:
Devo aggiungere che ho usato due funzioni e un array nella soluzione. Nessun puntatore o collegamento.

La tua soluzione non va bene. Avete già un array di 100x100x255, cioè 2.550.000 celle, riservato a 100 parole! E se avete 10 000 000 di parole, raggiungerete il limite di memoria sui sistemi a 32 bit. E se ci sono più di 100 collisioni? Quante parole iniziano con la lettera S e quante con la lettera P? - Ovviamente più di 100, quindi perché non dovremmo conservarli?

 
fxsaber:

Cioè devi trovare il giusto equilibrio tra la dimensione del dizionario (RAM) e la complessità computazionale della funzione hash (CPU) per ogni compito.

Proprio così. Scriverò di seguito sui requisiti della funzione hash.
 
fxsaber:

Dopo aver scritto tutto questo, mi è venuto in mente che non c'è nessun compito pratico per memorizzare i tick nel modo discusso nel thread. Sono ordinati per tempo e memorizzati in un semplice array.

È lo stesso per gli ordini/le offerte della storia. E, a giudicare da HistorySelect, sono memorizzati in un array in base al tempo. E credo che non ci sia nulla (nell'implementazione attuale) che permetta di cercare i record per biglietto o ID.

E tutto perché nel caso della storia nominata non è ragionevole fare una cosa del genere. La semplice matrice è sufficiente per la pratica.

Credo di sì.
 
fxsaber:

Per favore, scrivete in modo succinto, senza gli spoiler sotto forma di cappelli ed entità superflue.

Questo è un esempio di allenamento, quindi scusatemi, ma no. Voglio sottolineare, però, che questo è il modo in cui il codice è scritto nella versione da combattimento: il più conciso ed efficiente possibile (proprio come piace a voi). Negli esempi di formazione, il codice è scritto per tutti, è il più semplice e chiaro possibile, in modo che anche un utente non sofisticato possa capirlo.

S.W. Caps, ok, lo ripulirò.
 
Vasiliy Sokolov:

Tuttavia, vorrei sottolineare che questo è il modo in cui il codice è scritto nella versione da combattimento: il più conciso ed efficiente possibile (proprio come piace a voi).


In realtà, nei progetti, il codice è scritto secondo il "codice di condotta".
E tale variante, come nel caso difxsaber, non viene utilizzata:

bool Contains(string word)
{
   return words[word[0]-'a'] != NULL;
}

La ragione è banale: impossibilità di eseguire comodamente il debug.

 
Vasiliy Sokolov:

La tua soluzione non va bene. Avete già un array di 100x100x255, cioè 2.550.000 celle, riservato a 100 parole! E se avete 10 000 000 di parole, avrete raggiunto il limite di memoria sui sistemi a 32 bit. E se ci sono più di 100 collisioni? Quante parole iniziano con la lettera S e quante con la lettera P? - Sicuramente più di 100, quindi perché non dovremmo conservarli?


Sono tornato a studiare il codice suggerito daReTeg Konow.
Mi dispiace, ma è una completa spazzatura e una totale ignoranza degli argomenti di hash in generale, per non parlare delle tabelle di hash.
Perché creare questa bara su ruote quando si potrebbe andare su hubr e almeno familiarizzare con l'argomento degli hash.

Sì, non è un compito banale implementare la propria tabella hash in modo decente.
Ma nei codici proposti, non c'è nemmeno una questione di comprensione.

 

Amici. Vedo che il thread è diventato silenzioso.

Non voglio disturbare la discussione, quindi mi ritiro volontariamente.

Ci possono essere molte cose interessanti nella biblioteca.

Sentitevi liberi di discutere.

(La mia soluzione è in ogni caso peggiore, perché è 3,2 volte più lenta).

 
Vasiliy Sokolov:

La tua soluzione non va bene. Avete già un array di 100x100x255, cioè 2.550.000 celle, riservato a 100 parole! E se avete 10 000 000 di parole, avrete raggiunto il limite di memoria sui sistemi a 32 bit. E se ci sono più di 100 collisioni? Quante parole iniziano con la lettera S e quante con la lettera P? - Ovviamente più di 100, quindi perché non dovremmo conservarli?

Ladimensione dell'array può essere facilmente modificata per adattarsi alla dimensione del dizionario.

Non considero varianti infinite.

 
Sergey Dzyublik:


Sono tornato a studiare il codice suggerito daRetag Konow.
Mi dispiace, ma è una totale spazzatura e un totale fraintendimento dell'argomento degli hash in generale, per non parlare delle tabelle hash.
Perché creare questa bara su ruote quando si potrebbe andare su hubr e almeno familiarizzare con l'argomento degli hash.

Sì, non è un compito banale implementare la propria tabella hash in modo decente.
Ma nei codici offerti non si discute nemmeno di una qualsiasi comprensione.

Questo codice è l'inizio. Nessuno vi impedisce un ulteriore sviluppo.
 
Vasiliy Sokolov:

La tua soluzione non va bene. Avete già un array di 100x100x255, cioè 2.550.000 celle, riservato a 100 parole! E se avete 10 000 000 di parole, avrete raggiunto il limite di memoria sui sistemi a 32 bit. E se ci sono più di 100 collisioni? Quante parole iniziano con la lettera S e quante con la lettera P? - Ovviamente più di 100, quindi perché non dovremmo conservarli?

Nella mia versione è improbabile che ci siano più di 100 collisioni. Riesci a pensare a più di 100 parole che iniziano con una lettera e hanno lo stesso numero di lettere?

(tranne le varianti "testo 1", "testo 2", "testo 3", "testo 4", "testo 5"...)