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

[Atom001]

Pphantom в сообщении #1516421 писал(а):

Вполне сойдет, если только вы сколько-нибудь современный компилятор используете

Согласен. Это моё желание изучить С. На таких вот прикладных задачах смогу в какой-то мере освоить этот язык. Знать два языка лучше, чем один...

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

при накоплении статистики используйте double, а не float

Спасибо. С float, действительно, точность хуже.

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

если есть возможность, то лучше писать такие длинные файлы не в текстовые, а в двоичные: не будет тратиться время на преобразование из текстового в двоичное представление

Кстати, да. Я сначала тоже хотел в двоичном формате писать, но прибор до определённой частоты записи позволяет выбрать запись только в .txt или .csv. А уже при достаточно большом количестве точек в секунду открывается возможность сохранять данные в двоичном формате.

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

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

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


P.S. Программу дописал. Всё, что хотел получить, получил. По файлу делаю два прогона, суммарно занимает около 40-50 минут с учётом, что я параллельно сижу, например, в ютубе.

[GAA]

Dmitriy40, я себе напомню. Если не указывать последний параметр BlockRead, то, если достигнут конец файла до прочтения всей записи, при I+ будет сгенерирована ошибка ввода-вывода и прервано выполнение программы с выводом сообщения типа “Runtime error 100 at 00003D23” (консольное приложение). Если указан последний параметр, то данные будут прочитаны до конца файла и ошибка сгенерирована не будет. Можно локально отключить проверку ввода/вывода, если есть уверенность, но для надёжности указывают четвертый параметр.
Можно попробовать на таком простом примере, Delphi 5. В файл записано три байта. Читаем записями по два байта.

Используется синтаксис Delphi

const
  N = 3;
  RecSize = 2;
var
  f: File;
  i: LongInt;
  data: array[0..N-1] of byte;
  Result: Integer;
begin
  Assign(f, 'data.dat');
  Reset(f, 2);
  i:= 0;
  while not EoF(f)
    do begin
          BlockRead(f, data[i], 1, Result);
          i:= i+RecSize;
       end;
  Close(f);
end.

В общем, если файл большой и много раз происходит его обработка, то, как я и писал выше, имеет смысл записать его в двоичный.
Далее используя «классические функции» Object Pascal читать большими записями, или использовать handle-ориентированные функции ввода/вывода: FileOpen, FileRead, FileSeek, FileClose (модуль sysutils).
Современные винчестеры используют «внеочередное чтение», поэтому если запрашиваются данные большого объёма, то возможно немного ускорить чтение. Но это может усложнить программу.
Вроде всё, что около темы, обсудили. :)

[Geen]

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

Вроде всё, что около темы, обсудили. :)

Потеря точности осталась :)

[GAA]

Это, на мой взгляд, самое главное.

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

Выше (post1516486.html#p1516486) я приводил результат для значений функции, равномерно распределённых на $(0, 1]$ (значения сохранялись в текcтовом файле в формате чисел с плавающей точкой двойной точности). Выборочное среднее 4.999897489 достаточно близко к математическому ожиданию 1/2, а выборочное стандартное отклонение 0.0833274108 — к стандартному отклонению 1/12 (приближённо равному 0.0833333...). Если при чтении и нахождении средних использовать не Double, а Extended, то значения ожидаемо меняются очень слабо: выборочное среднее оказывается равным 4.999897490, а выборочное стандартное отклонение — 0.0833274107.
Можно конечно найти сумму и сумму квадратов точнее (используя большее число знаков), но такие тесты ничего интересного не говорят и у меня идей, увы, нет.

[realeugene]

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

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

Не будут. У дабла в мантиссе 53 значащих разряда. При последовательном суммировании 400 миллионов чисел сумма увеличивается на 29 двоичных разрядов. То есть от входных чисел в конце остаётся только 24 значащих разряда, чуть лучше чем у флоата. Если при сложении происходит округление усечением к нулю, что есть худший вариант, то результат после деления будет занижен до единицы младшего разряда флоата. Это вполне устраивает ТС.

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

[Geen]

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

При последовательном суммировании 400 миллионов чисел сумма увеличивается на 29 двоичных разрядов. То есть от входных чисел в конце остаётся только 24 значащих разряда, чуть лучше чем у флоата.

Это если числа распределены равномерно....
А так, достаточно одного выброса на 7 порядков чтобы всю точность убить (это для среднего, для диперсии и трёх порядков может хватить)...

[Pphantom]

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

[realeugene]

Geen в сообщении #1516602 писал(а):

А так, достаточно одного выброса на 7 порядков чтобы всю точность убить

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

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

Pphantom в сообщении #1516608 писал(а):

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

Для ТС результирующей точности флоата достаточно. Судя по тому, что входные данные у него представимы в флоате.

[geomath]

Я не понял, какая точность нужна в результате? Чисто содержательно. Может, гигабайты это избыточно и вполне достаточно мегабайтов?

[GAA]

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

Не будут.

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

По поводу априорных оценок.

Чтобы не запутаться, я себе напомню, что погрешности при обработке экспериментальных данных могут быть двух типов:
A) погрешностей измерений (о которых нам в данном случае ничего не известно);
B) погрешности вычислений;

