Здесь можно немножко помяукать :)
https://radiokot.ru:443/forum/
а при чем тут потеря точности, если мы говорим о делении на 0? или вы считаете нормальным писать такие алгоритмы, которые ДОПУСКАЮТ ситуацию деления на ноль? а о фиксированной точке вообще речь не шла, если память и история темы не подводят...tonyk писал(а):Проблема потери точности, особенно в технике, совсем не надумана
Вчера на иностранном форуме попался диалог двух программистов,там один тоже хотел так выключить какую-то оптимизацию,а другой ему сказал что это так сделать не получится. Именно только включать по одному все нужные.вместо включения всех, кроме, можно оставить включенными все, но выключить один конкретный
Это я в первую очередь вчера попробовал именно из-за "registers" в названии - не помогает.я точно не уверен, но вроде бы лучший кандидат на исключение - флаг -fcprop-registers. -Og -fno-cprop-registers
Давайте сравним точность вычислений тремя методами.avr-gcc version 9.2.0 (GCC)
Код: Выделить всё
23906/(0 ... 255)Код: Выделить всё
un_pac[0] 0x021E
n 0x021E 0
m1 0x021F 65535
m2 0x0221 0
m3 0x0223 999
un_pac[1] 0x0225
n 0x0225 5
m1 0x0226 200
m2 0x0228 200
m3 0x022A 199
un_pac[2] 0x022C
n 0x022C 10
m1 0x022D 600
m2 0x022F 600
m3 0x0231 599
un_pac[3] 0x0233
n 0x0233 20
m1 0x0234 300
m2 0x0236 300
m3 0x0238 299
un_pac[4] 0x023A
n 0x023A 25
m1 0x023B 240
m2 0x023D 239
m3 0x023F 239
un_pac[5] 0x0241
n 0x0241 40
m1 0x0242 650
m2 0x0244 650
m3 0x0246 649
un_pac[6] 0x0248
n 0x0248 50
m1 0x0249 120
m2 0x024B 119
m3 0x024D 119
un_pac[7] 0x024F
n 0x024F 80
m1 0x0250 825
m2 0x0252 825
m3 0x0254 824
un_pac[8] 0x0256
n 0x0256 100
m1 0x0257 60
m2 0x0259 59
m3 0x025B 59
un_pac[9] 0x025D
n 0x025D 125
m1 0x025E 248
m2 0x0260 248
m3 0x0262 247
un_pac[10] 0x0264
n 0x0264 200
m1 0x0265 530
m2 0x0267 529
m3 0x0269 529
un_pac[11] 0x026B
n 0x026B 250
m1 0x026C 624
m2 0x026E 624
m3 0x0270 623 С точки зрения ошибок вычислений, это, по-сути, одно и то же.ARV писал(а):а при чем тут потеря точности, если мы говорим о делении на 0?
Безусловно! Алгоритм должен быть устойчив к любым ошибкам, в том числе и деления на ноль. Например, вышел из строя АЦП и тебе приходит ноль, или очень маленькое число, которое в процессе промежуточных вычислений (особенно с плавающей точкой!) превратится в ноль, на который будет попытка деления. И что, твоя программа зависнет по по ошибке или выдаст несуразный результат?ARV писал(а):или вы считаете нормальным писать такие алгоритмы, которые ДОПУСКАЮТ ситуацию деления на ноль?
Вопрос, заданный ТС:ARV писал(а):а о фиксированной точке вообще речь не шла, если память и история темы не подводят...
Так что и память тебя подводит, и знаний мало. Я предложил использовать вычисления с фиксированной точкой и выложил текст класса большого целого с динамическим наращиванием разрядности.WatchCat писал(а):Если я просто поделю одно на другое целочисленным делением (на Си) то получу число 5, что означает весьма существенную потерю
точности из-за малого числа значащих разрядов... Собственно и вопрос к присутствующим - Какие еще есть варианты решения этой задачки?... Так что если кто в этой теме хорошо разбирается - подскажите пожалуйста!
ну так можно любые ошибки свести к ошибкам вычисления... несерьёзно так обобщатьtonyk писал(а):С точки зрения ошибок вычислений, это, по-сути, одно и то же
да ладно! а т в своих проектах непрерsвный контроль ОЗУ при помощи CRC делаешь? а то ведь вдруг какое-нибудь нейтрино пролетит и ячейка ОЗУ сдохнет в одном бите...tonyk писал(а):Алгоритм должен быть устойчив к любым ошибкам
на счет знаний спорить не буду, их и вправду немного... а вот на счет памяти - не соглашусь: не смотря на формальное родство фиксированной точки с целыми числами, речь о фиксированной точке не шла.tonyk писал(а):Так что и память тебя подводит, и знаний мало
у float фиксированной точки не может быть.tonyk писал(а):с фиксированной точкой
еще бы тест выложил, тогда, ладно, поверим.tonyk писал(а):выложил текст класса
Видимо, теорию не знаешь и практики работы со сложными вычислительными средствами нет. Просто почитай, сколько ошибок вычислений формирует математический сопроцессор твоего компа, может, тогда понятней станет, сколько ты упускаешь из рассмотрения. Кстати, в результате вычислений может получиться не число.ARV писал(а):ну так можно любые ошибки свести к ошибкам вычисления... несерьёзно так обобщать
Делаю непрерывное вычисление CRC для всех видов энергонезависимой памяти, в которых хранятся уставки и программа. Всё-таки уран плавил. Это требование у нас даже в ТЗ прописывается и все управляющие контроллеры его выполняют.ARV писал(а):да ладно! а т в своих проектах непрерsвный контроль ОЗУ при помощи CRC делаешь? а то ведь вдруг какое-нибудь нейтрино пролетит и ячейка ОЗУ сдохнет в одном бите...
Да ну! ТС просил способ повышения точности вычислений. Я предложил относительно простой способ решения с использованием арифметики с фиксированной точкой, которым пользовался на практике, но ты его даже не понял. Говорю же, с математикой у тебя плохо.ARV писал(а):не смотря на формальное родство фиксированной точки с целыми числами, речь о фиксированной точке не шла.
Код: Выделить всё
1/8бит = 0,00390625
1/16бит = 0,0000152587890625
1/32бит = 0,00000000023283064365386962890625эта та длинная портянка?tonyk писал(а):относительно простой способ решения с использованием арифметики с фиксированной точкой
Это тот огромный класс на плюсах - простой способ?Я предложил относительно простой способ решения с использованием арифметики с фиксированной точкой
И да, и нет. Я отгонял математику во всех мыслимых режимах и видел, что результатов больше 70 (или 72, не помню) бит не бывает, поэтому спокойно задал начальную разрядность для чисел в 80 бит, чтобы не перекраивать память в процессе работы. Если будет нужно, могу сам задать любую разрядность чисел, хоть 40000 бит, а могу отдать на откуп классу в динамике подстраивать разрядность, что очень удобно при наладке. Так что можно промасштабировать и 1/32, и 1/32767. Конечный результат на регулятор выдаю в виде 16-ти битного числа с фиксированной точкой с двумя достоверными знаками, хотя имею честные 6.Dimon456 писал(а):Как бы ты там не наращивал - ошибка будет, ну не делится эта "штука" так как надо.
Концепция С++ как раз и заключается в том, что ты платишь только за то, что используешь. В примере, вроде, закоментарен вызов методов потокового ввода-вывода, поэтому никакого дополнительного кода из библиотек там нет и не будет.WatchCat писал(а):А еще использование плюсового класса скорее всего потащит за собой линковку в проект значительного дополнительного куска библиотечного кода.
Мне же достаточно будет написать просто #include "BigInt.h"Наверно от этого после начала внедрения плюсов на персоналках в 90е годы - весь софт сильно разжирен и затормозил.Концепция С++ как раз и заключается в том, что ты платишь только за то, что используешь.
Вот когда (и если!) понадобится - тогда я об этом и задумаюсь. У меня не промышленное изделие,в которое надо закладывать возможности дальнейшего "развития" с маркетинговыми целями - чтобы можно было продавать "новые" модели,отличающиеся прошивкой и дизайном корпуса. Так что сейчас я точно не буду разбираться с встраиванием скомпилированного плюсами модуля в свою программу на самом обычном,отчасти даже "устаревшем"(зато мне привычном) диалекте Си. Да, я знаю как такие штуки делать,но бороться с name mangling и правильным своевременным вызовом конструкторов/деструкторов сейчас совсем не хочется.Завтра понадобится вам 96-ти битная арифметика, и будете вы новые костыли выдумывать, ибо нет в Си типа данных с такой разрядностью. Мне же достаточно будет написать просто #include "BigInt.h"
а ты форумом не ошибся? ураноплавильщиков тут нет, кроме тебя, и ураноплавильные подходы тут вряд ли разумно применятьtonyk писал(а):Всё-таки уран плавил.
не можетtonyk писал(а):Кстати, в результате вычислений может получиться не число
NaN - это тоже число, из битиков который тоже поврежден предыдущим нейтрино... и, естественно, не отрабатывает из-за этого... паранойя никогда до добра не доводилаReflector писал(а):Прилетело нейтрино, один бит RAM изменился и попадаем в соответствующий обработчик прерывания
тут ураноплавильщик недавно доказывал, что не только можно, но и нужно! программа должна работать правильно всегда, невзирая на любые ошибки, неисправности и вообще на выключенном МКAlexS4 писал(а):сделать программу надежно работающую на неисправном компьютере для общего случая невозможно
не уверен, но подозреваю, что и на непрошитом тоже...уран в пятерочку завезут по дешевке? никому из здесь присутствующих, даже такому гуру, как Reflector, никогда не понадобится такая арифметика... во всяком случае в контексте pet-проектов, т.е. любительстве, о чем мы тут все (кроме тебя) и говоримtonyk писал(а):Завтра понадобится вам 96-ти битная арифметика, и будете вы новые костыли выдумывать
Ну с некоторой вероятностью тут могут пастись какие-нибудь студенты-дипломники или аспиранты,которым может потребоваться что-нибудь в лабораторных экспериментах померить и посчитать. А больших денег на оборудование у них нет,так что вполне могут паять и программировать сами. Или это вообще может быть темой дипломной/научной работы - создание такого измерителя. Так что то,что профессионал поделился здесь примером кода промышленного уровня - это не плохо. Молодым будет с чего брать пример. А то ведь вообще на каком-нибудь php написать могут или там яваскрипте.никому из здесь присутствующих, даже такому гуру, как Reflector, никогда не понадобится такая арифметика...
так было же сказано, для чего: уран плавить!Dimon456 писал(а):вопрос - для чего?
ну, это, как я понимаю, просто традиция неприятия printf... я для себя её сломал давно, и в случаях, когда результат важнее размера прошивки, использую printf и для ЖКИ тожеWatchCat писал(а):в микроконтроллерных поделках как правило вывод на индикатор не через printf делается