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

[GAA]

А понял. Вы не на то обращаете внимание. С таким я справиться легко могу. Используя не Double, а в VPA. Это уже много раз обсуждалось. Дело в том, что даже использую VPA все плохо с априорными оценками, если ничего не предположить. Ещё раз, я специально все описал очень грубо, чтобы суть видна была. А обрабатывать с VPA такие вещи вроде большинство умеет.

Мне гораздо было бы интересней узнать откуда там Single/Double берутся. Мне экспериментаторы давали целые числа. (Исходные данные с оборудования.) Предположив особенности оборудования, можно как-то диапазон данных уменьшить и улучшить априорные оценки. (Я просто на аппаратном уровне с такими вещами не работал.)

-- Вт 04.05.2021 11:58:55 --

(Вообще, для 24-битного получить диапазон значений от 0 до $2^{24}$ в эксперименте не получается. Обычно всё гораздо скромнее. Не получается подобрать условия проведения эксперимента. А что-то с запредельной точностью — это уникальные эксперименты. Там над результатом годами работают, электроника уникальная, а мы в Phis.Rev. потом читаем.)

[realeugene]

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

Там над результатом годами работают, электроника уникальная, а мы в Phis.Rev. потом читаем

Я тридцать лет назад при помощи АЦП двойного интегрирования на дешевом советском операционнике, конденсаторе и коммутаторе, подключённым к 8-битной однокристалке, получал шум измерения после обработки на уровне $2^{-20}$ от измеряемого АЦП сигнала.

[Dmitriy40]

GAA
Снова Вас не пойму. У ТС числа single, т.е. в диапазоне грубо $10^{-40} \ldots 10^{40}$ и их порядка миллиарда или даже $10^{10}$ (завтра). Суммируя их в виде целых с масштабным коэффициентом $10^{40}$ будет достаточно диапазона $1\ldots 10^{90}$ или 300 битов. Не мелочиться и взять сразу 1024 бита (чтобы перекрыть от $10^{-150}$ до $10^{150}$, зачем — не спрашивайте!). Ну и всё, все вычисления сумм абсолютно точные. Погрешность среднего будет определяться выходным форматом (и количеством чисел понятно). Если нужно и квадраты точно считать, то ещё удвоить длину в битах.
Тупо, зато надёжно. И бессмысленно, realeugene прав насчёт 24 битов.

По скорости. Сложить два 1024 битных числа можно где-то со скоростью 50млн/с (на обычных 32бит регистрах). Складывать квадраты сложнее, лучше сначала возводить в квадрат (мантиссу, с удвоением порядка), а потом уже приводить к целым и складывать, это даст где-то 45млн/с. Читаться с диска будет в любом случае медленнее.

[GAA]

Предположим 24 (можно 32, не имеет значения) целые. Как и какие из них получаются Single? Они же не во всём диапазоне $10^{-40} \ldots 10^{40}$ лежат ?
Вот и не будем тупо. Зададимся количеством измерений, зададимся диапазоном значений.

Никто и не спорит с realeugene, т.к. все сами считают и приговаривают Double хватает и даже грубые оценки на коленке рисуют. Если диапазон можно ограничить, то можно дальше уточнять. Если это всё уже где-то есть, то можно просто ссылку привести. Мне интересно будет почитать.

[Dmitriy40]

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

Предположим 24 (можно 32, не имеет значения) целые. Как и какие из них получаются Single?

Это очень даже важно, 24 или 32 бита. Важно даже со знаком или без.
Если 24 бита, то и со знаком и без в single влезают без погрешностей, все числа $-2^{23}\ldots2^{24}-1$ в single представимы точно.
Если суммируется не более чем $2^k$ чисел, то достаточно иметь ещё $k$ битов слева (в целой части чисел) чтобы избежать погрешностей. Или те же лишние k битов справа (в дробной части). Что для $k=30$ практически влезает в double и значит суммирование до миллиарда целых в диапазоне $-2^{23}\ldots2^{24}-1$ каждое итоговую погрешность не увеличивает.
Деление в double суммы на количество почти не увеличивает относительную погрешность среднего.
Как конкретно кодируются числа в single и double вопрос считаю банальным, он много где подробно описан (включая и вики).

Если известен диапазон чисел и их количество, то для исключения погрешности суммы надо иметь не менее суммы битов в каждом из чисел (и всё округлять вверх). Это же тривиально, $2^{k-1}\le N<2^k$ умножаем на верхний предел диапазона чисел $0\ldots 2^b-1$ (а любой диапазон целых можно привести к такому виду) и получаем сложение количества битов $2^k \times 2^b = 2^{k+b}$ (членами второго порядка малости пренебрёг, но они гарантированно не увеличивают результат). Если располагаем меньшим количеством битов, то будет зависимость от порядка суммирования.
Вот с умножением всё гораздо хуже.

