Um pouco surpreendido :) Pensei em partilhar e fazer uma pergunta NÃO retórica. - página 21
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
É fácil saltar de uma declaração falhada para outra.
Quando se tem um processador com tipos de dados racionais e quando outro conjunto de comandos SSExxx pode lidar com eles mais rapidamente do que o dobro, então pode-se trazer números racionais para a discussão sobre a aceleração dos cálculos. Quando publicar testes de cálculo de SMA com métodos diferentes e mostrar que ganha o dobro, então será um discurso de prática.
Entretanto, a afirmação original sobre a aceleração dos cálculos matemáticos reais através da mudança para números inteiros falhou.
Tu o quê?! Eu não saltei NADA. Se ler apenas metade. Ai de mim. Já falei sobre fracções racionais cerca de vinte vezes. Mas até eu salientar que se trata de fracções, ninguém compreendeu. :) Digo-vos, é ridículo. Ai de mim. :(
:) Falha - estava a falar de números inteiros e do conceito de POINT, e um ponto é sempre o denominador. 13000 pontos se um ponto for igual a 10000 - então o valor é = 13000/10000 = 1,3 :)
O que é que estás a fazer?! Eu não saltei para lado nenhum. Se ler apenas metade. Lamento. Já vos falei de cisternas racionais vinte vezes. Mas até eu salientar que se trata de fracções, ninguém compreendeu. :) Digo-vos, é ridículo. Ai de mim. :(
:) Falha - estava a falar de números inteiros e do conceito de POINT, e um ponto é sempre o denominador. 13000 pontos se um ponto for igual a 10000 - então o valor é = 13000/10000 = 1,3 :)
Propõe-se processar três longs de 8 bytes (parte inteira + denominador + numerador) em vez do dobro de 8 bytes. E se começar a cortar os longos em algo mais curto, obterá um transbordamento em cálculos bastante adequados.
Mesmo três polegadas e essas são mais do que uma tomada.
Propõe-se processar três longs de 8 bytes (parte inteira + denominador + numerador) em vez do dobro de 8 bytes. E se começar a cortar os longos para algo mais curto, obterá um transbordamento em cálculos bastante adequados.
Escolheu a pior forma de a implementar. Tendo em conta o que me disse, não faz sentido. Qual de nós sabe melhor?
Há um número em quilómetros - é int32 E não precisa de mais nada. Só não é preciso somá-lo com um valor noutra dimensão. :) Se quiser mais precisão do que quilómetros, vá a nanómetros. :) E armazená-los como um número inteiro. :)
TheXpert:
E segundo, duvido muito que a aritmética com o dobro seja mais lenta do que com números racionais.
Wapchet mais lento. Mas ele forneceu-nos uma ligação errada.
1. A implementação em BOOST normaliza os números das rações em cada operação com eles. Isto não tem de ser feito em todos, pois é caro. É melhor fazê-lo apenas quando existe uma ameaça real de transbordamento de denominador.
2. A redução para um denominador comum (mais precisamente, o cálculo do maior divisor comum) não é aí feita pelo algoritmo mais rápido. De longe, o mais rápido.
Com correcção, ele está certo sobre a velocidade dos números racionais.
Tê-los-ia em mql, se estivessem disponíveis operações aritméticas de recarga. Sem ela a minha sintaxe seria muito entediante (funcional), por isso esqueça... С++ :-)
--
Mas seria muito fixe se houvesse apoio ao nível do processador.
Wapchetta mais lento. Apenas a ligação que ele deu estava errada.
1. A implementação em BOOST normaliza os números de ração em cada operação sobre eles. Não é necessário fazê-lo em todos, porque é caro. É melhor fazê-lo apenas quando existe uma ameaça real de transbordamento de denominador.
2. A redução para um denominador comum (mais precisamente, o cálculo do maior divisor comum) não é aí feita pelo algoritmo mais rápido. De longe, há um mais rápido.
Dito isto, ele está certo sobre a velocidade dos números de rati.
Tê-los-ia em mql, se as operações aritméticas de recarga estivessem disponíveis. Sem ela ficaria com uma sintaxe muito entediante (funcional), por isso esqueça... С++ :-)
--
Mas seria muito fixe se houvesse apoio a nível de CPU...
A própria aritmética é mais lenta porque ainda temos de lidar com o ponto flutuante (isto é, se compararmos a aritmética pura dupla e longa), se convertermos a dupla em aritmética inteira perdemos. Só o cálculo de NOD recorrente exigiria operações de registo(N), para não mencionar o facto de que cada operação de multiplicação exigiria se fosse necessário verificar a existência de transbordo. Depois mais 4 divisões (duas por NOD e para extrair a parte inteira e o resto fracionário).
Além disso, ainda precisaria de atribuir mais memória para armazenar todo este disparate do que precisaria para a tomada.
Wapchet mais lento. Apenas a ligação que ele citou foi infeliz.
Comprovação? É certamente mais autoritário aos meus olhos do que o escritor original, mas essa é uma afirmação forte.
Por conseguinte, gostaria de ver testes comparativos.
A própria aritmética é mais lenta porque ainda tem de lidar com o ponto flutuante (isto é, se compararmos a aritmética pura dupla e longa),
1. se converter as duplas em aritmética inteira, perde.
2. O cálculo recorrente do NOD, por si só, exigiria operações de log(N), para não mencionar o facto de
3. cada operação de multiplicação requererá se para verificar a existência de transbordo.
4. Depois mais 4 divisões (duas por NOD e para extrair a parte inteira e o resto fracionário).
5. Além de tudo isto, terá ainda de atribuir mais memória para armazenar todo este disparate do que é necessário para a tomada.
1. esta é uma operação única para cada tomada. A perda é insignificante, então os ganhos são sólidos. :) Presumo que o quociente original é logarítmico uma vez e convertido em representação inteira.
2. isto é correcto. Embora seja rápido, porque existe um algoritmo rápido que utiliza turnos de bits.
3. não mais do que verificações de transbordo.
4. a parte inteira não precisa de ser atribuída de forma alguma. a fracção é armazenada como um par de longs. e se possível, como um par de ints.
5. exactamente a mesma quantidade se armazenada como um par de longs, e metade da quantidade no caso de haver ints suficientes (depende dos requisitos do algoritmo).
Se considerarmos que o consumidor de memória principal é uma citação, então com representação inteira, o ganho no espaço é inegável.
Embora o ponto principal não seja a poupança de memória, mas sim a aceleração. Isto é muito mais importante.
--
O problema com o Académico não é que ele esteja errado. É que ele está a fazer os outros parecerem errados.
É isso que irrita os presentes e rejeita ideias saudáveis. Juntamente com a água suja... :(
Por conseguinte, gostaria de ver testes comparativos.
Vou tentar. Em mql5, se chegar a isso... :)
Só preciso de algum tempo. Eu teria de escrever uma biblioteca.
Vou tentar. Em mql5, se chegar a isso... :)
Para quê? C++ é aceite.
O problema com o académico não é que ele esteja errado. É que ele está a fazer os outros parecerem errados.
O problema é que ele pensa que é mais esperto do que os outros e tenta constantemente fazer de outra pessoa um tolo.
E ele faz asneira. Em alguns lugares, muito.
O problema com o académico não é que ele esteja errado. É que ele faz os outros parecerem errados.
Isto é o que irrita os presentes e rejeita ideias saudáveis. Juntamente com a água suja... :(
Não me meto na cabeça de ninguém. Mas eu estou invertido. :) Quem tem pedido conselhos sobre "devo ir com o tema"? :)
E depois eu é que sou o único que é o único... :) Bem, não venhas até mim.
Qual é a diferença em geral? O que há para discutir? IMHO - tudo se mantém ao mesmo nível embrionário que era. Portanto, não há problema comigo - é como se eu não existisse. :)