Biblioteca de classes genéricas - bugs, descrição, perguntas, recursos de uso e sugestões - página 4
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
Não estás a perceber o contexto. Se você andar por aí em vários fios e afirmar disparates sem provas, então sim, é um tiro direto para a proibição. Se você estiver disposto a apoiar suas reivindicações com o código fonte, você é bem-vindo. É por isso que Vladimir lhe deu um aviso, porque ele próprio adora o código fonte e às vezes até o exige. Olha através dos seus próprios fios para um exemplo.
Muito bem. Se você conseguir o código do Peter, será muito bom comparar seu desempenho.
Já dei uma vista de olhos. Está tudo escrito correctamente. Como já foi dito, a pesquisa de elementos no dicionário é feita em tempo médio O(1), ou seja, instantaneamente.
Isto é o que parece ilógico. Entre milhares de pedidos, é necessário um máximo de 10 verificações. Mas certamente não uma, em média. Há sempre uma dependência do tempo médio de busca em relação ao número de itens.
Não. O(n) é obtido devido a colisões de hash em casos muito raros. Estas são estimativas de complexidade para o algoritmo ideal. O número de colisões está relacionado com a sobrecarga de memória
No caso habitual não há essencialmente necessidade de procurar, porque ao calcular o hash já sabemos a localização do item que precisamos.
Tanto quanto me lembro, a escolha ideal do tamanho do dicionário de hash é o número de elementos esperados ao quadrado.
Um exemplo claro de colisões é o paradoxo do aniversário.
https://ru.wikipedia.org/wiki/
No caso normal não há essencialmente necessidade de procurar, porque ao calcular o hash já sabemos essencialmente a localização do item em questão.
Isso não soa plausível. Mas vou esperar por exemplos, depois vou ver as entranhas da implementação.
Por um lado é legal e por outro, lembramos que a MQL tem muitas coisas que estão ausentes em comparação com outras línguas: nem herança múltipla, foreach, yeild return, lamb, ...
É claro que o IEnumerable está fora de questão.
Então como podemos lidar com contentores C# sem IEnumerable?
Nós ainda temos os antigos algoritmos C++ e usamos interfaces em vez de ponteiros para funções.
No final, temos um hodgepodge de C# e C++.
O hodgepodge dos nomes é precisamente o resultado de nomes incorrectos que confundem as coisas.
Se eles fossem C++, tudo estaria claro.
PS E por que esta herança múltipla está ausente? Não posso escrevê-la em mql5?
Tanto quanto sei, não há problema.
É por isso que acabamos com C/C++. Se fizermos nomes normais. :)
Exatamente certo. Se houver um código do Peter, seria muito bom comparar o desempenho.
Estou sempre disposto a falar em linguagem de código. O autor poderia simplesmente oferecer-me uma prova e eu iria directo ao assunto.
Deixe o autor fornecer a tarefa e nós compararemos as nossas soluções por eficiência.
O tópico é fixo. Podes ver as coisas assim:
e você pode ver imediatamente que o tópico está preso:
Isso não soa plausível. Mas vou esperar por exemplos, depois vou ver as entranhas da implementação.
Hashes O(1) médio se o tamanho do dicionário para o número de elementos esperados permitir.
E depois depende de implementações de tratamento de colisões, pode ser através de uma lista, pode também ser uma sub-edge....
Um exemplo de colisão é o paradoxo do aniversário.
Eu li na wiki. O caso quando não se compreende de todo a lógica do raciocínio intuitivo.
O tópico é fixo. Podes ver as coisas assim:
e você pode ver imediatamente que o tópico está preso:
Obrigado. Vamos tentar tornar esta linha interessante. Eu já vejo a demanda pelo tema:))