Biblioteca de classes genéricas - bugs, descrição, perguntas, recursos de uso e sugestões - página 4

 
Vasiliy Sokolov:

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.

 
Vasiliy Sokolov:
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.

 
Combinador:

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/

 
Combinador:

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.

 
Sergey Dzyublik:

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?

class A : public B
  {
  }

Tanto quanto sei, não há problema.


É por isso que acabamos com C/C++. Se fizermos nomes normais. :)

 
Vladimir Karputov:

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:

Passo 1: Clique em "Discussão geral".

e você pode ver imediatamente que o tópico está preso:

Passo 2: Veja se o tópico é fixo

 
fxsaber:

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....


 
Sergey Dzyublik:

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.

 
Vladimir Karputov:

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:))