Biblioteca de clases genéricas - errores, descripción, preguntas, características de uso y sugerencias - página 9
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Debo añadir que he utilizado dos funciones y un array en la solución. No hay punteros ni conexiones.
Su solución no es buena. Ya tienes una matriz de 100x100x255, es decir, 2.550.000 celdas, reservadas para 100 palabras. Y si tiene 10 000 000 de palabras, habrá alcanzado el límite de memoria en los sistemas de 32 bits. ¿Y si hay más de 100 colisiones? ¿Cuántas palabras comienzan con la letra S y cuántas con la letra P? - Evidentemente, más de 100, así que ¿por qué no íbamos a almacenarlos?
Es decir, hay que encontrar el equilibrio adecuado entre el tamaño del diccionario (RAM) y la complejidad computacional de la función hash (CPU) para cada tarea.
Después de escribir todo esto, se me ocurrió que no hay ninguna tarea práctica para almacenar las garrapatas en la forma discutida en el hilo. Se ordenan por tiempo y se almacenan en un simple array.
Lo mismo ocurre con los Pedidos/Ofertas de Historia. Y, a juzgar por HistorySelect, se almacenan en una matriz por tiempo. Y creo que no hay nada (en la implementación actual) que permita buscar registros por ticket o por ID.
Y todo porque en el caso de la historia nombrada no es razonable hacer algo así. Una matriz simple es suficiente para practicar.
Por favor, escriba de forma concisa, sin spoilers en forma de mayúsculas o entidades superfluas.
Este es un ejemplo de entrenamiento, así que discúlpame, pero no. No obstante, señalaré que así es como se escribe el código en la versión de combate: de la forma más concisa y eficiente posible (como a ti te gusta). En los ejemplos de formación, el código está escrito para todo el mundo, es lo más sencillo y claro posible, de modo que incluso un usuario poco sofisticado podría entenderlo.
s.w. Caps, ok, lo limpiaré.Sin embargo, me gustaría señalar que así es como se escribe el código en la versión de combate: de la forma más concisa y eficiente posible (como a ti te gusta).
En realidad, en los proyectos, el código se escribe según el "código de conducta".
Y dicha variante, como en el casode fxsaber, no se utiliza:
La razón es banal: imposibilidad de depurar convenientemente.
Su solución no es buena. Ya tienes una matriz de 100x100x255, es decir, 2.550.000 celdas, reservadas para 100 palabras. Y si tiene 10 000 000 de palabras, habrá alcanzado el límite de memoria en los sistemas de 32 bits. ¿Y si hay más de 100 colisiones? ¿Cuántas palabras comienzan con la letra S y cuántas con la letra P? - Sin duda, más de 100, así que ¿por qué no íbamos a almacenarlos?
He vuelto a estudiar el código sugerido porReTeg Konow.
Lo siento, pero es una completa basura y un desconocimiento total de los temas de hash en general, por no hablar de las tablas de hash.
Por qué crear este ataúd con ruedas cuando podrías ir a hubr y al menos familiarizarte con el tema de los hashes.
Sí, no es una tarea trivial implementar tu propia tabla hash de forma decente.
Pero en los códigos propuestos, ni siquiera se habla de ningún tipo de entendimiento.
Amigos. Veo que el hilo se ha silenciado.
No quiero perturbar la discusión, así que me retiro voluntariamente.
Puede haber muchas cosas interesantes en la biblioteca.
Siéntase libre de discutir.
(Mi solución es en cualquier caso peor, porque es 3,2 veces más lenta).
Su solución no es buena. Ya tienes una matriz de 100x100x255, es decir, 2.550.000 celdas, reservadas para 100 palabras. Y si tiene 10 000 000 de palabras, habrá alcanzado el límite de memoria en los sistemas de 32 bits. ¿Y si hay más de 100 colisiones? ¿Cuántas palabras comienzan con la letra S y cuántas con la letra P? - Evidentemente, más de 100, así que ¿por qué no íbamos a almacenarlos?
El tamaño de la matriz puede cambiarse fácilmente para adaptarse al tamaño del diccionario.
No considero un sinfín de variantes.
Volví a estudiar el código sugerido deRetag Konow code.
Lo siento, pero es una absoluta basura y una total incomprensión del tema de los hashes en general, por no hablar de las tablas hash.
Por qué crear este ataúd con ruedas cuando podrías ir a hubr y al menos familiarizarte con el tema de los hashes.
Sí, no es una tarea trivial implementar tu propia tabla hash de forma decente.
Pero en los códigos ofrecidos no hay ni siquiera una cuestión de entendimiento.
Su solución no es buena. Ya tienes una matriz de 100x100x255, es decir, 2.550.000 celdas, reservadas para 100 palabras. Y si tiene 10 000 000 de palabras, habrá alcanzado el límite de memoria en los sistemas de 32 bits. ¿Y si hay más de 100 colisiones? ¿Cuántas palabras comienzan con la letra S y cuántas con la letra P? - Evidentemente, más de 100, así que ¿por qué no íbamos a almacenarlos?
En mi versión es poco probable que haya más de 100 colisiones. ¿Puedes pensar en más de 100 palabras que empiecen por una letra y tengan el mismo número de letras?
(excepto las variantes "texto 1", "texto 2", "texto 3", "texto 4", "texto 5"...)