-
- "Быстрее/точнее" по сравнению с чем? С целочисленной арифметикой? О_о - rezident(08.07.2012 02:22)
- Быстрее по сравнению с МК без FPU. Точнее чем в целочисленной считать. А вы что - против FPU в МК? - Apтём(08.07.2012 02:33)
- Точнее? Ну-ка прибавьте-ка к миллиону одну сотую :) И вообще речь не про FPU. В сообщении Dir запятая пропущена. ИМХО читать его нужно так "Как только перейдете на Cortex-ы, (то) без float-ов ..." - rezident(08.07.2012 02:45, ссылка)
- нету смысла прибавлять к миллиону одну сотую. и кстати, покажите как вам без флоатов удаётся прибавить одну сотую к миллиону ))) - Mahagam(08.07.2012 03:03)
- Смысл есть. Например, накопительный итог (накопленный расход) в приборе учета/расходомере. Примеры возможных ошибок и критических ситуаций при использовании float описаны по ссылке. - rezident(08.07.2012 14:05 - 14:47, ссылка)
- тут вопрос не в том, что float даст тьму ошибок, а в том, что формат исходных данных и метода их подсчёта выбрана неверно. Mahagam(251 знак., 08.07.2012 15:57)
- Хе-хе. Приходится аппроксимировать объем каждого импульса расходомера. - Vladimir Ljaschko(08.07.2012 17:05)
- float для денег это круто :=) Банкиры за это дело сразу бы расстреляли. Да и по поводу счета в импульсах датчика тоже жэсть - koyodza(08.07.2012 16:15)
- а я про банкиров и не говорю =8) для личных нужд - хватит за глаза. Mahagam(517 знак., 08.07.2012 16:38)
- это довольно примитивный пример, в котором промежуточные вычисления действительно удобнее в попугаях - koyodza(08.07.2012 18:13)
- Ога, то-то в каждой банковской выписке вижу "Количество транзакций за год = 154.0000, за месяц = 13.0000" - и никого еще не расстреляли :)) - MBedder(08.07.2012 16:20)
- а я про банкиров и не говорю =8) для личных нужд - хватит за глаза. Mahagam(517 знак., 08.07.2012 16:38)
- Ага. И для каждого датчика размер его попугая. rezident(318 знак., 08.07.2012 16:05)
- так или иначе разрядность или размер попугая в системе есть. при передаче "наверх" приводим к кошерному виду. но внутрях лучше считать более оптимальным методом. а человечеству проще чем контроллеру - при сложении "в столбик" разрядность Mahagam(62 знак., 08.07.2012 16:10)
- Нюансы. rezident(1014 знак., 08.07.2012 16:30 - 16:33)
- ещё можно добавить koyodza(559 знак., 08.07.2012 16:38 - 16:42)
- Да все просто. Учитывать не объемный расход, а массовый. Такие расходомеры тоже существуют. А закон сохранения массы еще никто не отменял ;) - Dir(08.07.2012 17:44)
- ну так везде свой подход. мой пример (см. ссылку) удобнее считать в целых. газ - даблами. удавов - попугаями. лишь бы обоснованно было )) - Mahagam(08.07.2012 16:45, ссылка)
- Резюмируя. Чтобы не терять точность, локальные вычисления нужно производить в целых числах. Но! Обмениваться данными приходится во float. - rezident(08.07.2012 16:49)
- Угу. Типа приведение расхода газа к Н.У. - rezident(08.07.2012 16:41)
- ещё можно добавить koyodza(559 знак., 08.07.2012 16:38 - 16:42)
- есть масса мест, где подобный подход недопустим - koyodza(08.07.2012 16:30)
- Нюансы. rezident(1014 знак., 08.07.2012 16:30 - 16:33)
- так или иначе разрядность или размер попугая в системе есть. при передаче "наверх" приводим к кошерному виду. но внутрях лучше считать более оптимальным методом. а человечеству проще чем контроллеру - при сложении "в столбик" разрядность Mahagam(62 знак., 08.07.2012 16:10)
- тут вопрос не в том, что float даст тьму ошибок, а в том, что формат исходных данных и метода их подсчёта выбрана неверно. Mahagam(251 знак., 08.07.2012 15:57)
- Как без флоатов? Легко. Лeoнид Ивaнoвич(132 знак., 08.07.2012 13:32)
- и получаем предел всего в 4 миллиона попугаев. - Mahagam(08.07.2012 14:31)
- Вам мало? Тогда берите long long. - Лeoнид Ивaнoвич(08.07.2012 14:52)
- А тригонометрия? Квадратные корни? - Apтём(08.07.2012 13:38)
- И то, и другое делается в 32-битных целых гораздо точнее и гораздо быстрее, чем во флоатах - MBedder(08.07.2012 13:42)
- Нет два раза. Если подразумевается, что посчитать какую-то дискретную функцию в целых числах проще -- тоже часто нет. Потому, что float не 32-битный и может быть ручным хорошо оптимизированным ассемблерным кодом в libc. MBedder имел ввиду, что fk0(2296 знак., 08.07.2012 14:08)
- Каким образом? Пример приведёте? - Apтём(08.07.2012 13:45)
- И то, и другое делается в 32-битных целых гораздо точнее и гораздо быстрее, чем во флоатах - MBedder(08.07.2012 13:42)
- и получаем предел всего в 4 миллиона попугаев. - Mahagam(08.07.2012 14:31)
- бывает что есть смысл. Например, когда происходит накопление большого количества значений - koyodza(08.07.2012 10:27 - 11:34)
- Есть смысл! Недавно пришлось делать это в банальном приборе, чтобы алгоритм оставался прозрачным. long long, и объем сотни литров считается с точностью микролитров - Vladimir Ljaschko(08.07.2012 09:08)
- В контроллерах профессионального уровня (PIC18) нет long long, а float есть. Хотя в флоате так не посчитаешь (добавить к гигалитру микролитр никак не получится). - fk0(08.07.2012 11:02)
- В контроллере и не может быть long long, это свойство компиляторов, которые более развиты для контроллеров "любительского уровня" ;) - Vladimir Ljaschko(08.07.2012 13:03)
- Профессионалы пишут свои библиотеки целочисленной 64-битной и выше арифметики ) - zzz(08.07.2012 14:50,
)
- Профессионалы пишут свои библиотеки целочисленной 64-битной и выше арифметики ) - zzz(08.07.2012 14:50,
- В контроллере и не может быть long long, это свойство компиляторов, которые более развиты для контроллеров "любительского уровня" ;) - Vladimir Ljaschko(08.07.2012 13:03)
- В контроллерах профессионального уровня (PIC18) нет long long, а float есть. Хотя в флоате так не посчитаешь (добавить к гигалитру микролитр никак не получится). - fk0(08.07.2012 11:02)
- Если хочется сотую прибавить можно double взять. Так что можно. - Apтём(08.07.2012 03:05)
- Прибавить в double вы можете (более того, вычисления float как раз с удвоенной точностью происходят), но передать полученное значение во float вы уже не сможете. - rezident(08.07.2012 14:01)
- В АВР вычисления происходят с одинарной точностью. Или не так? - Apтём(08.07.2012 14:09)
- В ваших АВР, как и в любых других ваших МК, вычисления происходят исключительно с той точностью, которую удосужился реализовать тот или иной гавнокодер. Во всех моих МК вычисления происходят с точностью в один младший бит - MBedder(08.07.2012 15:08)
- А как по скорости/объёму получилось? Не поделитесь результатами сравнения стандартными решениями? - Apтём(08.07.2012 15:14)
- По скорости - многократно скорее, по объему - многократно меньше - MBedder(08.07.2012 15:17)
- Так может исходниками поделитесь с народом? - Apтём(08.07.2012 15:19)
- Пока народ пользует флоаты для масштабирования отсчетов 10-битных АЦП - нет желания - MBedder(08.07.2012 15:38)
- такой подход тоже имеет право на жизнь ))) если ты не матёрый koyodza, то тебе проще ляпнуть во флоат, зато не будет проблем с переполнением, потерями точности и прочими проблемами - Mahagam(08.07.2012 17:53)
- Между прочим, да. А в новых МК, в которых FPU уже встроен изначально и перемножение флоатов занимает несколько тактов этот путь еще и по времени выполнения предпочтителен. Dir(169 знак., 08.07.2012 18:02)
- Потеет жопа, а не мозг. Разрабатывать нужно как раз мозгом, а не жопой - MBedder(08.07.2012 18:12)
- Тут не место разделять что потеет, главное в этом деле время=деньги ;) - Dir(08.07.2012 18:20)
- Потеет жопа, а не мозг. Разрабатывать нужно как раз мозгом, а не жопой - MBedder(08.07.2012 18:12)
- Между прочим, да. А в новых МК, в которых FPU уже встроен изначально и перемножение флоатов занимает несколько тактов этот путь еще и по времени выполнения предпочтителен. Dir(169 знак., 08.07.2012 18:02)
- +500 - koyodza(08.07.2012 16:11)
- Это наш народ так масштабирует? Кто такие? - Apтём(08.07.2012 15:43)
- 99% - MBedder(08.07.2012 15:51)
- такой подход тоже имеет право на жизнь ))) если ты не матёрый koyodza, то тебе проще ляпнуть во флоат, зато не будет проблем с переполнением, потерями точности и прочими проблемами - Mahagam(08.07.2012 17:53)
- Пока народ пользует флоаты для масштабирования отсчетов 10-битных АЦП - нет желания - MBedder(08.07.2012 15:38)
- Так может исходниками поделитесь с народом? - Apтём(08.07.2012 15:19)
- По скорости - многократно скорее, по объему - многократно меньше - MBedder(08.07.2012 15:17)
- А как по скорости/объёму получилось? Не поделитесь результатами сравнения стандартными решениями? - Apтём(08.07.2012 15:14)
- Для вычислений используются библиотечные функции компилятора. Причем тут AVR? Обычно для подобных МК в компиляторе есть выбор - считать float с одинарной или с двойной точностью. Хотя по стандарту операции вычислений с float должны rezident(32 знак., 08.07.2012 14:45)
- В ваших АВР, как и в любых других ваших МК, вычисления происходят исключительно с той точностью, которую удосужился реализовать тот или иной гавнокодер. Во всех моих МК вычисления происходят с точностью в один младший бит - MBedder(08.07.2012 15:08)
- В АВР вычисления происходят с одинарной точностью. Или не так? - Apтём(08.07.2012 14:09)
- Прибавить в double вы можете (более того, вычисления float как раз с удвоенной точностью происходят), но передать полученное значение во float вы уже не сможете. - rezident(08.07.2012 14:01)
- Смысл есть. Например, накопительный итог (накопленный расход) в приборе учета/расходомере. Примеры возможных ошибок и критических ситуаций при использовании float описаны по ссылке. - rezident(08.07.2012 14:05 - 14:47, ссылка)
- Хоть десятые прибавляет ито ладно. Apтём(144 знак., 08.07.2012 03:01)
- Так в курятниках float не нужен. А ничего сложнее я не делаю. - Лeoнид Ивaнoвич(08.07.2012 22:41)
- нету смысла прибавлять к миллиону одну сотую. и кстати, покажите как вам без флоатов удаётся прибавить одну сотую к миллиону ))) - Mahagam(08.07.2012 03:03)
- Точнее? Ну-ка прибавьте-ка к миллиону одну сотую :) И вообще речь не про FPU. В сообщении Dir запятая пропущена. ИМХО читать его нужно так "Как только перейдете на Cortex-ы, (то) без float-ов ..." - rezident(08.07.2012 02:45, ссылка)
- Быстрее по сравнению с МК без FPU. Точнее чем в целочисленной считать. А вы что - против FPU в МК? - Apтём(08.07.2012 02:33)
- "Быстрее/точнее" по сравнению с чем? С целочисленной арифметикой? О_о - rezident(08.07.2012 02:22)