
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
)). Этому может быть место только в личных поделках при точном знании диапазона значений, но никак не в стд библиотеке. Штатные функции не дураками писаны, не думайте, что самый умный. Вот тоже товарищ пишет на undefined и unspecified behavior, а пототм удивляется, что работает не так https://www.linux.org.ru/forum/development/14422428#comments. А вся эта экономия в несколько наносекунд в реальном алгоритме (а не в голом цикле) даже видна не будет.
Только сейчас догнал о том, что Вы говорили.
Беру свои слова обратно о том, что Вы не в теме. Прошу прощения.
Да, тот вариант можно использовать с оговоркой, что число double лежит в диапазоне от -9007199254740992 до 9007199254740992 (2 в степени 53(количество битов в мантиссе))
Задумайтесь, что получите за пределами целого числа.
а если такой вариант?
результат:
вроде тест показывает полную идентичность.
Правда скорость альтернативного решения в таком варианте, где идет проверка диапазона, выше примерно всего в 2 раза (а не 3-8), но это если число double находится в диапазоне от -9007199254740992 до 9007199254740992. Зато значительно выше, когда находится вне этого диапазона.
вроде тест показывает полную идентичность.
Правда такой вариант не учитывает переполнения входной переменной типа double, когда она принимает значения nan, snan.
Если это нужно учитывать, то можно еще вставлять одну проверку, но все равно и такой вариант будет работать быстрее оригинальной функции
Запилите советник для тестера/оптимизатора. Именно там важна скорость на практике.
Запилите советник для тестера/оптимизатора. Именно там важна скорость на практике.
Как многим известно, я так же занимаюсь сглаженной графикой. Именно для сглаженной графики и работе с каждым пикселем активно используются функции округления.
Я раньше даже представить себе не мог, что функция округления выполняется медленнее извлечения квадратного корня из числа double.
Именно по этой причине я занялся выдушиванием этих наносекунд. Потому как эти наносекунды на сглаженной графике могут превращаться в миллисекунды на каждом кадре, а кадр может меняться каждые 33 миллисекунды.
Как многим известно, я так же занимаюсь сглаженной графикой. Именно для сглаженной графики и работе с каждым пикселем активно используются функции округления.
Именно по этой причине я занялся выдушиванием этих наносекунд. Потому как эти наносекунды на сглаженной графике могут превращаться в миллисекунды на каждом кадре, а кадр может меняться каждые 33 миллисекунды.
Безусловно, для графики это важно. Поэтому там очень давно существуют алгоритмические оптимизации почти на все распространенные задачи.
Безусловно, для графики это важно. Поэтому там очень давно существуют алгоритмические оптимизации почти на все распространенные задачи.
Ошибаетесь. Там еще не паханное поле, а что распахано, то закрыто. А у MQL тем более. Класс CCanvas очень далек от оптимальности, а сглаженность там практически отсутствует, а то что есть из сглаженности - неудовлетворительно.
А почему не пользуетесь LONG_MAX/MIN ? Будет как-то приличней смотреться. Вроде, ничего выглядит. Я прогал ваши тесты на gcc (c мин модификацией, естественно, компилятор очень старый 5.4.0, что было под рукой):
1. Компиляция с -O3
2. Компиляция с -Ofast
У вас в коде подсчёт времени барахлит - вывод в милисекундах (а не нано), и я так и не понял - зачем нужно минус t0.
Ошибаетесь. Там еще не паханное поле, а что распахано, то закрыто.
Про мировой опыт говорил. Посмотрите алгоритмы на тематических форумах, где граф. демки делают. Народ делится быстрыми алгоритмами.
Про мировой опыт говорил. Посмотрите алгоритмы на тематических форумах, где граф. демки делают. Народ делится быстрыми алгоритмами.