Чем обработать 8 Гб данных?

[Dmitriy40]

Можно брать относительную погрешность не относительно точного значения, а относительно максимально возможного значения (для знаковых данных удобно брать полный размах/диапазон, особенно если он не симметричен относительно нуля, например температуру часто ограничивают интервалом $-50°C\ldots+150°C$), так маркируют измерительные приборы, в процентах от полной шкалы, а не от текущих показаний. Это удобно тем что погрешность не зависит от величины, фактически становясь абсолютной. Те самые LSB.
Но для плавающих форматов это категорически неверно, именно из-за перемещения десятичной/двоичной точки. И у них более-менее сохраняется (плавает вдвое) именно относительная погрешность, относительно текущей величины.

И кстати, вот Вы брали целые числа в диапазоне $0\ldots 2^{24}-1$ и считали их погрешность как $2^{-24}$, но ведь в плане относительной погрешности это верно только для чисел около $2^{24}$, для меньших чисел относительная погрешность выше даже для исходных чисел, без всяких вычислений! И складывая числа $50$ c относительной погрешностью 1% и $2$ с относительной погрешностью 25% по правилам должны получать результат с относительной погрешностью тоже 25%, или $52\pm13$! Но это явно же глупость ... Правильно было бы считать не относительные погрешности, а абсолютные, $50\pm0.5 + 2\pm0.5 = 52\pm1$ или 2%.

-- 04.05.2021, 16:07 --

realeugene в сообщении #1516716 писал(а):

Нет, абсолютная погрешность измерений реального АЦП

Я нигде не упоминал АЦП и говорил лишь о представлении чисел в компьютерах и при вычислениях. Метрологические параметры АЦП это отдельная тёмная тема и я не уверен что понимаю её достаточно.

[realeugene]

Dmitriy40 в сообщении #1516719 писал(а):

И складывая числа $50$ c относительной погрешностью 1% и $2$ с относительной погрешностью 25% по правилам должны получать результат с относительной погрешностью тоже 25%,

При сложении величин с ошибками суммируется абсолютная погрешность, а не относительная.

[Dmitriy40]

realeugene в сообщении #1516721 писал(а):

Dmitriy40 в сообщении #1516719 писал(а):

И складывая числа $50$ c относительной погрешностью 1% и $2$ с относительной погрешностью 25% по правилам должны получать результат с относительной погрешностью тоже 25%,

При сложении величин с ошибками суммируется абсолютная погрешность, а не относительная.

Я знаю, и взял не сумму, а максимум, ровно по правилам.

[realeugene]

Dmitriy40 в сообщении #1516719 писал(а):

Я нигде не упоминал АЦП и говорил лишь о представлении чисел в компьютерах и при вычислениях.

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

[Dmitriy40]

realeugene
Криптография на значениях АЦП это сильно, да.

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

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

[realeugene]

Dmitriy40 в сообщении #1516729 писал(а):

Когда исходные данные с погрешностями, полезно посчитать несколько раз с добавлением случайной ошибки порядка погрешности в данные, результат должен оставаться стабильным (в пределах соответствующей погрешности, которую реальную часто как раз так и можно неплохо оценить).

Что не гарантирует отсутствия округления до одного старшего разряда где-нибудь внутри алгоритма. В общем, в более-менее сложных случаях гарантий никаких, кроме грамотности и аккуратности инженеров, разрабатывавших этот алгоритм.

[GAA]

Виноват. Тут выше я зря поправлялся. 24 бита. Предельная абсолютная погрешность каждого слагаемого (значений функции) будет равна единице. Сумма же этих единиц даст $n$ и предельная абсолютная погрешность среднего будет равна 1 (складываем без погрешностей). Это соответствует формулировке realeugene о точности float.

GAA в сообщении #1516578 писал(а):

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

Учет вида данных, конечно, сильно уменьшил величину этой предельной абсолютной погрешности. Однако предельная абсолютная погрешность в таком случае не зависит от формы сигнала, т.е. дальше, в общем случае, улучшить, скорее всего, не получится.

Спасибо за подсказки и замечания!

[Dmitriy40]

realeugene
Да, даже до знака или перманентного зануления не гарантирует.
А если помнить сколько всего не гарантирует стандарт С/С++ (я не помню), то проще и не писать ничего. И считать в Excel (уж он то точно гарантирует всё что угодно! ) кусочками по 10000 строк.

[Geen]

Возможно стоит выслушать ТС о природе его задачи? А то можно сильно не в ту сторону уйти.

[Atom001]

realeugene в сообщении #1516628 писал(а):

Но, судя по постановке задачи, ТС купил АЦП пошустрее и запустил его собирать данные на подольше. А теперь перед ним встала задача хоть как-то обработать это всё.

Не, частота как раз-таки была снижена до минимально возможного в эксеприменте предела. Объём конечного файла обеспечивается длительностью записи: многие и многие часы без возможности прервать запись, чтобы разделить файлы.