Мне неловко об этом говорить, но WOE вы посчитали неправильно. По крайней мере, на иллюстрации в статье. Дело в том, что в колонках "% оплативших услугу" и "% не оплативших услугу" должны считаться доли от всех оплативших и всех не оплативших, соответственно. И сумма по каждой из колонок должна быть 100%. Соответственно, и значения WOE будут совсем иными.
С нулевой вероятностью. Каковы шансы, случайно выбирая точки на отрезке [0, 1], заполнить его строго равномерно (все расстояния между соседними парами точек равны)? Шансов нет.
Чтобы посчитать статистику и построить эти графики, он экспортировал историю твитов к себе на компьютер. По какой-то причине твиты за указанный период не экспортировались. Вот так и понимать.
Потерялась нумерация формулы (23), хотя дальше стоит ссылка на неё.
В формуле (24) перепутаны индексы систем координат: в левой части должен быть (1), а в правой (0).
Для bias-variance tradeoff в академической среде, кажется, закрепился перевод "смещение и разброс" (https://alexanderdyakonov.wordpress.com/2018/04/25/смещение-bias-и-разброс-variance-модели-алгорит/). Называть разброс случайной ошибкой кажется не совсем правильным, потому что могут возникнуть неверные ассоциации со случайным шумом в данных (noise), к которым разброс модели, как характеристика алгоритма, имеет лишь косвенное отношение. Хотя у Ына в принципе не совсем традиционный подход по части avoidable/unavoidable bias.
В данный момент это бесконечно далёкая от прода архитектура с точки зрения производительности. Результат продемонстрирован только на игрушечном MNIST. Засуньте её обратно в ворох шума и оставьте диванным архитекторам.
Есть у них ещё браузер Clever https://clever.mail.ru и вот выше про браузер Quantum упоминали: https://quantum.mail.ru
Не удивлюсь, если и эти четыре браузера — не полный список. Так что пост всё же юмористический.
Если исходы фреймов независимы, то оценка вероятности победы с конкретным известным нам счётом точнее, чем её приближение по вашему методу, которое не использует всей полноты информации.
Если игроки воспринимают матч как единое целое и способны максимально гибко подстраивать силу своей игры под обстоятельства, то ваш расчёт не имеет смысла, так как строится на предположении, что все варианты развития матча равновозможны.
Эти аргументы противоречат предположению о независимости исходов каждого фрейма. И тогда использованная вами оценка вероятности победы тоже не работает, потому что суммирует вероятности исходов встреч, когда игроки борются в каждом фрейме без оглядки на общий результат.
Если исходы фреймов независимы, то точнее будет подход, который я предложил. Если же игроки думают только о результате в целом, подстраивая силу игры в зависимости от текущего счёта, то обычный Эло будет точнее вашего подхода.
При расчёте вероятности победы вы суммируете вероятности всех возможных исходов. То есть, для игры до 4 побед вы суммируете вероятности исходов 4:0, 4:1, 4:2, 4:3. Но в действительности вам известно конкретное количество фреймов, выигранное каждым соперником. И вероятность победы 4:0 сильно отличается от вероятности победы 4:3 и тем более от вероятности победы с любым счётом.
Проще всего рассматривать каждый фрейм как отдельный матч для обычного рейтинга Эло, не накручивая поверх не совсем подходящее сюда распределение. Требуется только одна поправка — не обновлять рейтинги после каждого фрейма, а суммировать дельты на протяжении матча и обновлять рейтинги однократно по его завершении. Это необходимо для того, чтобы порядок взятия фреймов, который нам не известен, не влиял на результат.
Это всё, конечно, в предположении независимости исходов каждого фрейма. На что вы и сами опирались в рассуждениях.
Меняют не при подключении, а при сканировании и только для неизвестных сетей. Когда автоматом подключаются к известной — показывают честный MAC. Можно на тот же MT_FREE их ловить, ведь нам как раз нужны те, кто им пользуется.
Да все же рассказывают про свои внутренние ML-платформы: Facebook FBLearner Flow Uber Michelangelo Google TFX
Ничто из этого нельзя потрогать снаружи, так что заманивают на работу, конечно.
С другой стороны, мы вот у себя внутри тоже платформу пилим, да и все на ML-рынке этим в той или иной степени занимаются. И я с интересом смотрю на опыт других, подмечаю интересные идеи.
Только пробегать заново по каждому окну не эффективно. Достаточно просто при сдвиге окна делать +1/0/-1 к текущему каунту в зависимости от того, добавилось ли новое "хорошее" значение к окну справа или, наоборот, ушло из окна слева. Ниже уже и реализацию соответствующую привели.
Одной перестановкой на каждый пропуск не отделаешься, за ней целый паровоз перестановок поползёт. Надо просто сначала посчитать количество "хороших" значений <= k, а потом пройтись окном размера k по всему массиву, считая количество попаданий "плохих" значений в каждое окно. Минимум и будет ответом — это значит, что в данном окне нужно перестановками заменить "плохие" значения "хорошими" снаружи окна.
Возможно, вы просто не изучали комбинаторику, но это чуть ли не самая известная формула. Сама конструкция называется сочетаниями из n по k: https://ru.wikipedia.org/wiki/Сочетание. В русских учебниках обычно обозначается как C_n^k. И формула традиционно записывается через факториалы: n!/(k!(n-k)!). По запросу "сумма сумм" такое вряд ли найдётся, но ведь и задача изначально сформулирована вами как выбор k ячеек из n, это и надо было искать.
Оператора вы ни о чём не просили, это настройка телефона. Значит она буквально следующее: телефон передаёт данные только в родной сети вашего оператора. Сеть телефон определяет единственно возможным способом: код страны (MCC) плюс код сети (MNC). Конечно, у Мегафона один код сети на всю страну. Он получил его от регулятора. Коды сети двузначные и в период расцвета региональных операторов их было пару десятков действующих. Но даже сейчас, если начать выдавать по коду на регион, хватит только на одного оператора. Так что настройкой на телефоне такой запрет технически реализовать невозможно.
Потому что МегаФон купил Йоту и получил от неё 2x30. А Йоте так много досталось, потому что она пошла осваивать эти частоты на много лет раньше других ещё до всякого LTE под технологию WiMAX.
Причём, монотонность, о которой вы пишете, настоящее WOE не даёт. А то, что вы посчитали, это, по сути, log odds.
Мне неловко об этом говорить, но WOE вы посчитали неправильно. По крайней мере, на иллюстрации в статье. Дело в том, что в колонках "% оплативших услугу" и "% не оплативших услугу" должны считаться доли от всех оплативших и всех не оплативших, соответственно. И сумма по каждой из колонок должна быть 100%. Соответственно, и значения WOE будут совсем иными.
С нулевой вероятностью. Каковы шансы, случайно выбирая точки на отрезке [0, 1], заполнить его строго равномерно (все расстояния между соседними парами точек равны)? Шансов нет.
Чтобы посчитать статистику и построить эти графики, он экспортировал историю твитов к себе на компьютер. По какой-то причине твиты за указанный период не экспортировались. Вот так и понимать.
Потерялась нумерация формулы (23), хотя дальше стоит ссылка на неё.
В формуле (24) перепутаны индексы систем координат: в левой части должен быть (1), а в правой (0).
Для bias-variance tradeoff в академической среде, кажется, закрепился перевод "смещение и разброс" (https://alexanderdyakonov.wordpress.com/2018/04/25/смещение-bias-и-разброс-variance-модели-алгорит/). Называть разброс случайной ошибкой кажется не совсем правильным, потому что могут возникнуть неверные ассоциации со случайным шумом в данных (noise), к которым разброс модели, как характеристика алгоритма, имеет лишь косвенное отношение. Хотя у Ына в принципе не совсем традиционный подход по части avoidable/unavoidable bias.
В данный момент это бесконечно далёкая от прода архитектура с точки зрения производительности. Результат продемонстрирован только на игрушечном MNIST. Засуньте её обратно в ворох шума и оставьте диванным архитекторам.
Есть у них ещё браузер Clever https://clever.mail.ru и вот выше про браузер Quantum упоминали: https://quantum.mail.ru
Не удивлюсь, если и эти четыре браузера — не полный список. Так что пост всё же юмористический.
Имею в виду ровно то, о чём писал выше.
Если исходы фреймов независимы, то оценка вероятности победы с конкретным известным нам счётом точнее, чем её приближение по вашему методу, которое не использует всей полноты информации.
Если игроки воспринимают матч как единое целое и способны максимально гибко подстраивать силу своей игры под обстоятельства, то ваш расчёт не имеет смысла, так как строится на предположении, что все варианты развития матча равновозможны.
Эти аргументы противоречат предположению о независимости исходов каждого фрейма. И тогда использованная вами оценка вероятности победы тоже не работает, потому что суммирует вероятности исходов встреч, когда игроки борются в каждом фрейме без оглядки на общий результат.
Если исходы фреймов независимы, то точнее будет подход, который я предложил. Если же игроки думают только о результате в целом, подстраивая силу игры в зависимости от текущего счёта, то обычный Эло будет точнее вашего подхода.
При расчёте вероятности победы вы суммируете вероятности всех возможных исходов. То есть, для игры до 4 побед вы суммируете вероятности исходов 4:0, 4:1, 4:2, 4:3. Но в действительности вам известно конкретное количество фреймов, выигранное каждым соперником. И вероятность победы 4:0 сильно отличается от вероятности победы 4:3 и тем более от вероятности победы с любым счётом.
Проще всего рассматривать каждый фрейм как отдельный матч для обычного рейтинга Эло, не накручивая поверх не совсем подходящее сюда распределение. Требуется только одна поправка — не обновлять рейтинги после каждого фрейма, а суммировать дельты на протяжении матча и обновлять рейтинги однократно по его завершении. Это необходимо для того, чтобы порядок взятия фреймов, который нам не известен, не влиял на результат.
Это всё, конечно, в предположении независимости исходов каждого фрейма. На что вы и сами опирались в рассуждениях.
Я не совсем прав, название статьи и автор упоминаются в первом абзаце. И всё же, учитывая, что это просто перевод, надо было как перевод и оформлять.
Это же просто кривой перевод довольно известной статьи: http://colah.github.io/posts/2014-03-NN-Manifolds-Topology/ Хуже всего то, что переводчик не проставил ссылку на оригинал, выставив себя автором.
Меняют не при подключении, а при сканировании и только для неизвестных сетей. Когда автоматом подключаются к известной — показывают честный MAC. Можно на тот же MT_FREE их ловить, ведь нам как раз нужны те, кто им пользуется.
Да все же рассказывают про свои внутренние ML-платформы:
Facebook FBLearner Flow
Uber Michelangelo
Google TFX
Ничто из этого нельзя потрогать снаружи, так что заманивают на работу, конечно.
С другой стороны, мы вот у себя внутри тоже платформу пилим, да и все на ML-рынке этим в той или иной степени занимаются. И я с интересом смотрю на опыт других, подмечаю интересные идеи.
Только пробегать заново по каждому окну не эффективно. Достаточно просто при сдвиге окна делать +1/0/-1 к текущему каунту в зависимости от того, добавилось ли новое "хорошее" значение к окну справа или, наоборот, ушло из окна слева. Ниже уже и реализацию соответствующую привели.
Одной перестановкой на каждый пропуск не отделаешься, за ней целый паровоз перестановок поползёт. Надо просто сначала посчитать количество "хороших" значений <= k, а потом пройтись окном размера k по всему массиву, считая количество попаданий "плохих" значений в каждое окно. Минимум и будет ответом — это значит, что в данном окне нужно перестановками заменить "плохие" значения "хорошими" снаружи окна.
Возможно, вы просто не изучали комбинаторику, но это чуть ли не самая известная формула. Сама конструкция называется сочетаниями из n по k: https://ru.wikipedia.org/wiki/Сочетание. В русских учебниках обычно обозначается как C_n^k. И формула традиционно записывается через факториалы: n!/(k!(n-k)!). По запросу "сумма сумм" такое вряд ли найдётся, но ведь и задача изначально сформулирована вами как выбор k ячеек из n, это и надо было искать.
Оператора вы ни о чём не просили, это настройка телефона. Значит она буквально следующее: телефон передаёт данные только в родной сети вашего оператора. Сеть телефон определяет единственно возможным способом: код страны (MCC) плюс код сети (MNC). Конечно, у Мегафона один код сети на всю страну. Он получил его от регулятора. Коды сети двузначные и в период расцвета региональных операторов их было пару десятков действующих. Но даже сейчас, если начать выдавать по коду на регион, хватит только на одного оператора. Так что настройкой на телефоне такой запрет технически реализовать невозможно.
Потому что МегаФон купил Йоту и получил от неё 2x30. А Йоте так много досталось, потому что она пошла осваивать эти частоты на много лет раньше других ещё до всякого LTE под технологию WiMAX.