Свежие комментарии

>отношение сигнал/шум на диапазоне 5000-14700 (верхние полтора стопа) перестает падать
в смысле - перестает? шум (мощность шума) растет вместе с сигналом?

>120 - это корень из значения (14700).
не понял - зачем брать квадратный корень из [максимального] значения сигнала?
наверное у меня какие-то пробелы в математике...

>И пуассоновское распределение при большом числе самплов - "переходит" в нормальное.
а в википедии :) написано "Сумма независимых пуассоновских случайных величин также имеет распределение Пуассона"

120 - это корень из значения (14700). Для Пуассононовского распределения (фотонный шум) - в самый раз.
И пуассоновское распределение при большом числе самплов - "переходит" в нормальное.

А вот то, что отношение сигнал/шум на диапазоне 5000-14700 (верхние полтора стопа) перестает падать - меня удивляет и я думаю.

Ну да, мантиссы - 24 бита (не помню, включает это знак или нет, но скорее всего 23 бита и знак). Это в float.
А в double - битов 48 или около того.

Но в float - 4 действия, а в double - одно, при этом double всего-то вдвое медленнее.

практикуют с этой целью маньякусы.
Т.е. из 2**К чисел получают 2**(К-1) промежуточных сумм (попарных) итд итп ипкнх.

Ты уже купил Дюну, но я всё равно скажу.
Я тут себе взял ASRock Vision 3D ( http://www.asrock.com/Nettop/overview.asp?Model=Vision%203D%20Series ) и очень им доволен.

В вариации float/double (у обоих есть аппаратная поддержка) - это бессмысленно.

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

Но если не хватает double, то да, спасет.

У меня это место подетектилось только когда я в варез загнал заранее известные *константные* значение (то самое 59259).

Так как там минимум-максимум-среднее выводятся рядом, то вот оно и вылезло.

Все чаще убеждаюсь, что все уже придумано до нас. :-)


main ()
{
unsigned short v=59259;
float a=0.0f;
double b=0.0;
// float divider=100000.0;
// float divider=50000.0f;
float divider=1.0;
int i;

float c = 0.0f; //A running compensation for lost low-order bits.
float t;
float y;
float sum = 0.0f;

for(i=0;i<33*33;i++)
{
a+=v/divider;
b+=v/divider;
}
a*=divider;
b*=divider;
printf("%.15g a=%.15g b=%.15g a-b=%.15g int=%d iter=%d\n",(a-b)/(33*33), a, b, a-b, v*33*33, 33*33 );

// Vsjo pridumano do nas
a=0.0f;
b=0.0;
for(i=0;i<33*33;i++)
{
// a+=v; // see below
y = v - c; //So far, so good: c is zero.
t = sum + y; //Alas, sum is big, y small, so low-order digits of y are lost.
c = (t - sum) - y; //(t - sum) recovers the high-order part of y; subtracting y recovers -(low part of y)
sum = t; //Algebraically, c should always be zero. Beware eagerly optimising compilers!
//Next time around, the lost low part will be added to y in a fresh attempt.
b+=v;
}
a = sum;
printf("%.15g a=%.15g b=%.15g a-b=%.15g int=%d iter=%d\n",(a-b)/(33*33), a, b, a-b, v*33*33, 33*33 );

}

0.73921028466483 a=64533856 b=64533051 a-b=805 int=64533051 iter=1089
0.000918273645546373 a=64533052 b=64533051 a-b=1 int=64533051 iter=1089

Правда операций чуть побольше.

В-общем, получается так, если не по формальным спекам, а по наличию в магазинах: салазок для C200, которые позволяют и BD и 3.5" диск поставить - в Москве нет.
Более того, там где такие штуки обычно были (mnt.ru) - я тоже что-то не нашел.

А у Дюны Max - про это голова не болит т.к. отсеки разные.

Зато в Дюну не ставится (пока?) Mini-PCI Wifi, USB-шные, по слухам, медленнее, т.е. про HD по воздуху придется забыть скорее всего. Ну и хрен с ним, значит, будем приносить на HDD.

А я тут давеча слышал вопль души по направлению к Интел и АМД "ну когда же в процессорах будет поддержка четверной точности". Не хватает кое-кому уже double.

Иманна-иманна...

Вот тут или на худой конец тут как гриццо совершенно famous article на этот счёт

Да, лажаю. :-(

Я не понимаю вашего кода. Вот смотрите:
float avg=0.0f;
int i;
for(i=0;i<1000;i++)
{
float a = i;
if(i) { avg = (avg+a)/2.0f; } else { avg+=ф;}
}
printf("%g\n",avg);

Это же то же самое делает?

Но оно не среднее печатает, отнюдь.

Я думал, что libraw, в перспективе, и претендует стать самостоятельным raw процессором.

Нет-нет. Эту тему мы обсуждали в самом начале и решили что нет, не претендуем. RAW-процессор *как библиотека* (т.е. приделывай свой GUI и радуйся) это какая-то неправильная штука. Или она будет слишком generic (и потому - медленной), либо там нужна какая-то строгая идеология процессинга, а тогда и GUI можно приделать свой (и исходники открывать необязательно).

Нет, этот самый постпроцессинг достался на халяву из dcraw, немножко разросся в последние полгода, но сильно развивать это место (на сегодняшний день) не планируется.