Во втором случае грубо предположим, что предельная относительная погрешность составляет $10^{-d}$, где $d$ — приблизительно равно 7 для одинарной точности (Single) и 15 для двойной точности (Double). Здесь предполагается, что данные не содержат денормализованные значения (и банальные оговорки про $-\infty$, $+\infty$, NaN).

Поскольку о погрешностях измерений нам ничего не известно, то пока нас интересуют погрешности вычислений (B).

Предельная абсолютная погрешность суммы не превосходит суммы предельных абсолютных погрешностей слагаемых. Грубо предельная абсолютная погрешность среднего не превосходит произведения среднего на $10^{-d}$. В худшем случае предельная абсолютная погрешность не превосходит $10^{-d}\max$, где $\max$ — модуль максимального числа (Single/Double). Для Single предельная абсолютная погрешность будет не превышать $3.5\times 10^{31}$. Банально: на этом пути нужны оценки сверху модуля значений экспериментальных данных. Если значения не превышают 1, то предельная абсолютная погрешность будет меньше $10^{-d}$.
[Возражение, что при больших значениях данных мы среднее не сможем получить, т.к. произойдёт переполнение, отметается тем, что при сложении больших чисел заранее выполняется деление на число слагаемых. Технически число слагаемых можно подсчитать по известному формату двоичного файла и его размеру. Если файл текстовый, то конечно нужно знать число точек, но это обычно известно с высокой точностью: данные же сами получали.]

Если слагаемые одного знака, то предельная относительна погрешность среднего не превышает наибольшей из предельных абсолютных относительных погрешностей слагаемых. Грубо для Single предельная относительная погрешность среднего не превысит $10^{-7}$.

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

Ясно, что в практических ситуациях так плохо не бывает, но что-то нужно предположить для получения априорных оценок.

В общем, всё выше написанное в этом сообщении чудовищно банально. Содержательных мыслей у меня нет. Никаких идей из предыдущих нескольких сообщений я выудить не смог. [Вообще, всё это что-то из самого часто встречаемого на практике. Если никаких чудесных правил на все случаи жизни не предложено, то шанс быстренько предложить формулу всего очень мал. Тут, как всегда, если что-то и можно предположить, то учитывая сведения о данных.]

[realeugene]

geomath в сообщении #1516620 писал(а):

Я не понял, какая точность нужна в результате? Чисто содержательно. Может, гигабайты это избыточно и вполне достаточно мегабайтов?

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

-- 04.05.2021, 10:55 --

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

A) погрешностей измерений (о которых нам в данном случае ничего не известно);

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

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

Если слагаемые разного знака

В вашем собственном модельном эксперименте данные неотрицательные:

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

Я создал файл с целыми от 1 до 400000000 и со случайно распределёнными значениями функции от 0 до 1

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

-- 04.05.2021, 10:58 --

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

В общем, всё выше написанное в этом сообщении чудовищно банально.

Только не путайте вычматы с обработкой сигналов реального мира. При решении дифуров ошибка может чудовищно накапливаться, при подсчёте просто среднего, снятого с АЦП, дабла достаточно обычно за глаза.

[Dmitriy40]

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

