Algoritmos, métodos de solução, comparação de seu desempenho - página 7
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
bem, em poucas palavras, um fio de um personagem é umchar com algum código de 0 a 255 e pesa 1 byte. e é alocada apenas memória suficiente para ter 256 valores, 257 não caberão lá, ele voltará para o primeiro.
Em qualquer página, cada caractere é um número de 0 a 255. então pegamos o número 10000000 - ele pesa 4 bytes, convertemo-lo para a string "10000000" então para cada caractere alocamos memória como para um gráfico individual de 0 a 255... 8 bytes no total. Não há economia de memória em nenhum lugar.
Estou entendendo o que você quer dizer.
Precisamos calcular com precisão o consumo de memória para esta solução.
Você pode começar a escrever a segunda linha. Depois a terceira e assim por diante... :)
p.s. Oh sim, você tem mais um erro. Se MathRand na terceira chamada retornar, por exemplo, o número 1000 e escrever _3_1000_, que tipo de medge será encontrado para uma transação com o número de pedido 1000?A questão é que o MathRand é necessário apenas para simular números de medigee.
Os números Medjic são definidos pelo usuário, e podem ultrapassar um valor inferior a 100.000 (digamos).
Entretanto, pode haver um erro dentro do exemplo dado. Você está correto.
Obrigado pela observação. Uma solução completa deve levar isso em conta.
Entendo seu ponto de vista.
Precisamos calcular com precisão a quantidade de memória consumida nesta solução.
Isto também desperdiça muitos recursos em referências internas, porque o acesso a cada caractere de corda é o mesmo que o acesso à matriz[x] char[x]. Neste caso, um link é o acesso a um determinado elemento de matriz. E você vai passar por enormes pilhas delas lá. A implementação com int seria muitas vezes mais fácil e mais rápida de entender...
Quanto à limitação do comprimento das cordas, ela geralmente depende do tamanho máximo da matriz [x] - ela também tem seu próprio limite máximo.
O homem realmente não se dá conta da extensão de sua própria estupidez.
O efeito Dunning-Kruger em ação.
Tudo bem, uma pessoa só precisa de uma linguagem não dactilografada e sem problemas))
embora ainda haja uma diferença na velocidadep.s. Oh sim, você tem mais um erro. Se MathRand na terceira chamada retornar por exemplo número 1000 e escrever _3_1000_, qual magik será encontrado para lidar com o número ordinal 1000?
Isto também desperdiça muitos recursos em referências internas, porque acessar cada caractere de string é o mesmo que acessar o char[x] de um array. Neste caso, um link é o acesso a um determinado elemento de matriz. E você vai passar por enormes pilhas delas lá. A implementação com int seria muitas vezes mais fácil e mais rápida de entender...
Quanto à limitação do comprimento das cordas, ela geralmente depende da limitação de tamanho máximo no conjunto char[x] - ela tem seu próprio limite máximo, assim como outros.
Não podemos implementá-lo com int, porque não sabemos antecipadamente o número de transações futuras. Temos que adivinhar ou mudar o tamanho da matriz em cada comércio e reescrever os dados para frente e para trás.
De que outra forma podemos fazer isso?
A velocidade da minha solução é uma loucura.
A memória é consumida, mas desconhece-se quão ineficiente é. Precisamos descobrir com certeza.
Ele "pensará" um pouco mais e resolverá este problema: ele colocará um sublinhado antes da transação, e um símbolo diferente diante do mágico :)
Gostaria de ressaltar que, ao contrário de todos aqui, Peter provavelmente tem a maior paciência - e uma vontade de escrever código monótono. Não há outra maneira de explicar como ele conseguiu escrever tanto
Não podemos implementar com int, porque não sabemos antecipadamente o número de futuros negócios. Ou temos que adivinhar, ou temos que mudar o tamanho da matriz e sobregravar os dados para frente e para trás em cada comércio.
De que outra forma podemos fazer isso?
A velocidade da minha solução é uma loucura.
A memória é consumida, mas desconhece-se quão ineficiente é. Precisamos descobrir com certeza.
Há apenas duas variantes de cadeia ou ela tem um tamanho máximo (em reserva), ou também a memória é alocada e, no seu caso, durante o processo de adição, ela é alocada cada vez.... Portanto, é o mesmo que mudar o tamanho de uma matriz int. 1em1 bem talvez leve 10% mais tempo para int alocar memória do que para string alocar memória para 1 caracter, se você comparar mais caracteres então eu acho que int ganha