Float to String ?

[Andrew Martin]

То что вам float не нужны, это значит только то, что вы попросту не в тех морях плаваете
О целочисленном квантовании коэффициентов ЦФ уже немало написано, как и о побочных явлениях такового. Атмел даже выпустил соответствующий аппноут.

Из целых чисел извлечь корень конечно можно, но с какой точностью? Целый корень из 8 это 2, и из 4 - тоже 2. Вас такая точность устроит? Меня - нет. А если вычислять отношение двух произвольных чисел, тогда что?
Термометр? Возьмите термопару, подцепите её через инструментальный усилитель к МК. Организуйте самокалибровку, хоть по кипятку. И чтобы не было ни одного подстроечного резистора. Как-то так

[КРАМ]

Андрей...
Это печально...

ВСЕ ВЫЧИСЛЕНИЯ в МК производятся ТОЛЬКО В ЦЕЛЫХ ЧИСЛАХ. Даже если в МК есть FPU. Просто потому, что никаких других чисел в МК не существует.
Потому извлечение корня в целых числах может быть произведено С ЛЮБОЙ наперед заданной разрядностью результата.
Вопрос только ЗАЧЕМ? Зачем нужно извлекать корень с выходной разрядностью выше, чем половина входной?

Никакой дополнительной точности Вы не получите.
И потому извлечение корня из 32-разрядного ЦЕЛОГО числа даст более высокую точность, чем извлечение корня из 23,5 разрядной мантиссы стандартного флоата.
Получение лишних дробных разрядов - это ИЛЛЮЗИЯ ТОЧНОСТИ. На самом деле в этих дополнительных разрядах будет ровно столько значений, сколько в исходной. Можете проверить...
Второе.
Максимальная разрядность АЦП при сигнальных измерениях - 24. Да и то для совсем низких частот.
Таким образом, даже в самом крутом раскладе извлечение корня из 48-разрядного целочисленного числа (суммы квадратов 24 разрядных квадратурных компонент) не может дать ничего сверх 24-разрядного результата.
Третье. Сама по себе разрядность АЦП - это НИ О ЧЕМ.
Можно пафосно употреблять термин инструментальный усилитель, но на самом деле за ним НИЧЕГО НЕ СТОИТ. Потому что 24-разрядное АЦ преобразование имеет смысл лишь при том условии, что дрейф, смещение, линейность (амплитудная и частотная) и шумы будут ЛУЧШЕ, чем - 140 дБ.
Вы отдаете себе отчет в порядке этой величины?
На практике, даже 16 разрядов - это уже серьезный "океан"... И калибровка термопары в кипящей воде представляется "грязной лужей" в этом контексте. Если сей "автоматический" термометр с такой "калиброванной" термопарой измеряет в диапазоне -100...+400 градусов с точностью этой самой "калибровки", то даже 10 разрядов АЦП будет СЛИШКОМ много...

Насчет целочисленного квантования коэффициентов.
Полагаю техписателей аппнот у Атмеля людьми грамотными, поэтому настоятельно рекомендую ВАМ найти сию аппноту и прочитать ее. А потом объяснить мне каким таким образом умножение числителя и знаменателя простой дроби на одно и тоже число влияет на точность?

[Andrew Martin]

Насчет целочисленного квантования коэффициентов.
Полагаю техписателей аппнот у Атмеля людьми грамотными, поэтому настоятельно рекомендую ВАМ найти сию аппноту и прочитать ее. А потом объяснить мне каким таким образом умножение числителя и знаменателя простой дроби на одно и тоже число влияет на точность?

Не надо смешивать мухи с котлетами.
Тереотизировать на тему чисел могут многие, на практике же попытки обойтись только целочисленной арифметикой для определённых задач приводят к пляскам с бубном, леплению горбатого и усложнению кода до такой степени, что порой рациональнее было бы прибегнуть к float.

Float используют повсеместно, и они действительно облегчают жизнь.
Один из примеров: http://msevm.com/main/LCF/index.htm. Это вот реальная конструкция, а не пустопорожний трёп как у нас здесь
Скажите теперь, с какого перепугу отнюдь неглупые авторы всунули в убогий и мелкий PIC16F628 библиотеку для вычислений с плавающей точкой, учитывая при этом что проект на асме и они собственноочно видели к чему это ведёт? От хорошей жизни наверное? Или может быть просто потому, чтобы не выпендриваться с массштабированием (при делении близких по модулю чисел) и не огребать переполнений? Или чтобы реализацию самокалибровки прибора сделать лёгкой и беспроблемной, а не череззадничной?
Или может быть потому, что умножение и деление на МК без аппаратного умножителя в дробных 24- или 32-битных не намного накладнее (ровно на обработку экспоненты и знака), чем в целых 24 или 32-битных (add-shift/subtract-shift методы)?