Что-то полезное можно посмотреть в той же вики1, вики2.

[realeugene]

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

Это очень даже важно, 24 или 32 бита. Важно даже со знаком или без.

Суммируйте int64 - будет не важно.

[Dmitriy40]

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

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

Это очень даже важно, 24 или 32 бита. Важно даже со знаком или без.

Суммируйте int64 - будет не важно.

Это и есть переход single $\to$ double, ну почти. А речь я так понял была про кодирование int32 в single. Хотя конечно это настолько известно что даже и непонятно в чём у GAA вопрос или проблема.
Работать же всегда в целых можно, но сложно и неудобно, и иногда попытки перекрыть все возможные варианты приводят к пересозданию аналога плавающих типов.

[GAA]

Если беззнаковые, то значения лежат в диапазоне от 0 до $2^{24}$. Пусть погрешности данных составляют $1/2^{24}$. Если сложение будет выполняться без погрешностей (идеальный вариант), то в худшем случае (все значения функции $2^{24}$) предельная абсолютная погрешность суммы будет равна 1. (Реальная погрешность вроде больше младшего разряда, но пока пусть.) Что ещё желательно учесть или это совсем не в ту строну?

-- Вт 04.05.2021 14:16:39 --

Если значения функции одного знака, то относительная погрешность мизерная. Если разных знаков, то среднее может быть близко к нулю. Ясно, что грубой оценкой абсолютной предельной погрешности пользоваться глупо. Как разумно оценить предельную относительную погрешность в этом случае?

[realeugene]

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

Что ещё желательно учесть или это совсем не в ту строну?

Можно, например, рассмотреть ситуацию, когда погрешности данных некоррелированы, имеют нулевое среднее и равномерно распределены в интервале [-0.5, 0.5], как происходит при округлении к ближайшему чётному после умножения достаточно больших чисел. Тогда ожидаемая абсолютная погрешность суммы $2^{24}$ слагаемых будет гораздо меньше единицы, её СКО будет примерно $1.15\cdot 2^{-14}$, если, конечно, не произойдут другие округления .

-- 04.05.2021, 15:23 --

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

Как разумно оценить предельную относительную погрешность в этом случае?

Предельную - так же. Более точно - с использованием статистических свойств ошибок округления, когда они известны, или когда о них можно сделать разумные предположения.

[GAA]

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

Если беззнаковые, то значения лежат в диапазоне от 0 до $2^{24}$. Пусть погрешности данных составляют $1/2^{24}$.

Сбился. Погрешность данных будет просто 1. И тогда абсолютная погрешность в худшем случае $2^{24}$. А относительная в случае значений одного одного знака --- 1 (шагу).

[realeugene]

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

Погрешность данных будет просто 1

Тогда СКО равномерно размазанной ошибки будет 0.29, а СКО ошибки суммы будет $1.15\cdot 2^{10}$.

[Dmitriy40]

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

(Реальная погрешность вроде больше младшего разряда, но пока пусть.)

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

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

Что ещё желательно учесть или это совсем не в ту строну?

Да ничего вроде, максимальное возможное значение (считая минимальное $0$) и количество слагаемых. Перемножаем и округляем вверх до степени двух (для некратных двум та моя формула может дать на 1 бит больше необходимого, например 3 числа 0..5 дают сумму всего лишь 0..15 или 4 бита, а в битах 2 бита на 3 и по 3 бита на 0..5 получается 5 битов).

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

Если разных знаков, то среднее может быть близко к нулю.

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

Вот тут (первая попавшаяся ссылка) что-то такое с формулами про погрешности операций. Но оно же должно быть и в (англо)вики, правда я не совсем понимаю как там это найти, может те две ссылки выше помогут.

[GAA]

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

-- Вт 04.05.2021 14:49:44 --

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

Это с чего вдруг?

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

[realeugene]

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

Нет, либо единице младшего разряда, либо половине её

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

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

Но независимость погрешностей экспериментальных данных, закон распределения погрешностей и т.п. с неба не падают.

У современных сигма-дельта АЦП обычно нужная статистика шума получается именно что даром. Такова их конструкция.

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

Т.е. нужно понять, чем можно характеризовать погрешности (в случае если значения функции разных знаков).

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

[GAA]

realeugene, спасибо. Общие представления есть, но пока ничего содержательного сказать не могу. Надо читать, разбираться.