Libreria di classi generiche - bug, descrizione, domande, caratteristiche d'uso e suggerimenti - pagina 9
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
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?
Cioè devi trovare il giusto equilibrio tra la dimensione del dizionario (RAM) e la complessità computazionale della funzione hash (CPU) per ogni compito.
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.
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ò.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:
La ragione è banale: impossibilità di eseguire comodamente il debug.
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).
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.
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.
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"...)