Пару месяцев назад делал библиотеку для работы с 32-разрядными float для Cortex-M0 на FASMARM. Там есть и конвертация туда-обратно, и умножение (основная часть которого - целочисленное умножение 24-разрядных мантисс), и деление, и даже пресловутый квадратный корень К sqrt идёт прицепом таблица начальных приближений мантисс для метода Ньютона, чтобы сходилось быстрее

Так что откуда у float-ов ноги растут и чем пахнут знаю прекрасно. И накладные расходы на вычисления с плавающей точкой тоже представляю, тем не менее отказываться от float не собираюсь, особенно там, где это упрощает жизнь и нет высоких требований к скорости вычислений.

С МК у которых FPU дела не имел, поэтому стыдливо промолчу . В х86 FPU работает с 80-битными числами с плавающей точкой, но даже там, как ни странно, целочисленное деление средствами CPU не особо шустрее, чем дробное средствами FPU.

[dr.doc]

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

[КРАМ]

Не надо смешивать мухи с котлетами.
Тереотизировать на тему чисел могут многие, на практике же попытки обойтись только целочисленной арифметикой для определённых задач приводят к пляскам с бубном, леплению горбатого и усложнению кода до такой степени, что порой рациональнее было бы прибегнуть к float.
Float используют повсеместно, и они действительно облегчают жизнь.

Из всего Вашего "понтового" спича я лично понял только одно: Вы не ответили НИ НА ОДНО мое возражение по теме.
Бессвязный набор слов...., извините.

Намек на мою "теоретичность", молодой человек, просто смешон.

[Andrew Martin]

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

Курсовой? Чей? Авторов прибора (у них это не единственный проект) или "студентов" из компании Микрочип? Библиотеки и аппноуты официальные микрочиповские (575 вроде бы).

[Andrew Martin]

Из всего Вашего "понтового" спича я лично понял только одно: Вы не ответили НИ НА ОДНО мое возражение по теме.
Бессвязный набор слов...., извините.

Намек на мою "теоретичность", молодой человек, просто смешон.

А у вас они были, эти возражения?
Кроме какого-то куска кода, который вы выдаёте за процедуру извлечения квадратного корня из 32-разрядных чисел (дающую sqrt(4)=2 и sqrt(8)=2 и требующую неизвестно какого "приведения" входного аргумента для получения вменяемого результата), и призывов квантовать коэффициенты КИХ - фильтров (стабильность КИХ фильтров - очевидная и общеизвестная вещь) тоже ничего.
Ни ссылок на библиотеки или аппноуты, ни сравнения производительности кода целочисленных и float функций хотя бы для бедных восьмибиток без аппаратного умножителя.
НИЧЕГО что можно было бы почерпнуть.

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

Может вы привыкли работать с большими МК, где фарш солидный (умножители/делители) и целочисленную арифметику больше чем на 8 бит делать легко.

Написали mul.uu W6, W6, W2 и радуетесь А разворачивать на восьмибитку кто будет?

В маленьких МК разница по накладным расходам между целочисленной и float арифметикой не на порядок, и даже не в разы.

Конечно повсеместно использовать float глупо, но иногда оправдано, не только диапазоном чисел, но и удобством.

[КРАМ]

Кроме какого-то куска кода, который вы выдаёте за процедуру извлечения квадратного корня из 32-разрядных чисел (дающую sqrt(4)=2 и sqrt(8)=2 и требующую неизвестно какого "приведения" входного аргумента для получения вменяемого результата), и призывов квантовать коэффициенты КИХ - фильтров (стабильность КИХ фильтров - очевидная и общеизвестная вещь) тоже ничего.

Конечно повсеместно использовать float глупо, но иногда оправдано, не только диапазоном чисел, но и удобством.

