Biblioteca de classes genéricas - bugs, descrição, perguntas, recursos de uso e sugestões - página 9
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Devo acrescentar que usei duas funções e uma matriz na solução. Sem indicações ou ligações.
A sua solução não é boa. Você já tem uma matriz de 100x100x255, ou seja, 2.550.000 células, reservada para 100 palavras! E se tiver 10 000 000 de palavras, terá atingido o limite de memória em sistemas de 32 bits. E se houver mais de 100 colisões? Quantas palavras começam com a letra S, e quantas começam com a letra P? - Obviamente mais de 100, então porque não os devemos guardar?
Ou seja, você tem que encontrar o equilíbrio certo entre o tamanho do dicionário (RAM) e a complexidade computacional da função hash (CPU) para cada tarefa.
Depois de escrever tudo isso, ocorreu-me que não há tarefa prática para armazenar carrapatos na forma discutida no fio. Eles são ordenados pelo tempo e armazenados em uma matriz simples.
O mesmo se passa com os Pedidos/Negócios de História. E, a julgar pela HistorySelect, eles são armazenados em um array pelo tempo. E eu acho que não há nada (na implementação actual) que permita procurar registos por bilhete ou identificação.
E tudo porque, no caso da história nomeada, não é razoável fazer algo assim. Uma matriz simples é suficiente para a prática.
Por favor, escreva sucintamente, sem os spoilers na forma de chapéus e entidades supérfluas.
Isto é um exemplo de treino, por isso desculpem-me, mas não. Vou salientar, no entanto, que é assim que o código é escrito na versão de combate: da forma mais concisa e eficiente possível (da maneira que você gosta). Em exemplos de treinamento, o código é escrito para todos, é tão simples e claro quanto possível, de modo que até mesmo um usuário pouco sofisticado poderia entendê-lo.
S.W. Caps, ok, eu limpo isso.No entanto, gostaria de salientar que é assim que o código é escrito na versão de combate: da forma mais concisa e eficiente possível (da maneira que você gosta).
Na realidade, nos projetos, o código é escrito de acordo com o "código de conduta".
E tal variante, como no casodo fxsaber, não é utilizada:
A razão é banal - impossibilidade de depurar convenientemente.
A sua solução não é boa. Você já tem um conjunto de 100x100x255, ou seja, 2.550.000 células, reservadas para 100 palavras! E se tiver 10 000 000 de palavras, terá atingido o limite de memória em sistemas de 32 bits. E se houver mais de 100 colisões? Quantas palavras começam com a letra S, e quantas começam com a letra P? - Definitivamente mais de 100, então porque não os devemos guardar?
Eu voltei para estudar o código sugerido peloReTeg Konow.
Desculpe, mas é um completo lixo e total ignorância de temas de hash em geral, para não mencionar as tabelas de hash.
Porquê criar este caixão sobre rodas quando podias ir ao hubr e pelo menos familiarizar-te com o assunto dos hashes.
Sim, não é uma tarefa trivial implementar decentemente a sua própria mesa de hash.
Mas nos códigos propostos, não há sequer uma questão de qualquer compreensão.
Amigos. Vejo que o fio ficou quieto.
Não quero perturbar a discussão, por isso estou a retirar-me voluntariamente.
Pode haver muitas coisas interessantes na biblioteca.
Fique à vontade para discutir.
(A minha solução é de qualquer forma pior, porque é 3,2 vezes mais lenta).
A sua solução não é boa. Você já tem uma matriz de 100x100x255, ou seja, 2.550.000 células, reservada para 100 palavras! E se tiver 10 000 000 de palavras, terá atingido o limite de memória em sistemas de 32 bits. E se houver mais de 100 colisões? Quantas palavras começam com a letra S, e quantas começam com a letra P? - Obviamente mais de 100, então porque não os devemos guardar?
O tamanho da matriz pode ser facilmente alterado para se adequar ao tamanho do dicionário.
Eu não considero variantes infinitas.
Voltou para estudar o código sugerido pelo código daRetag Konow.
Desculpe, mas é um grande disparate e uma total incompreensão do tema dos hashes em geral, para não falar das mesas de hash.
Porquê criar este caixão sobre rodas quando podias ir ao hubr e pelo menos familiarizar-te com o assunto dos hashes.
Sim, não é uma tarefa trivial implementar decentemente a sua própria mesa de hash.
Mas em códigos oferecidos não é sequer uma questão de compreensão.
A sua solução não é boa. Você já tem uma matriz de 100x100x255, ou seja, 2.550.000 células, reservada para 100 palavras! E se tiver 10 000 000 de palavras, terá atingido o limite de memória em sistemas de 32 bits. E se houver mais de 100 colisões? Quantas palavras começam com a letra S, e quantas começam com a letra P? - Obviamente mais de 100, então porque não os devemos guardar?
Na minha versão é improvável que haja mais de 100 colisões. Você consegue pensar em mais de 100 palavras que começam com uma letra e têm o mesmo número de letras?
(excepto para as variantes "texto 1", "texto 2", "texto 3", "texto 4", "texto 5"...)