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

Поправка, в последнем абзаце следует читать:
...для события A1 у нас и будет искомое множество.

Давайте с основ.
Множество элементарных событий = {w1 - избератель выбрал 1 пункт в бюллетене, w2 - избератель выбрал 2 пункт в бюллетене, итд}

Дальше смотрим что такое случайная величина - это функция из множества элементарных событий в множество вещественных чисел, отвечающая некоторым условиям.

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

В тех же исследованиях, которые вы опревергаете, дело обстоит чуть иначе.
Там исследуется случайная величина - число проголосовавших за конкретную партию на конкретном участке.
Т.е. берутся данные по одному участку, определяется событие A1 = {w1}. Далее для простоты введем индикаторную величину Ik = 1, если при kтом опыте событие A1 произошло, Ik = 0, если не произошло.
Далее берем случайную величину F = сумме Ik.
И вот когда мы возмем множество таких случайных величин, по всем участкам для события A у нас и будет искомое множество.

а какое количество малых участков? (скажем не более 300 избирателей)
мне кажется такие участки обеспечивают от силы 1-2 процента от общего числа избирателей.

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

Я проверял собственную идею про 2/3, потому что это такое место, до которого искусственно накручивать было бы странно (ровно до 66.7 для бина 0.1, а не 67)

Но как нам тут ниже подсказывают, на 1/5 и 1/4 пики есть и у "партии Гаусса"

психи! только запутали...

Потому что они в internal/libraw_internal_func.h
Как и прочие служебные, коим даже в derived class не нужно пользоваться.

Мешает - перенесите в libraw_h, если надо.

Ну если очень хочется включить туда libraw.h, включите его под #ifndef LIBRAW_LIBRARY_BUILD

Редактор это увидит, а компилятор - нет.

Ну так и не надо его включать в проект.

Потому что, из demosaic_packs.cpp:
#include "./wf_filtering.cpp"

И все 3rd-party включено так же, мне так удобнее.

Да, станет.

Но в реальной жизни процедура распаковки вообще парит мало, все уходит в демозаику.

Ну, если хочется чтобы на int всё-таки был дебандинг, то придётся пока так. Кстати, на фуджи я вообще не рассчитывал, как его отсечь?

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

Hmm, ну надо будет попробовать, раз больше полуметра едут. Я тоже бегун не особый, у меня жена по этой части, вот на ней мазать и учусь :) Стараюсь по свежести и влажности снега ориентироваться. По теплу, конечно сложнее, а на морозы v20 вроде нормально, v05 мазал только раз или два. Может с жесткостью что не то... Кстати, парафином я колодку не мажу, только под конёк, а конёк у нас редок.

В смысле - "вычитай не хочу"? Ну да, там есть, насколько я понял, вся плоскость raw файла.

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

Ну, тоже вариант - склонировать текущий dcraw_emu, и поменять там всё.

Можно еще поискать peltonen nanogrip - у них подошва как мелкий наждак, при этом после полукилометра отлично скользят вперед и не скользят назад (поднимался на них по склону градусов сорок пять). Но дороже обычных Фишеров раза в полтора.