Biblioteca de classes genéricas - bugs, descrição, perguntas, recursos de uso e sugestões - página 17
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
Um grande exemplo teórico! Na prática, alguém já operou milhares de transacções?
p.s. não estou a tentar provar que é uma porcaria e ninguém precisa dela. Estou a tentar compreender o valor de uma negociação a sério. Eu não sou um teórico em geral, mas um puro praticante.
Brevemente sobre a implementação atual doCHashMap:
Primeiro, vamos descobrir o que éEntrada<TKey,TValue>.
Essencialmente é um Nodo como na CLinkedList que contém:
m_entries[] - array de "células" onde a chave e o valor acrescentado, hash_code, são colocados a seguir. O tamanho da matriz corresponde à Capacidade.
m_count - especifica o índice da primeira célula não utilizada em m_entries. O valor inicial é 0, crescendo para Capacidade, a seguir é a reconstrução de todas as matrizes com aumento de Capacidade e tamanho de todas as matrizes.
m_buckets[] - matriz de índice em m_entries[]. O valor padrão é -1. O tamanho da matriz corresponde à Capacidade.
Sem colisão, adicionando um valor único ao contentorCHashMap:
Sem colisões, obtenha valor por chave no recipienteCHashMap:
Resolução de colisões:
Colisão, obter valor por chave no recipienteCHashMap:
Remoção de um valor do recipienteCHashMap:
Reconstruir tabela de hash (processo para aumentar a capacidade) :
Fórum sobre negociação, sistemas de negociação automatizados e testes estratégicos
Biblioteca de classes genéricas - bugs, descrição, perguntas, uso e sugestões
Sergey Dzyublik, 2017.12.09 01:12
Conheci a implementação doCHashMap
Honestamente, eu gostei.
Há várias sugestões para possíveis melhorias:
1) Na minha humilde opinião, a implementação não contém uma seleção correta da capacidade - tanto o tamanho inicial 3 como os tamanhos subseqüentes quando se reconstrói a tabela de hash.
Sim, é correto que um número primo deve ser escolhido para a uniformidade da distribuição.
No entanto, a implementação do CPrimeGenerator não corresponde às expectativas e contém omissões de números primos.
O propósito de tal "gerador" é claro - fornecer um fator de incremento da ordem de 1,2 com geração automática de números primos.
No entanto, isto não é um coeficiente muito pequeno? Em C++ para vetores, o coeficiente é normalmente de 1,5-2,0, dependendo da biblioteca (pois afeta fortemente a complexidade média da operação).
A saída poderia ser um coeficiente constante seguido de arredondamento do número para prime através de uma pesquisa binária de uma lista de números primos.
E um tamanho inicial de 3 é muito pequeno, nós não vivemos no século passado.
2) Atualmente a tabela de hash é reconstruída (Redimensionada) somente quando a capacidade está 100% cheia (todos os m_entries[] estão preenchidos).
Devido a isso, pode haver uma quantidade significativa de colisões de chaves que não estão muito bem distribuídas.
Como opção, considere a introdução de um fator de preenchimento que reduz 100% pelo limite necessário para realizar a reconstrução de uma tabela de hash.
Na prática, alguém já operou em milhares de transacções?
Sim, milhões de chamadas históricas em um passe são praticadas por muitos.
Em Forts todos os primeiros.
Está claro.
Oenvio de ordens por algoritmo de balanço e a sua recolha para análise são coisas diferentes. Estes hashes não são necessários para envio, e também não são necessários para análise, porque são analisados de uma forma diferente.
Então, sem ofensa. Você também precisa de teoria.
Está claro.
O envio de ordens por algoritmo de balanço e a sua recolha mais tarde para análise são coisas diferentes. Você não precisa desses hashes para enviar, e também não precisa deles para análise, porque não é isso que está sendo analisado.
Então, sem ofensa. Também precisamos de teoria.
Eu não uso máquina de lavar louça, eu uso uma esponja.
Sem ofensa nenhuma. As máquinas de lavar louça são foleiras, para que servem.
Está claro.
O envio de ordens por algoritmo de balanço e sua posterior elevação para análise são coisas diferentes. Você não precisa desses hashes para submetê-los e não precisa deles para análise, já que analisamos outra coisa depois.
Então, sem ofensa. Também precisamos de teoria.
Que ressentimentos? Continue a escrever as suas muletas.
Brevemente sobre a implementação actual doCHashMap
Obrigado, eu vou usá-lo quando analisar o código fonte.
Que ressentimentos? Continue a escrever as suas muletas.
Obrigado, vou usá-lo quando analisar as fontes.
Omitida a verificação da existência da chave no contentor ao adicionar um novo par de valores de chave, executado primeiro.
Mas isso não é importante.
Por favor, conserte algo como isto em todo o genérico.