Biblioteca de clases genéricas - errores, descripción, preguntas, características de uso y sugerencias - página 4
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
No estás entendiendo el contexto. Si vas por varios hilos y afirmas tonterías sin pruebas, entonces sí, eso es un camino directo al baneo. Si estás dispuesto a respaldar tus afirmaciones con el código fuente, eres bienvenido. Por eso Vladimir te avisó, porque a él mismo le encanta el código fuente y a veces incluso lo exige. Mira sus propios hilos para ver un ejemplo.
Muy bien. Si consigues el código de Peter será muy bueno comparar su rendimiento.
Lo he mirado. Todo está escrito correctamente. Como ya se ha dicho, la búsqueda de elementos en el diccionario se realiza en un tiempo medio O(1), es decir, instantáneamente.
Esto es lo que suena ilógico. Entre miles de pedidos, se necesita un máximo de 10 controles. Pero desde luego no uno de media. El tiempo medio de búsqueda depende siempre del número de elementos.
No. Se obtiene O(n) debido a las colisiones de hash en casos muy raros. Son estimaciones de la complejidad del algoritmo óptimo. El número de colisiones está relacionado con la sobrecarga de memoria
En el caso habitual no es necesario buscar, porque al calcular el hash ya sabemos la ubicación del elemento que necesitamos.
Por lo que recuerdo, la elección óptima del tamaño del diccionario hash es el número de elementos esperados al cuadrado.
Un claro ejemplo de colisiones es la paradoja del cumpleaños.
https://ru.wikipedia.org/wiki/
En el caso normal, no hay necesidad de buscar, porque al calcular el hash ya sabemos esencialmente la ubicación del elemento en cuestión.
Eso no suena plausible. Pero esperaré a los ejemplos, luego veré las tripas de la implementación.
Por un lado mola y por otro recordamos que MQL tiene un montón de cosas que están ausentes en comparación con otros lenguajes: ni herencia múltiple, foreach, yeild return, lamb, ...
Está claro que IEnumerable está fuera de lugar.
Entonces, ¿cómo podemos manejar los contenedores de C# sin IEnumerable?
Todavía tenemos los viejos algoritmos de C++ y utilizamos interfaces en lugar de punteros a funciones.
Al final obtenemos un batiburrillo de C# y C++.
La mezcolanza de nombres es precisamente el resultado de nombres incorrectos que confunden las cosas.
Si fueran C++, todo estaría claro.
P.D. ¿Y por qué no existe esta herencia múltiple? ¿No puedo escribirlo así en mql5?
Por lo que tengo entendido, no hay problema.
Por eso acabamos con C/C++. Si hacemos nombres normales. :)
Exactamente. Si hay un código de Peter, sería muy bueno para comparar el rendimiento.
Siempre estoy dispuesto a hablar en lenguaje de códigos. El autor podría simplemente ofrecerme una prueba y yo iría directamente al grano.
Deje que el autor proporcione la tarea y compararemos nuestras soluciones por eficiencia.
El tema está arreglado. Puedes verlo así:
y podrás ver inmediatamente que el tema está anclado:
Eso no suena plausible. Pero esperaré a los ejemplos, luego veré las tripas de la implementación.
Los hashes tienen un promedio de O(1) si el tamaño del diccionario al número de elementos esperados lo permite.
Y luego depende de las implementaciones de manejo de colisiones, podría ser a través de una lista, también podría ser un sub-hedge....
Un ejemplo de colisión es la paradoja del cumpleaños.
Lo he leído en la wiki. El caso es que no entiendes en absoluto la lógica del razonamiento intuitivo.
El tema está arreglado. Puedes verlo así:
y podrás ver inmediatamente que el tema está anclado:
Gracias. Intentaremos que este hilo sea interesante. Ya veo la demanda del tema:))