Black Cat Theory
Jun. 5th, 2018 06:38 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_r
Опять про выборы. После того, как написал про теорию чёрного кота, увидел статью про целочисленную аномалию и спросил, как они считают целочисленный процент.
Наконец-то, нашёл время посмотреть. Да! Оно работает.
| last digit | count of uiks int percent putin |
| 0 | 1062 |
| 5 | 327 |
| 6 | 87 |
| 2 | 85 |
| 8 | 78 |
| 4 | 72 |
| 1 | 12 |
| 3 | 7 |
| 7 | 5 |
| 9 | 1 |
В этой весёлой табличке в первой колонке стоит последняя цифра в явке.
Напоминаю, явка - это число, которое складывается из всех бюллетеней, то есть из чисел бюллетеней:
- выданных избирателям, проголосовавшим досрочно
- выданных в помещении для голосования в день голосования
- выданных вне помещения для голосования в день голосования
Вторая колонка - это число УИК, у которых явка как сумма трёх вышеназванных чисел оканчивается на эту цифру.
А вырезает запрос УИКи по простому правилу: число голосов за путина составляет целый процент от числа голосовавших, кроме тех случаев, когда это 100%:
WHERE
-- integer percent in putin
100.0 * n_putin % n_golosov = 0.0
AND
n_putin < n_golosov
Число голосов тоже не стоит в протоколе УИК, а является суммой двух чисел бюллетеней:
- недействительных
- действительных
(В протоколе есть ещё утраченные.)
Короче, чтобы получить целый процент голосов у путина, явку делают удобной для математики руками. Причём, если исключить УИК с целочисленным процентом у путина, аномальное число УИК с явкой, заканчивающейся нулём, становится вполне средним.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2018-06-05 06:04 pm (UTC)а какой смысл-то? неужели 1230 лучше 1234 для рисования 85% за Пу?
no subject
Date: 2018-06-05 06:46 pm (UTC)У меня ощущения, что целый процент делают только лентяи, а нарисовано процентов 20 чисел. Большинство просто приписывает процент немного больше требуемого. Но софт, проверяющий эти ощущения, я написать сейчас не возьмусь.
неужели 1230 лучше 1234 для рисования 85% за Пу?
Если бы это было два числа, то без разницы. Когда чисел много, одно надо отнимать, другое - делить, третье - складывать, так что подставляют те числа, которые проще считаются. Иначе что-то может не сойтись.
В принципе, я ожидал чего-то странного, но не настолько. У меня в планах проверить вариант для двух последних. Но там всё поскромнее выходит.
Кстати, открыл базу, сделал запрос сколько УИК сколько утраченных бюллетеней отрапортовали. Тоже смешные цифры
SELECT n_utrachennyh , count(*) FROM temp.table_227_level_3 GROUP BY n_utrachennyh ORDER BY 2 DESC ; --no subject
Date: 2018-06-05 06:55 pm (UTC)no subject
Date: 2018-06-05 07:12 pm (UTC)no subject
Date: 2018-06-05 07:56 pm (UTC)Я сам не понимаю, что первично. Собственно, об этом я тогда и спрашивал.
Если, скажем, явку нарисуют равной 100, то процент у Путина будет целым без калькулятора. А 100 - это самое популярное число, самая вершина горба и оттуда ещё вверх выброс.
Сейчас посмотрю, что с двумя цифрами.
Вот первая дюжина пар при целочисленном проценте у путина
Вот первая дюжина при вырезанном целочисленном проценте у путина
Соответственно, последняя дюжина
Понятно, что в вырезанном 00 и 50 внизу. Но 10 всплыла наверх. Про 77 я уже писал.
Я вижу, что тут нечто странное. Но выяснять, что именно, потребует написать гораздо больше, чем пара лишних строчек в SQL запросе, потому что придётся таблицы не только выдавать, но и сравнивать, при этом высчитывая вероятность. А это уже совсем другая сложность.
no subject
Date: 2018-06-05 08:29 pm (UTC)no subject
Date: 2018-06-06 11:10 am (UTC)Если в расчётах нет ошибок, можно сделать какие-нибудь выводы.
no subject
Date: 2018-06-07 07:42 pm (UTC)Тут я просто на голубые столбики с количеством УИК, где у Путина не целый процент (с дельтой), поставил красные, где в плюс-минус дельту от целого процента попадает.
В районе явки порядка тысяч количество целочисленных путиных в пределах десятка, но те столбики, где 00 на конце чуть выше соседних. То есть, аномалия может и там накапливаться.
no subject
Date: 2018-06-05 07:27 pm (UTC)Я проделал расчет в точности, как у Вас написано и получил вот что:
https://i.imgur.com/rCsFx6B.png
no subject
Date: 2018-06-05 07:58 pm (UTC)no subject
Date: 2018-06-05 08:11 pm (UTC)Тут написано, что остаток от деления числа голосов за путина на сумму действительных и не действительных бюллетеней должен быть меньше дельты 0.05
Мне сказали, что считать так. Я переспрашивал.
no subject
Date: 2018-06-05 08:12 pm (UTC)no subject
Date: 2018-06-05 08:23 pm (UTC)Формула не верная. Она не дельту вырезает, а только целые проценты.
no subject
Date: 2018-06-05 08:15 pm (UTC)Вы считаете остаток от деления целого числа (100.0 * n_putin) на целое число (n_golosov). Он может быть только целым числом. Меньше 0.05 он будет только если он равен нулю. Это совершенно не то, что нужно. Тут какое-то недопонимание.
no subject
Date: 2018-06-05 08:17 pm (UTC)abs(100*n_putin/n_golosov - round(100*n_putin/n_golosov)) < 0.05
но в SQL я не знаю, как это правильно написать.
no subject
Date: 2018-06-05 08:32 pm (UTC)Ещё раз спасибо.
no subject
Date: 2018-06-05 09:25 pm (UTC)AND 100.0 * n_putin / n_golosov % 1 < 0.05 -- AND -- 100.0 * n_putin / n_golosov % 1 > 0.0 AND n_putin < n_golosovВторая колонка - с дельтой, третья то, что <0.05 за исключением того, где точное попадание в 0.0
Похоже на правду?
no subject
Date: 2018-06-05 09:28 pm (UTC)no subject
Date: 2018-06-06 08:26 am (UTC)Вот таблица.
Вот на всякий случай код. Вроде, на этот раз без ошибок.
-- -- integer percent in javka -- AND -- ( -- -0.05 < x < 0.05 -- 100.0 * n_javka / n_spisok % 1 > 1 - 0.05 -- OR -- 100.0 * n_javka / n_spisok % 1 = 0.00 -- OR -- 100.0 * n_javka / n_spisok % 1 < 0.05 -- ) -- -- AND -- n_javka != n_spisok -- -- integer percent in putin -- AND -- ( -- -0.05 < x < 0.05 -- 100.0 * n_putin / n_golosov % 1 > 1 - 0.05 -- OR -- 100.0 * n_putin / n_golosov % 1 = 0.00 -- OR -- 100.0 * n_putin / n_golosov % 1 < 0.05 -- ) -- -- AND -- n_putin != n_golosov -- -- remove integer percent in javka -- AND -- ( -- not in delta or is exact 100% -- ( -- x <= - 0.05 OR 0.05 <= x -- 100.0 * n_javka / n_spisok % 1 <= 1 - 0.05 -- AND -- 100.0 * n_javka / n_spisok % 1 != 0.00 -- AND -- 100.0 * n_javka / n_spisok % 1 >= 0.05 -- ) -- -- OR -- n_javka = n_spisok -- ) -- not in delta or is exact 100% -- -- remove integer percent in putin -- AND -- n_golosov > 0 -- protect against division by zero -- AND -- ( -- not in delta or is exact 100% -- ( -- x <= - 0.05 OR 0.05 <= x -- 100.0 * n_putin / n_golosov % 1 <= 1 - 0.05 -- AND -- 100.0 * n_putin / n_golosov % 1 != 0.00 -- AND -- 100.0 * n_putin / n_golosov % 1 >= 0.05 -- ) -- -- OR -- n_putin = n_golosov -- ) -- not in delta or is exact 100%no subject
Date: 2018-06-06 10:54 am (UTC)Я решил, что логично добавить не только левую и правую дельту, но и участки с нецелым процентом такой же ширины. Вот какая табличка вышла.
0.33 - это 1/3, а справа от 0.4 ничего интересного нет.
Так в интервале вокруг 0.333...
с последним 0 выдаёт 263 УИК
, у 5 - 127 УИК
, у 6 и других чётных около 50
, у нечётных - в районе единиц.
(Я добавил код внизу комментария.)
График распределения последней цифры в явке третья картинка тут. И моя гипотеза состоит в том, что это вызвано психологическими причинами (плюс, плохим знанием математики).
WHERE n_golosov > 0 -- protect against division by zero AND 100.0 * n_putin / n_golosov % 1 < 0.333333333333334 AND 100.0 * n_putin / n_golosov % 1 > 0.333333333333333no subject
Date: 2018-06-08 05:44 am (UTC)В результате, у нуля в плюс-минус дельту попадает в три раза больше, чем у остальных.
И кратные 5% пики при последнем 0 дают 40.5% случаев всех целочисленных процентов и порядка 20% при других последних цифрах.