Ну, слава Богу, Вы все таки признали, что использовать флоат нужно не повсеместно.
Уже неплохо.
Удобство - понятие относительное.
Вот, скажем, одному удобно ездить на такси,а другому на своей машине. Одному удобно есть всегда вилкой, а другому руками.
Тут ведь кто на кого учился...
А если серьезно, то при создании коммерческих проектов (да и любительских, если целесообразности совпадают) основной целью является не процесс сам по себе, а достижение как ТТХ устройства, так и минимизации затрат его производства, а ПО ВОЗМОЖНОСТИ и затрат на его создание. Учитывая, что затраты на разработку в цене одного устройства делятся на тираж этого устройства, методы при разработке исключают сибаритство. "Удобство" можете оставить для своей жены, извините...
ПРАКТИКА (по крайней мере моя и моих коллег) показывает, что В КОНЦЕ КОНЦОВ "удобство" разработчика кода (и схемотехника, кстати, хоть они, как правило, и двуедины) оборачивается для проекта увеличением себестоимости изделия.
Приведу пример.
Нынче очень "модно" (даже у авторитетных в своих областях контор) применять "удобные" референсные решения. Чтобы сбить в правильную кучку схемотехнику демонстрационных плат производителей элементной базы и библиотечные референсные коды к ним, затрачивая на конечный продукт минимум усилий моска эмбеддера. В результате получаем "солидную" схемотехнику и печатную плату в сборе при себестоимости в пару-тройку килобаксов конечного изделия там, где потратив не пару недель, а пару месяцев можно создать ТАКОЙ ЖЕ ТОЧНО функционал, но с себестоимостью изделия в 2...4 раза ниже.
При этом выясняется, что и стоимость разработки тоже падает, потому что пресловутое "удобство" разработчика стоит для компании приличного бабла...
Все это я к тому, уважаемый, что аргумент "удобно" отражает либо элементарную непрофессиональность, либо недобросовестность разработчика.
ЗЫ. По поводу извлечения корня.
При заявленных Вами заслугах и опыте кажется странным, что Вы так ничего и не поняли. Хотя это, по моему, элементарно.
Извлечение корня в показанном мной алгоритме можно продолжать до ЛЮБОЙ РАЗРЯДНОСТИ РЕЗУЛЬТАТА, ибо речь будет идти лишь о счетчике циклов и расширении нулями исходного числа в сторону дробной части. То есть об увеличении его разрядности.
Сиречь, применение флоата НИКАК НЕ УЛУЧШИТ ситуацию, поскольку операция с мантиссой по извлечению корня дает АБСОЛЮТНО ТЕ ЖЕ ОГРАНИЧЕНИЯ. А учитывая, что разрядность мантиссы 32-разрядного флоата составляет 23,5 разряда, результат извлечения корня во флоате будет МЕНЕЕ ТОЧНЫМ, нежели в предложенном мной коде даже без использования расширения в дробную часть.
И в завершение повторюсь.
НЕОБХОДИМОСТЬ в использовании флоата наблюдается в очень ограниченном количестве применений.
IIR фильтрация входит в это число, хотя и с оговорками. И в случае с IIR при входной разрядности 12 (большинство МК для обработки сигналов содержит именно такую разрядность АЦП) и разрядности контроллера от 16 до 32 без наличия в нем FPU использование флоатов ПРАКТИЧЕСКИ нецелесообразно из-за весьма низкого выигрыша по затратам ОЗУ и колоссального проигрыша по скорости обработки. IIR практически исключает использование DSP MAC операций, поэтому вопрос быстрого кода стоит очень остро.
Возращаясь к нашим баранам, напомню Вам, уважаемый, что следует прочесть СТАРТОВЫЙ ТОПИК и прекратить утверждать всякую, извините, херню...
Напомню Вам, что речь шла о датчике температуры с НАТУРАЛЬНЫМ представлением чисел в формате с ФИКСИРОВАННОЙ точкой 12.4 из которых собственно являются диапазоном чисел только 9.4.
Никакая калибровка не может изменить этой разрешающей способности. То есть множитель и смещение калибровки не могут быть выше разрядности самого обрабатываемого числа (9.4).
Из чего следует, что применять тут флоат - глупость феерическая.

[Andrew Martin]

Сиречь, применение флоата НИКАК НЕ УЛУЧШИТ ситуацию, поскольку операция с мантиссой по извлечению корня дает АБСОЛЮТНО ТЕ ЖЕ ОГРАНИЧЕНИЯ. А учитывая, что разрядность мантиссы 32-разрядного флоата составляет 23,5 разряда, результат извлечения корня во флоате будет МЕНЕЕ ТОЧНЫМ, нежели в предложенном мной коде даже без использования расширения в дробную часть.

Это само собой.
Естественно даже при конвертации целого 32-разрядного в 32-разрядный float нам нужно будет резать целых 8 разрядов и это только ухудшит изначальную точность.
Вопрос не в формате, а в разрядности. Можем использовать 31-битную мантиссу и 8-битную экспоненту, будет 40-битный float. Работать с ним не намного затратнее, чем с 32-битным, как на 8-битных МК, так и на простых 32-битных вроде М0.

