Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Числа с фиксированной точкой в своих комментариях я отмечаю как QN.M, где N — разрядность числа, M — количество разрядов после запятой.Получилось практически как в фортране. Там в форматах вывода используют такую же логику.
Думаю многим будет интересно, если расскажите как правильно поступать, если требуется сложить/умножить большое и маленькое число с какой-то точностью.
Не очень понял последний вопрос, если честно. То есть, возможно, понял неправильно.
Что значит «большое» и «маленькое» число в данном случае?
Разной разрядности или одной разрядности с сильно различающимися мантиссами?
Что значит «большое» и «маленькое» число в данном случае?
Разной разрядности или одной разрядности с сильно различающимися мантиссами?
Разрядности сильно отличаются. Мб в 10 раз и больше.
Это, видимо, из FPGA?
На «обычных» процессорах разрядности максимум в 16 раз сейчас отличаются (128 bit vs. 8 bit)
Если по сути вопроса, то есть уточняющий вопрос:
в Вашем FPGA вычислитель любой разрядностью оперирует или есть ограничения?
Т.е. он может перемножить числа максимальной требуемой разрядности и полностью сохранить результат в регистре?
Если да, то хитростей никаких нет.
в моей/матлабовской нотации запись выглядит так:
QN1.M1 x QN2.M2 = Q(N1 + N2).(M1 + M2), то есть имеем число с (N1 + N2) значащих бит с (M1 + M2) бит на дробную часть числа. Дальше следует округлить результат до желаемой точности.
Постараюсь уместить во вторую часть статьи вариант для перемножения чисел, которые не влезают в регистр.
ЗЫ. На подготовку и вычитку текста у меня немало времени уходит, поэтому второй части пока нет.
На «обычных» процессорах разрядности максимум в 16 раз сейчас отличаются (128 bit vs. 8 bit)
Если по сути вопроса, то есть уточняющий вопрос:
в Вашем FPGA вычислитель любой разрядностью оперирует или есть ограничения?
Т.е. он может перемножить числа максимальной требуемой разрядности и полностью сохранить результат в регистре?
Если да, то хитростей никаких нет.
в моей/матлабовской нотации запись выглядит так:
QN1.M1 x QN2.M2 = Q(N1 + N2).(M1 + M2), то есть имеем число с (N1 + N2) значащих бит с (M1 + M2) бит на дробную часть числа. Дальше следует округлить результат до желаемой точности.
Постараюсь уместить во вторую часть статьи вариант для перемножения чисел, которые не влезают в регистр.
ЗЫ. На подготовку и вычитку текста у меня немало времени уходит, поэтому второй части пока нет.
> Полный контроль за поведением кода.
> Фиксированная точка исключает появление «неожиданностей»,
> связанных с особенностями реализации плавающей запятой на используемой платформе.
С форматом плавающей точки как раз все гораздо определенней.
Как правило, процессорные модули для вычислений с плавающей точкой
реализуют стандарт IEEE 754, и имеют набор команд (F*) работающий с тремя типами данных длиной 4,8,10 байт (собственно: float, double, long double)
При портировании на разные ОС, проблем как раз с этими типами данных возникнуть не должно.
> Фиксированная точка исключает появление «неожиданностей»,
> связанных с особенностями реализации плавающей запятой на используемой платформе.
С форматом плавающей точки как раз все гораздо определенней.
Как правило, процессорные модули для вычислений с плавающей точкой
реализуют стандарт IEEE 754, и имеют набор команд (F*) работающий с тремя типами данных длиной 4,8,10 байт (собственно: float, double, long double)
При портировании на разные ОС, проблем как раз с этими типами данных возникнуть не должно.
В ядре Linux, например, использование вычислений с плавающей запятой затруднено (требуется полное сохранение контекста FPU), да и вообще крайне не рекомендуется. А если придётся переносить уже написанный код на микроконтроллер, который в принципе не имеет FPU? Так что всё зависит от конкретного применения.
Насколько я понимаю вы собираетесь переносить код на Си,
а это значит, что вы будете использовать компилятор заточенный под ту или иную архитектуру,
который сам реализует описанные вами действия (я не беру в расчет компиляторы на Си, которые не знают что такое float и double).
В бытность разработчика приборной техники я переносил ГОСТовские алгоритмы для вычислений по газу с устройств на базе контроллеров PIC на ARM. Проблем небыло, коды с использованием типа float перенеслись и работали.
Про ядро сказать ничего не могу.
а это значит, что вы будете использовать компилятор заточенный под ту или иную архитектуру,
который сам реализует описанные вами действия (я не беру в расчет компиляторы на Си, которые не знают что такое float и double).
В бытность разработчика приборной техники я переносил ГОСТовские алгоритмы для вычислений по газу с устройств на базе контроллеров PIC на ARM. Проблем небыло, коды с использованием типа float перенеслись и работали.
Про ядро сказать ничего не могу.
>… вы будете использовать компилятор заточенный под ту или иную архитектуру…
В тех случаях, когда сам микроконтроллер не поддерживает работу с плавающей запятой, используется программная эмуляция, так называемый soft-float. Да, оно скомпилируется и будет работать, но это применимо только в тех случаях, когда скорость вычислений особого значения не имеет. Понятно что fixed-point вычисления быстрее.
> Про ядро сказать ничего не могу.
А тут особо ничего нового и не скажешь. Вот что про это дело Линус Торвальдс говорил: lkml.indiana.edu/hypermail/linux/kernel/0405.3/1620.html
Основная мысль сводится к следующей фразе:
В тех случаях, когда сам микроконтроллер не поддерживает работу с плавающей запятой, используется программная эмуляция, так называемый soft-float. Да, оно скомпилируется и будет работать, но это применимо только в тех случаях, когда скорость вычислений особого значения не имеет. Понятно что fixed-point вычисления быстрее.
> Про ядро сказать ничего не могу.
А тут особо ничего нового и не скажешь. Вот что про это дело Линус Торвальдс говорил: lkml.indiana.edu/hypermail/linux/kernel/0405.3/1620.html
Основная мысль сводится к следующей фразе:
In other words: the rule is that you really shouldn't use FP in the kernel.
Гонять floating-point на PIC и ARM (до ARM с VFP) — издевательство :)
«Работали» и «битэкзектно» — разные вещи немножко. Наверное, удовлетворяли требованиям по точности? По скорости все хорошо было?
На TI не пробовали запускать? Числодробилки, а на плавающей точке не живут (только вот 67хх немножко выправил ситуацию).
«Работали» и «битэкзектно» — разные вещи немножко. Наверное, удовлетворяли требованиям по точности? По скорости все хорошо было?
На TI не пробовали запускать? Числодробилки, а на плавающей точке не живут (только вот 67хх немножко выправил ситуацию).
Ключевое слово в данном случае «как правило» :)
Модули вычислений с плавающей точкой на разных процессорах дают разные результаты. С различными опциями компиляции — тоже.
Что для Вас «портирование»? Если просто перенести, чтобы работало и давало похожий результат — то да, проблем не возникнет, если надо перенести код так, чтобы результат был битэкзактен, то проблем не оберешься. Попробуйте одинаковый код погонять на ARM и х86 в качестве упражнения.
Можно также пройти по ссылкам на другие топики в начале моей статьи — там рассказано и о «переносимости» плавающей запятой.
N.B. Вас никто не неволит фиксированную точку использовать :)
Все зависит от решаемых задач и целевых платформ. Плавающая запятая может быть быстрее и удобнее, но не всегда подходит для конкретной платформы.
Модули вычислений с плавающей точкой на разных процессорах дают разные результаты. С различными опциями компиляции — тоже.
Что для Вас «портирование»? Если просто перенести, чтобы работало и давало похожий результат — то да, проблем не возникнет, если надо перенести код так, чтобы результат был битэкзактен, то проблем не оберешься. Попробуйте одинаковый код погонять на ARM и х86 в качестве упражнения.
Можно также пройти по ссылкам на другие топики в начале моей статьи — там рассказано и о «переносимости» плавающей запятой.
N.B. Вас никто не неволит фиксированную точку использовать :)
Все зависит от решаемых задач и целевых платформ. Плавающая запятая может быть быстрее и удобнее, но не всегда подходит для конкретной платформы.
Согласен с вами, особенно про битэкзактность.
Допустим, если вы считаете хеш для ЭЦП, то без нее никуда.
Однако, имеет ли она смысл, когда разговор идет о дробных числах?
(особенно близких к нолю или с кучей знаков после запятой)
Их некорректно сравнивать жестко f1 == f2, а неплохо бы делать |f1-f2| < Δ.
Дельта в этом случае как раз и позволит избавиться от особенностей округления и других индивидуальных настроек FPU на разных архитектурах.
Допустим, если вы считаете хеш для ЭЦП, то без нее никуда.
Однако, имеет ли она смысл, когда разговор идет о дробных числах?
(особенно близких к нолю или с кучей знаков после запятой)
Их некорректно сравнивать жестко f1 == f2, а неплохо бы делать |f1-f2| < Δ.
Дельта в этом случае как раз и позволит избавиться от особенностей округления и других индивидуальных настроек FPU на разных архитектурах.
Вот как раз на fixed-point корректно сравнивать f1 == f2 ;)
А на плавающей точке тогда уж |f1-f2| / |f1| < Δ или можно просто промахнуться с выбором допустимой погрешности. Т.е. имеем лишнее деление (умножение, если вправо перенести) на простой операции сравнения. Когда такты считаешь, оно не очень приятно.
А на плавающей точке тогда уж |f1-f2| / |f1| < Δ или можно просто промахнуться с выбором допустимой погрешности. Т.е. имеем лишнее деление (умножение, если вправо перенести) на простой операции сравнения. Когда такты считаешь, оно не очень приятно.
Я не ас в метрологии… :) Но попробую:
Если это какой-то конкретный параметр
(вряд ли имеет смысл сравнивать промежуточные величины),
некая конкретная физическая или математическая величина,
то требования по точности должны быть определены в ТЗ
и это вряд ли будет величина относительная.
Если это какой-то конкретный параметр
(вряд ли имеет смысл сравнивать промежуточные величины),
некая конкретная физическая или математическая величина,
то требования по точности должны быть определены в ТЗ
и это вряд ли будет величина относительная.
Если требования к приборам можно задавать в абсолютных величинах (иногда), и это вызвано вполне конкретными возможностями аппаратуры, то требования к вычислительным погрешностям стоит задавать именно в относительных величинах.
Просто пример:
Зададим абсолютный порог равным 1.
Тогда 1000 и 1001 примерно равны по вышеуказанному критерию, с относительной погрешностью 1e-3 (0.1%).
С другой стороны 2 и 1 тоже равны по вышеуказанному критерию, вот только относительная погрешность уже 1 (100%) или 0.5 (50%) — в зависимости от того, относительно чего сравниваем.
Кстати, если Вы заранее знаете порядки величин, то зачем плавающую запятую использовать и заморачиваться «правильным» сравнением, когда можно на фиксированной точке алгоритм реализовать?
Просто пример:
Зададим абсолютный порог равным 1.
Тогда 1000 и 1001 примерно равны по вышеуказанному критерию, с относительной погрешностью 1e-3 (0.1%).
С другой стороны 2 и 1 тоже равны по вышеуказанному критерию, вот только относительная погрешность уже 1 (100%) или 0.5 (50%) — в зависимости от того, относительно чего сравниваем.
Кстати, если Вы заранее знаете порядки величин, то зачем плавающую запятую использовать и заморачиваться «правильным» сравнением, когда можно на фиксированной точке алгоритм реализовать?
Спасибо за материал, написано интересно.
Не много не понял вот этого момента
Не много не понял вот этого момента
Например, q32.15 * q16.4 = q48.19. Сразу видно, что для полного представления результата надо 48-бит. Во второй нотации запись выглядит как q16.15 * q12.4 = q28.19
<.blockquote>
Здесь для 16-тибитного числа вроде должно получиться q11.4, а не q12.4? Нет? Или я не правильно понял принцип 2-ой Q-нотации
И еще немного позанудствую.
В вычислительной математике дробные значения представляют в виде пары целых чисел (n, e): мантиссы и экспоненты.
Все же по-русски это мантисса и показатель степени.
Если экспонента переменная, записываемая в регистр и неизвестная при компиляции, (n, e) называют числом с плавающей запятой. Если экспонента известна заранее, (n, e) называют числом с фиксированной точкой.
ИМХО следует использовать один вариант выражения: либо точка, либо запятая.
Ну, я сразу извинился за «фиксированную точку» :)
По-русски, наверное, правильнее в обоих случаях «запятая» — у нас именно запятая разделяет целую и дробную части десятичных дробей.
По-русски, наверное, правильнее в обоих случаях «запятая» — у нас именно запятая разделяет целую и дробную части десятичных дробей.
1) Извините, нажал «Написать», не дописав ответ, когда ребенок проснулся/заплакал.
По оставшимся моментам:
q12.4 — ошибка, сейчас поправлю. С учетом знака правильно q11.4.
Со знаком, кстати, вообще путаница может возникнуть — приведенные мной нотации не предусматривают беззнаковых чисел.
2) Насчет «показателя степени» — достаточно часто встречается выражение «экспоненциальная запись числа» или «запись числа с экспонентой». Поэтому, не думаю, что прямо путаница возникнет, но на всякий случай внесу Ваше замечание в статью.
По оставшимся моментам:
q12.4 — ошибка, сейчас поправлю. С учетом знака правильно q11.4.
Со знаком, кстати, вообще путаница может возникнуть — приведенные мной нотации не предусматривают беззнаковых чисел.
2) Насчет «показателя степени» — достаточно часто встречается выражение «экспоненциальная запись числа» или «запись числа с экспонентой». Поэтому, не думаю, что прямо путаница возникнет, но на всякий случай внесу Ваше замечание в статью.
Извините, если я тупой вопрос задам, но не смог сходу нагуглить ответ на него.
Объясните, пожалуйста запись переменных:
int32_t a = 0x1000L; // q15: a = 0.125
int32_t b = 0x20000L; // q20: b = 0.125
Что за L в конце? И почему это получается число с одной и той же мантиссой?
Объясните, пожалуйста запись переменных:
int32_t a = 0x1000L; // q15: a = 0.125
int32_t b = 0x20000L; // q20: b = 0.125
Что за L в конце? И почему это получается число с одной и той же мантиссой?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вычисления с фиксированной точкой. Основные принципы (ч.1)