Предельная абсолютная погрешность суммы не превосходит суммы предельных абсолютных погрешностей слагаемых. Грубо предельная абсолютная погрешность среднего не превосходит произведения среднего на $10^{-d}$. В худшем случае предельная абсолютная погрешность не превосходит $10^{-d}\max$, где $\max$ — модуль максимального числа (Single/Double). Для Single предельная абсолютная погрешность будет не превышать $3.5\times 10^{31}$. Банально: на этом пути нужны оценки сверху модуля значений экспериментальных данных. Если значения не превышают 1, то предельная абсолютная погрешность будет меньше $10^{-d}$.

Это не совсем так: если в данных первое число на 16 порядков больше всех прочих, то сколько бы ни было прочих они не изменят среднее ни на бит. Просто потому что каждая промежуточная сумма будет округляться к первому числу, больше не меняясь. Сколько бы ни было чисел, хоть $10^{1000}$ штук.
И предварительное деление на количество чисел не поможет, относительная разница между числами никуда не денется.
Прибавьте к единице ещё $10^{30}$ чисел $10^{-20}$, должны получить сумму $1+10^{10}$ и среднее $10^{-30}+10^{-20}$ (что вполне представимо double), а получите сумму $1$ и среднее $10^{-30}$. Хоть с предварительным делением на $10^{30}$, хоть без. При изменении порядка суммирования можно получить видимо почти любое среднее от $10^{-30}$ до $10^{-30}+10^{-20}$ (не совсем любое, а с шагом не менее $10^{-20}$ и не менее погрешности double результата). Заметьте что ошибка составила до 10 порядков! Хотя все исходные числа и все результаты вполне представимы в double.

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

[realeugene]

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

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

Потому что для ТС это не нужно.

[GAA]

Dmitriy40, я не понял Ваше уточнение/опровержение. Что и при каких условиях не совсем так. Можно выделить кусочки утверждений.
[Деление только для предотвращения переполнения. Это мелочь. Можно считать, что запустили арифметику переменной точности (VPA) и не обращать на это внимание.]

-- Вт 04.05.2021 11:17:42 --

Вот что по шагам очень неправильно:
1. Предельная абсолютная погрешность суммы не превосходит суммы предельных абсолютных погрешностей слагаемых.
2. Грубо предельная абсолютная погрешность среднего не превосходит произведения среднего на $10^{-d}$.
3. В худшем случае предельная абсолютная погрешность не превосходит $10^{-d}\max$, где $\max$ — модуль максимального числа (Single/Double).

-- Вт 04.05.2021 11:19:52 --

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

-- Вт 04.05.2021 11:22:57 --

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

-- Вт 04.05.2021 11:30:14 --

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

Прибавьте к единице ещё $10^{30}$ чисел $10^{-20}$, должны получить сумму $1+10^{10}$ и среднее $10^{-30}+10^{-20}$ (что вполне представимо double), а получите сумму $1$ и среднее $10^{-30}$.

Считайте, что запущено VPA. (Если нужны подробности, то можно использовать Matlab; выше писал «Можно конечно найти сумму и сумму квадратов точнее (используя большее число знаков)».)

[Dmitriy40]

GAA
Вы сказали что абсолютная погрешность суммы не превосходит суммы абсолютных погрешностей слагаемых, я привёл пример когда превосходит, вместо $1+10^{10}$ получили лишь $1$, сумма $10^{30}$ погрешностей $10^{-35}$ каждого слагаемого порядка $10^{-5}$, что отличается на 15 порядков.

Плюс чуть ниже Вы утверждали что для double относительная погрешность не превышает $10^{-15}$ (точнее Вы это сказали лишь про single, но про double очевидно аналогично). Но среднее $10^{-30}$ на 10 порядков меньше правильного значения! Т.е. относительная погрешность не $10^{-15}$, а аж $10^{10}$.

Ваши утверждения верны для бесконечной точности вычислений (т.е. математически) и не обязательно верны для любой конечной.

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

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

Ну вычислите в double $1+10^{-30}$ и сравните с $1$. Увидите что равно. А значит можно чисел $10^{-30}$ добавлять сколько угодно, ни в сумму ни в среднее они не войдут. Банально же. Пока чисел меньше $10^{15}$ Вы ещё можете говорить мол погрешность суммы меньше погрешности double $1$, но если чисел станет больше, то будет уже ошибочно. И чем больше чисел, тем ошибочнее.