Я и не утверждал, что float нужно использовать повсеместно, нужно избегать где только возможно. Вот только пределы возможного и целесообразности у всех разные, потому как разные и задачи.

Но ИНОГДА можно, и не только для БИХ - фильтров. Выше уже написали про LCF-метр и про 80-битный целочисленный "калькулятор", который нужно ещё ваять вручную и который на PIC16F628 выльется возможно почти в те же расходы памяти и процессорного времени, что и использование стандартной микрочиповской float библиотеки. А время разработки при использовании стандартной библиотеки будет однозначно меньше.

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

Это вы фирмачам объясните
Майкрософт в своё время был первым и монопольно захватил рынок, и почти никогда - лучшим. Его пример вдохновляет многих.
Если уж говорить о коммерции, то нужно и вовсе отходить от выкрутасов и весь код строить исключительно на стандартных средствах Си, всяких SPL и т.д. И везде, в каждую "мигалку" - непременно RTOS

Но вернёмся к теме. А тема у нас называется Float to String.
Топикстартер просто хотел что-либо пошустрее стандартных сишных функций, а получил порицание за использование float.

[КРАМ]

Не выдумывайте. Никакого порицания не было, пока ТС не упомянул про термометр.
Идиотизмом была названа идея преобразовывать целое формата 8.4 во флоат. И ничего более.
Вы начали фантазировать про калибровку. Калибровка не создает необходимости во флоате, поскольку на выходе все равно будет 8.4 через округление из 16.8
По любому перемножение 2 обычных int с делением на 4096 на три порядка проще чем перректальная возня с флоат.
К чему был весь этот спор - я так и не понял...

[moLCHec]

Ну и нафлудили на 1,5 страницы. Эх добавлю свои 5 копеек.
В защиту КРАМ-а (которого поддерживаю) скажу, что по моему опыту кроме понятных затрат на ресурсы при работе с float на МК без FPU
возникает проблема при сравнении переменных типа float или double, а также при инкременте на малые значения относительно больших чисел.
Допустим если время системное у вас float и вы его на 0,01 с инкриминируете, уже через 10 с начинаются проблемы

PS перенести бы это весь флуд в новую тему " float vs int ", тогда из флуда он превратится в материал по теме

[arkhnchul]

Допустим если время системное у вас float

так кто-то делает?)

[Pnjom-Penb]

Так делает Юникс и сочувствующие ему товарищи ("и другие официальные лица" ©).

[arkhnchul]

а можно примерчик из сопутствующих? Все, что видел - или таймстампы в long, long long или int64, или структуры timeчототам с тако же целочисленными полями.

[Pnjom-Penb]

а можно примерчик из сопутствующих?

Ох, "что-то с памятью моей стало" ©... слишком давно не лез внутрь и память меня амманула! Float - это в Борланде было:

Following are some examples of TDateTime values and their corresponding dates and times:

• • 0.0= 12/30/1899 12:00 am
  • 2.75= 1/1/1900 6:00 pm
  • -1.25= 12/29/1899 6:00 am
  • 35065= 1/1/1996 12:00 am

Посыпаю голову пеплом! Надеюсь, никого не убило...

[arkhnchul]

Float - это в Борланде было:

месье знали толк) Крайне любопытно, что их сподвигло к столь оригинальному решению - считать дни в double, а не как все люди, секунды/миллисекунды в long.

[Siarzhuk]

Крайне любопытно, что их сподвигло к столь оригинальному решению - считать дни в double, а не как все люди, секунды/миллисекунды в long.

long не резиновый а до начала Unix Epoch тоже люди жили. Кстати, http://www.joelonsoftware.com/items/2006/06/16.html - начиная с фразы "In most modern programming environments, dates are stored as real numbers." - объяснение почему в качестве нуля для исчисления даты в Basic (и OLE DATA и т.д.) было выбрано 30 декабря 1899 года.

[Pnjom-Penb]

Крайне любопытно, что их сподвигло ...

Полагаю - обычная логика, присущая математикам.

[B@R5uk]

Особенно интересно как реализуешь извлечение квадратного корня

В школе было дело классный метод извлечения квадратного корня в столбик узнал (сейчас его и в википедии можно найти). Этот алгоритм, будучи записан в двоичной системе приводит к быстрой и простой программе вычисления квадратного корня, которая использует лишь битовые сдвиги, вычитание, сложение (можно заменить на логическое или) и сравнение. Вот здесь я поднимал эту тему. Там же код на си. Алгоритм замечателен ещё и тем, что можно не ограничится вычислением целой части корня, а продолжить его и получить желаемое фиксированное количество двоичных знаков после запятой.

