Nikolai Semko: Ну кто Вам мешает заменить тип функции на double.
И речь свою контролируйте, пожалуйста.
Не в обиду сказано. Для конвертации в целое есть всякие rint, lrint, llrint. Они ведь не просто так возникли, когда можно сделать много проще long(double). Конвертировать плавающее в целое это концептуальная ошибка.
Не в обиду сказано. Для конвертации в целое есть всякие rint, lrint, llrint. Они ведь не просто так возникли, когда можно сделать много проще long(double). Конвертировать плавающее в целое это концептуальная ошибка.
fxsaber: Неоднозначная трактовка тогда. Решил, что выводится время цикла, а не среднее время одного вызова функции.
Выигрыш оказывается в 3-8 раз.
Возможно метод расчета времени выполнения функций не безупречен, но вполне объективен. Но если кто-то предложит лучший более объективный вариант - то будет комильфо.
2018.08.2522:16:01.309 TestRound (EURUSD,M10) Время цикла без округления = 1.315 наносекунд, сумма = 5249993749.981459622018.08.2522:16:01.309 TestRound (EURUSD,M10) Время выполнения функции sqrt = 0.628 наносекунд, сумма = 81969849.90928555 // даже квадратный корень вычисляется в несколько раз быстрее чем штатные функции округления2018.08.2522:16:01.313 TestRound (EURUSD,M10) Время выполнения функции ceil = 2.037 наносекунд, Контрольная сумма = 5250492895.02018.08.2522:16:01.315 TestRound (EURUSD,M10) Время выполнения функции Ceil = 0.587 наносекунд, Контрольная сумма = 5250492895.02018.08.2522:16:01.318 TestRound (EURUSD,M10) Время выполнения функции floor = 2.247 наносекунд, Контрольная сумма = 5249492896.02018.08.2522:16:01.320 TestRound (EURUSD,M10) Время выполнения функции Floor = 0.385 наносекунд, Контрольная сумма = 5249492896.02018.08.2522:16:01.323 TestRound (EURUSD,M10) Время выполнения функции round = 1.610 наносекунд, Контрольная сумма = 5249992896.02018.08.2522:16:01.324 TestRound (EURUSD,M10) Время выполнения функции Round = 0.181 наносекунд, Контрольная сумма = 5249992896.0
Предлагаю разработчикам воспользоваться этим алгоритмом в штатных функциях.
)). Этому может быть место только в личных поделках при точном знании диапазона значений, но никак не в стд библиотеке. Штатные функции не дураками писаны, не думайте, что самый умный. Вот тоже товарищ пишет на undefined и unspecified behavior, а пототм удивляется, что работает не так https://www.linux.org.ru/forum/development/14422428#comments. А вся эта экономия в несколько наносекунд в реальном алгоритме (а не в голом цикле) даже видна не будет.
А я вот тоже не пойму, почему функции округления должны возвращать double. По-моему, в том и смысл округления, что необходимо определиться, как из плавающего значения получить целое.
В чем "концептуальная ошибка" конвертации - мне тоже не вполне ясно.
А я вот тоже не пойму, почему функции округления должны возвращать double. По-моему, в том и смысл округления, что необходимо определиться, как из плавающего значения получить целое.
В чем "концептуальная ошибка" конвертации - мне тоже не вполне ясно.
Задумайтесь, что получите за пределами целого числа.
Результат 1123275 и 1666643 в пользу MyNormalizeDouble (Optimize=1). Без оптимизации - быстрее раза в четыре (на память).
Всегда хотел Вас спросить, - а много ли можно напрограммировать в Вашем стиле кода?
Если поставлена задача, самостоятельно разработать и создать сложнейший механизм, стоит ли применять Ваш метод написания кода? Да еще на каждом шагу проверять производительность каждой записи.
Сколько времени уйдет у разработчика на чтение/написание/проверку кода, если подойти к этому процессу в Вашем стиле и на Вашем уровне?
Бьюсь об заклад, я бы состарился не написав и половину того, что задумал.
зы. Сорри за оффтоп. Стиль программирования - это личное дело каждого. Но на определенном этапе, начинаешь понимать, что код должен быть максимально читабельным, именно в целях производительности труда.
Индекс производительности труда показывает изменение объема выпущенной продукции, приходящегося на одного работника. Этот показатель полезен для предсказания инфляции и прироста объема производства. Если стоимость труда увеличивается соответственно увеличению производительности, и, кроме того, маловероятно увеличение производственных издержек...
Потому, что конвертировать double в целое (таким образом) - говнокод. round с друзьями не предназначена для получения целого типа из плавающего.
Ну кто Вам мешает заменить тип функции на double.
Не в обиду сказано. Для конвертации в целое есть всякие rint, lrint, llrint. Они ведь не просто так возникли, когда можно сделать много проще long(double). Конвертировать плавающее в целое это концептуальная ошибка.
Не в обиду сказано. Для конвертации в целое есть всякие rint, lrint, llrint. Они ведь не просто так возникли, когда можно сделать много проще long(double). Конвертировать плавающее в целое это концептуальная ошибка.
О, да Вы просто не в теме...
Ок, UB вам в руки.
Неоднозначная трактовка тогда. Решил, что выводится время цикла, а не среднее время одного вызова функции.
Выигрыш оказывается в 3-8 раз.
Возможно метод расчета времени выполнения функций не безупречен, но вполне объективен. Но если кто-то предложит лучший более объективный вариант - то будет комильфо.
Изменил все же для полной аналогии на тип double.
Предлагаю разработчикам воспользоваться этим алгоритмом в штатных функциях.
А я вот тоже не пойму, почему функции округления должны возвращать double. По-моему, в том и смысл округления, что необходимо определиться, как из плавающего значения получить целое.
В чем "концептуальная ошибка" конвертации - мне тоже не вполне ясно.
А я вот тоже не пойму, почему функции округления должны возвращать double. По-моему, в том и смысл округления, что необходимо определиться, как из плавающего значения получить целое.
В чем "концептуальная ошибка" конвертации - мне тоже не вполне ясно.
NormalizeDouble
Результат 1123275 и 1666643 в пользу MyNormalizeDouble (Optimize=1). Без оптимизации - быстрее раза в четыре (на память).
Всегда хотел Вас спросить, - а много ли можно напрограммировать в Вашем стиле кода?
Если поставлена задача, самостоятельно разработать и создать сложнейший механизм, стоит ли применять Ваш метод написания кода? Да еще на каждом шагу проверять производительность каждой записи.
Сколько времени уйдет у разработчика на чтение/написание/проверку кода, если подойти к этому процессу в Вашем стиле и на Вашем уровне?
Бьюсь об заклад, я бы состарился не написав и половину того, что задумал.
зы. Сорри за оффтоп. Стиль программирования - это личное дело каждого. Но на определенном этапе, начинаешь понимать, что код должен быть максимально читабельным, именно в целях производительности труда.
Всегда хотел Вас спросить, - а много ли можно напрограммировать в Вашем стиле кода?
Пример моего стиля?