Альтернативные реализации стандартных функций/подходов - страница 7

Новый комментарий
 
pavlick_:

Потому, что конвертировать double в целое (таким образом) - говнокод. round с друзьями не предназначена для получения целого типа из плавающего.

Ну кто Вам мешает заменить тип функции на double. 
И речь свою контролируйте, пожалуйста.
 
Nikolai Semko:
Ну кто Вам мешает заменить тип функции на double. 
И речь свою контролируйте, пожалуйста.

Не в обиду сказано. Для конвертации в целое есть всякие rint, lrint, llrint. Они ведь не просто так возникли, когда можно сделать много проще long(double). Конвертировать плавающее в целое это концептуальная ошибка.

 
pavlick_:

Не в обиду сказано. Для конвертации в целое есть всякие rint, lrint, llrint. Они ведь не просто так возникли, когда можно сделать много проще long(double). Конвертировать плавающее в целое это концептуальная ошибка.

О, да Вы просто не в теме...
 
Nikolai Semko:
О, да Вы просто не в теме...

Ок, UB вам в руки.

 
fxsaber:
Неоднозначная трактовка тогда. Решил, что выводится время цикла, а не среднее время одного вызова функции.

Выигрыш оказывается в 3-8 раз.

Возможно метод расчета времени выполнения функций не безупречен, но вполне объективен. Но если кто-то предложит лучший более объективный вариант - то будет комильфо.

Изменил все же для полной аналогии на тип double.

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

Предлагаю разработчикам воспользоваться этим алгоритмом в штатных функциях.

Файлы:
TestRound.mq5  7 kb
 
)). Этому может быть место только в личных поделках при точном знании диапазона значений, но никак не в стд библиотеке. Штатные функции не дураками писаны, не думайте, что самый умный. Вот тоже товарищ пишет на undefined и unspecified behavior, а пототм удивляется, что работает не так https://www.linux.org.ru/forum/development/14422428#comments. А вся эта экономия в несколько наносекунд в реальном алгоритме (а не в голом цикле) даже видна не будет.
 

А я вот тоже не пойму, почему функции округления должны возвращать double. По-моему, в том и смысл округления, что необходимо определиться, как из плавающего значения получить целое.

В чем "концептуальная ошибка" конвертации - мне тоже не вполне ясно.

 
Georgiy Merts:

А я вот тоже не пойму, почему функции округления должны возвращать double. По-моему, в том и смысл округления, что необходимо определиться, как из плавающего значения получить целое.

В чем "концептуальная ошибка" конвертации - мне тоже не вполне ясно.

Задумайтесь, что получите за пределами целого числа. 
 
fxsaber:

NormalizeDouble

 

Результат 1123275 и 1666643 в пользу MyNormalizeDouble (Optimize=1). Без оптимизации - быстрее раза в четыре (на память).


Всегда хотел Вас спросить, - а много ли можно напрограммировать в Вашем стиле кода?

Если поставлена задача, самостоятельно разработать и создать сложнейший механизм, стоит ли применять Ваш метод написания кода? Да еще на каждом шагу проверять производительность каждой записи.

Сколько времени уйдет у разработчика на чтение/написание/проверку кода, если подойти к этому процессу в Вашем стиле и на Вашем уровне?

Бьюсь об заклад, я бы состарился не написав и половину того, что задумал.


зы. Сорри за оффтоп. Стиль программирования - это личное дело каждого. Но на определенном этапе, начинаешь понимать, что код должен быть максимально читабельным, именно в целях производительности труда.

Productivity - США - MetaTrader 5
Productivity - США - MetaTrader 5
  • www.metatrader5.com
Индекс производительности труда показывает изменение объема выпущенной продукции, приходящегося на одного работника. Этот показатель полезен для предсказания инфляции и прироста объема производства. Если стоимость труда увеличивается соответственно увеличению производительности, и, кроме того, маловероятно увеличение производственных издержек...
 
Реter Konow:

Всегда хотел Вас спросить, - а много ли можно напрограммировать в Вашем стиле кода?

Пример моего стиля?

12345678910111213
Новый комментарий