Посчитай-ка TRUE RMS по N выборкам из 10ти битного АЦП на целых числах, да c возможностью калибровки константой из EEPROM.

Пусть будет 12 бит (беззнаковые). После БИХ фильтра, отделяющего постоянную составляющую получим 12 бит знаковых. Квадрат -- это 24 бита беззнаковых, сумма 256 квадратов как раз почти 32 бита. При желании можно порезать разрядность после фильтрации или повысить её для суммы.

О целочисленном квантовании коэффициентов ЦФ уже немало написано, как и о побочных явлениях такового.

Не так страшен чёрт, как его малюют. Грамотное квантование, конечно, не самая простая задача в построении ЦФ (особенно БИХ), но она решаема, было бы желание. В конце концов, весь смысл ЦФ потеряется, если использовать плавающую точку.

Из целых чисел извлечь корень конечно можно, но с какой точностью? Целый корень из 8 это 2, и из 4 - тоже 2. Вас такая точность устроит? Меня - нет. А если вычислять отношение двух произвольных чисел, тогда что?

Ваше заблуждение в том, что вы не знаете, что на целочисленной арифметике корень вычисляется не только из целых чисел, но из любых с фиксированной точкой. Результат такой же. Впрочем, я уже писал об этом выше. С целочисленным делением тоже нет никаких проблем. Алгоритм деления ни чуть не сложнее вычисления квадратного корня, даже чуть проще. Он так же не требует операции умножения, лишь сравнения, вычитания и битовая арифметика. И так же как при вычислении корня можно делить с любой наперёд заданной точностью.

Организуйте самокалибровку, хоть по кипятку.

К сожалению, давление насыщенных паров воды экспоненциально зависит от обратной абсолютной температуры. Как следствие, температура кипения воды сильно зависит от давления воздуха. Пожалуй, только ноль можно более менее откалибровать по смеси воды и льда, хотя тут тоже могут быть проблемы, если вода/лёд с примесями.

[Andrew Martin]

Особенно интересно как реализуешь извлечение квадратного корня

В школе было дело классный метод извлечения квадратного корня в столбик узнал (сейчас его и в википедии можно найти). Этот алгоритм, будучи записан в двоичной системе приводит к быстрой и простой программе вычисления квадратного корня, которая использует лишь битовые сдвиги, вычитание, сложение (можно заменить на логическое или) и сравнение. Вот здесь я поднимал эту тему. Там же код на си. Алгоритм замечателен ещё и тем, что можно не ограничится вычислением целой части корня, а продолжить его и получить желаемое фиксированное количество двоичных знаков после запятой.

Я тоже при углублённом поиске нашел на wasm.ru похожую тему, как раз реализация Фон Неймановского алгоритма на х86 асме. И даже уже перевёл на Cortex-M0. К сожалению, когда было нужно, не нашел этого алгоритма. Видать специалисты из Микрочипа тоже не нашли - в стандартных библиотеках метод Ньютона с выборкой начального приближения из огромной таблицы. Дорога ложка к обеду
Теперь возможно перепишу функцию извлечения корня из float, сделаю извлечение корня из мантиссы по вышеуказанному алгоритму (сейчас там метод Ньютона).

В конце концов, весь смысл ЦФ потеряется, если использовать плавающую точку.

Тем не менее в крутых DSP используется именно плавающая точка, потому как это универсально.

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

Это shift-subtract метод, обратный add-shift методу, используемому при умножении.
Проблемы начинаются тогда, когда нужно приводить результат к виду, пригодному для индикации. Да и арифметика дробных чисел в формате с фиксированной точкой плохо поддаётся формализации и унификации. Нельзя написать одну универсальную библиотеку и использовать её потом везде, при любом положении фиксированной точки.

Основная доля float вычислений - операции с мантиссой, которые ничем не отличаются от операций в арифметике с фиксированной точкой. Например, при делении float приходится делить мантиссы как раз shift-subtract методом.
Поэтому можно сказать, что float арифметика "тяжелее" фиксированной только на операции с экспонентой и знаком, коих порядка 15% от общих вычислительных затрат. Как вы там говорили, не так страшен, как его малюют

К сожалению, давление насыщенных паров воды экспоненциально зависит от обратной абсолютной температуры. Как следствие, температура кипения воды сильно зависит от давления воздуха. Пожалуй, только ноль можно более менее откалибровать по смеси воды и льда, хотя тут тоже могут быть проблемы, если вода/лёд с примесями.

Согласен, пример неудачный. Выше приведен более удачный пример, где без флоатов очень туго - LCF-метр.