Implementações alternativas de funções/abordagens padrão - página 7

[Nikolai Semko]

pavlick_:

Porque converter o dobro para o inteiro (desta forma) é um código de merda. A rodada com amigos não foi projetada para obter o tipo inteiro do tipo flutuante.

Quem impede que você mude o tipo de função para o dobro.

E controle seu discurso, por favor.

[pavlick_]

Nikolai Semko:
Bem, quem está impedindo que você mude o tipo de função para o dobro.

E controle seu discurso, por favor.

Sem ofensa. Há todos os tipos de cerveja, de hortelã, de hortelã para conversão em inteiro. Eles não apareceram apenas por uma razão quando é muito mais fácil fazer por muito tempo (duplo). A conversão de flutuante em inteiro é um erro conceitual.

[Nikolai Semko]

pavlick_:

Sem ofensa. Há todos os tipos de cerveja, de hortelã, de hortelã para converter em inteiro. Eles foram inventados por uma razão, quando você pode fazer muito mais fácil do que longo(duplo). A conversão de flutuante em inteiro é um erro conceitual.

Oh, você está fora do circuito...

[pavlick_]

Nikolai Semko:
Oh, você está apenas fora de contato...

OK, a UB está em suas mãos.

[Nikolai Semko]

fxsaber:
Interpretação ambígua, então. Decidiu produzir o tempo de ciclo, não o tempo médio de uma chamada de função.

O ganho é entre 3 e 8 vezes.

Talvez o método de cálculo do tempo para o funcionamento não seja impecável, mas é bastante objetivo. Mas se alguém sugerir um método melhor e mais imparcial, isso seria bom.

Eu o mudei para digitar o dobro para uma analogia completa.

double Ceil (double x) { return double((x-(long)x>0)?(long)x+1:(long)x);}
double Round(double x) { return double((x>0)?(long)(x+0.5):(long)(x-0.5));}
double Floor(double x) { return double((x>0)?(long)x:((long)x-x>0)?(long)x-1:(long)x);} 

2018.08.25 22:16:01.309 TestRound (EURUSD,M10)  Время цикла без округления = 1.315 наносекунд, сумма = 5249993749.98145962
2018.08.25 22:16:01.309 TestRound (EURUSD,M10)  Время выполнения функции sqrt = 0.628 наносекунд, сумма = 81969849.90928555  // даже квадратный корень вычисляется в несколько раз быстрее чем штатные функции округления
2018.08.25 22:16:01.313 TestRound (EURUSD,M10)  Время выполнения функции ceil =  2.037 наносекунд, Контрольная сумма = 5250492895.0
2018.08.25 22:16:01.315 TestRound (EURUSD,M10)  Время выполнения функции Ceil =  0.587 наносекунд, Контрольная сумма = 5250492895.0
2018.08.25 22:16:01.318 TestRound (EURUSD,M10)  Время выполнения функции floor = 2.247 наносекунд, Контрольная сумма = 5249492896.0
2018.08.25 22:16:01.320 TestRound (EURUSD,M10)  Время выполнения функции Floor = 0.385 наносекунд, Контрольная сумма = 5249492896.0
2018.08.25 22:16:01.323 TestRound (EURUSD,M10)  Время выполнения функции round = 1.610 наносекунд, Контрольная сумма = 5249992896.0
2018.08.25 22:16:01.324 TestRound (EURUSD,M10)  Время выполнения функции Round = 0.181 наносекунд, Контрольная сумма = 5249992896.0

Sugiro que os desenvolvedores usem este algoritmo nas funções regulares.

[pavlick_]

)). Isto pode ter um lugar somente em artesanato pessoal com conhecimento preciso da faixa de valores, mas não em bibliotecas std. As funções embutidas não são escritas por tolos, não pense que você é o mais inteligente. Aqui está um amigo que também escreve um comportamento indefinido e não especificado e depois se surpreende que não funcione dessa maneira https://www.linux.org.ru/forum/development/14422428#comments. Todas essas economias de vários nanossegundos não serão visíveis nem mesmo em algoritmo real (não em loop nu).

[Georgiy Merts]

Também não entendo porque as funções de arredondamento devem retornar em dobro. Na minha opinião, esse é o ponto de arredondamento - você precisa definir como obter um número inteiro a partir de um valor flutuante.

Que "erro conceitual" de conversão também não é muito claro para mim.

[Renat Fatkhullin]

Georgiy Merts:

Também não entendo porque as funções de arredondamento devem retornar em dobro. Na minha opinião, esse é o ponto de arredondamento - você precisa definir como obter um número inteiro a partir de um valor flutuante.

Que "erro conceitual" de conversão também não é muito claro para mim.

Pense no que você obtém fora de um número inteiro.

[Реter Konow]

fxsaber:

NormalizeDuplo

O resultado é 1123275 e 1666643 em favor do MyNormalizeDouble (Optimize=1). Sem otimização, é quatro vezes mais rápido (em memória).

Sempre quis lhe perguntar se há muito que você pode programar em seu estilo de código.

Se você tem uma tarefa para projetar e criar um mecanismo muito complexo sozinho, vale a pena usar sua maneira de escrever código? E você deve verificar o desempenho de cada registro em cada passo.

Quanto tempo levará para um desenvolvedor ler/escrever/verificar o código, se você abordar este processo em seu estilo e em seu nível?

Aposto que envelheceria sem escrever nem a metade do que eu tinha em mente.

zy. Desculpe-me pelos offtops. O estilo de programação é uma questão pessoal. Mas a um certo ponto, você começa a perceber que o código deve ser o mais legível possível, precisamente para fins de produtividade.

[fxsaber]

Реter Konow:

Sempre quis lhe perguntar - quanto você pode programar em seu estilo de código?

Um exemplo do meu estilo?