Это какой-стеб, наверное.
Если класс клиента (уйдет, не уйдет) кодируется значениями 0 и 1, а, судя по dataframe.corr(), это так, то использование корреляционной матрицы тут вообще недопустимо: мало того что Вы притащили в анализ тестовые данные (корр. матрица по всему датафрейму) так еще и сравнили с искомым классом.
Корреляционная матрица на ранговых данных (пол, местоположение, наличие кредитной карты) должна использовать корреляцию Кендалла, а не Пирсона по умолчанию. Мало того невозможно найти корреляцию между ранговыми и непрерывными полями данных — это сути корреляции противоречит!
Корреляция не показывает, какие данные повлияют на результат, она используется для нахождения сильно линейно зависимых друг от друга признаков, которые, при использовании линейных моделей, начнут «перетягивать» на себя коэффициенты линейного уравнения, что снизит точность модели. Потому, обычно, один из таких признаков исключают.
А в целом, статья непонятна начинающему, не имеет объяснений — Вы даже классификатор не описали!!, оперирует неверными понятиями и учит плохому. Дети, не делайте так.
При разработке системы автозаказа как-то пришлось перепробовать массу вариантов. Лучшим (и на практике, и в теоретическом объяснении) был такой:
1) взять продажи за последнюю неделю и найти по ним медиану
2) выставить верхнюю доверительную границу медианы (95%): использовал формулу для среднего выборки, но вместо среднего ставил медиану. По сути, это и будет необходимый запас товара на день, который покроет спрос.
3) если товарного запаса не хватает на время, необходимое для доставки — дозаказать полуторакратное количество от необходимого на этот период (это чтобы поставщика не гонять слишком часто)
Тут медиана позволяет избежать случайных всплесков (как и у вас), но при этом реагирует на начало и конец сезона где-то за 4 дня, автоматически и не смотря на предыдущие сезоны.
Система отлично себя показывала на исторических данных как для товаров, которые продаются по 4 шт. на месяц, так и для тех, что берут по 6 шт. на день. Жаль, в применение не пошла…
Вы можете предоставить информацию о зависимости мощности от массы?
В мышцах, например, при масштабировании масса увеличивается в кубе, а мощность в квадрате. Если и тут так, до «на порядок» не дотянет (повышение в 6,25-9 раз)
Спасибо. Я думал о таком сравнении векторов, но это было бы в ущерб наглядности.
А по поводу второй части комментария: не хотелось выдумывать новый алгоритм генерации входящей сетки при наличии приемлемого варианта с доработкой напильником. К тому же каждая конфигурация сетки обсчитывается для конечной задачи гараздо дольше, потому не видел смысла экономить на мелочах.
Да действительно. В статье переводы с 14-ричной СС и обратно показаны для наглядности критерия симметрии.
А вектор и так меняется итератором из itertools.product, а не строится заново.
Расчеты еще не закончены, но некоторые результаты есть
Best efficiency: 3.000000
__________________
____TR____________
____U1____________
____TR____________
____CV____________
____OV____________
Total EU output: 15.00 EU/t average.
Efficiency: 3.00 average.
Best EU output: 25
____U1____________
____AV____________
__________________
____U2____________
____CV____________
____OV____________
Total EU output: 25.00 EU/t average.
Efficiency: 1.67 average.
Легенда:
U1, U2 — Fuel Rod, Dual Fuel Rod
TR — Thick Neutron Reflector
AV — Advanced Heat Vent
CV — Component Heat Vent
OV — Overclocked Heat Vent
Это за 10-14 ночей работы. Может и попадались после них лучшие варианты, но я намеренно вставил нижнюю планку эффективности 3.00 и выхода 60 EU/t, потому что такая конфигурация известна. Она на КПДВ, кстати.
Последняя расчитанная конфигурация № 1720407652. Ее результат: остановлена из-за большой генерации тепла (548 HU/s)
функция write_flie 1000 раз вызывает get_users с id из своего диапазона раз в полсекунды, полученый список сериализирует и пишет в файл папки(книги) с помощью pickle.dump
функция write_book создает папку, файлы в ней и 100 раз вызывает write_flie для своего диапазона id
главная функция выполняет write_book в pool.apply_async 33 раза, запуская 33 асинхронных пула (фактически только 2 или 4 одновременно, по количеству процессоров, остальные ждут в очереди)
Сборка
собираем записи из одного файла книги (100 000 записей) в один датафрейм с помощью pandas, удаляем лишние столбцы, оставляя id и номер телефона, удаляем пустые строки и пишем в датафрейм книги
чистим датафреймы книги от мусора (буквы, знаки и т.д.), пишем его в общий датафрейм. У меня вышло где-то миллион записей
Валидация
Используя phonenumbers.parse три раза с параметрами страны None, "RU" и "UA" (можно еще стран добавить), записываем номера в три колонки. Потом чистка от совпадений пар (id, number) для трех колонок тем же pandas и запись в один датафрейм на 2 колонки (id, номер). Для одного id могут быть разные номера при валидации для разных стран.
Примечание: такая разбивка по файлам и фреймам, и поэтапный процесс сборки в один фрейм нужна для предотвращения вылета программы из-за нехватки памяти.
Как-то парсил номера телефонов первых 330 миллионов пользователей VK. Для валидации номеров использовал библиотеку phonenumbers на Python. Библиотека позволяет проверить номер как мировой (с +) так и для страны, дописывая код страны в нужное место. Получение номеров с vk.api заняло где-то 2 недели в 4 потока и день на обработку (убрать текст, малую длину номера и т.д), вышло около 1.5 миллиона записей с привязкой к id.
Для номинальных переменных используются критерии сходства на базе теста хи-квадрат.
Если класс клиента (уйдет, не уйдет) кодируется значениями 0 и 1, а, судя по dataframe.corr(), это так, то использование корреляционной матрицы тут вообще недопустимо: мало того что Вы притащили в анализ тестовые данные (корр. матрица по всему датафрейму) так еще и сравнили с искомым классом.
Корреляционная матрица на ранговых данных (пол, местоположение, наличие кредитной карты) должна использовать корреляцию Кендалла, а не Пирсона по умолчанию. Мало того невозможно найти корреляцию между ранговыми и непрерывными полями данных — это сути корреляции противоречит!
Корреляция не показывает, какие данные повлияют на результат, она используется для нахождения сильно линейно зависимых друг от друга признаков, которые, при использовании линейных моделей, начнут «перетягивать» на себя коэффициенты линейного уравнения, что снизит точность модели. Потому, обычно, один из таких признаков исключают.
А в целом, статья непонятна начинающему, не имеет объяснений — Вы даже классификатор не описали!!, оперирует неверными понятиями и учит плохому. Дети, не делайте так.
1) взять продажи за последнюю неделю и найти по ним медиану
2) выставить верхнюю доверительную границу медианы (95%): использовал формулу для среднего выборки, но вместо среднего ставил медиану. По сути, это и будет необходимый запас товара на день, который покроет спрос.
3) если товарного запаса не хватает на время, необходимое для доставки — дозаказать полуторакратное количество от необходимого на этот период (это чтобы поставщика не гонять слишком часто)
Тут медиана позволяет избежать случайных всплесков (как и у вас), но при этом реагирует на начало и конец сезона где-то за 4 дня, автоматически и не смотря на предыдущие сезоны.
Система отлично себя показывала на исторических данных как для товаров, которые продаются по 4 шт. на месяц, так и для тех, что берут по 6 шт. на день. Жаль, в применение не пошла…
В мышцах, например, при масштабировании масса увеличивается в кубе, а мощность в квадрате. Если и тут так, до «на порядок» не дотянет (повышение в 6,25-9 раз)
исход такого случайного события нельзя угадать быстрее, чем брутфорсом, в худшем случае.
Т.е. не существует алгоритма, который хоть как-то может уменьшить количество вариантов, необходимых для угадывания результата события.
14 * 14 *...* 14 = 1418
>>… помимо зеркального отражения…
Позволю себе поправить: зеркальное отражение — это осевая симметрия.
А по поводу второй части комментария: не хотелось выдумывать новый алгоритм генерации входящей сетки при наличии приемлемого варианта с доработкой напильником. К тому же каждая конфигурация сетки обсчитывается для конечной задачи гараздо дольше, потому не видел смысла экономить на мелочах.
А вектор и так меняется итератором из itertools.product, а не строится заново.
__________________
____TR____________
____U1____________
____TR____________
____CV____________
____OV____________
Total EU output: 15.00 EU/t average.
Efficiency: 3.00 average.
Best EU output: 25
____U1____________
____AV____________
__________________
____U2____________
____CV____________
____OV____________
Total EU output: 25.00 EU/t average.
Efficiency: 1.67 average.
Легенда:
U1, U2 — Fuel Rod, Dual Fuel Rod
TR — Thick Neutron Reflector
AV — Advanced Heat Vent
CV — Component Heat Vent
OV — Overclocked Heat Vent
Это за 10-14 ночей работы. Может и попадались после них лучшие варианты, но я намеренно вставил нижнюю планку эффективности 3.00 и выхода 60 EU/t, потому что такая конфигурация известна. Она на КПДВ, кстати.
Последняя расчитанная конфигурация № 1720407652. Ее результат: остановлена из-за большой генерации тепла (548 HU/s)
Может только эта делегация собиралась в спешке и налегке. Остальные же взяли с собой другую одежду, и имели возможность переодеться.
>> 2) Странно, что полный борт туристов не прочёл особенности эксплуатации и не слышал о такой особенности ранее от других.
Ну тут мне ничего не придумать…
Общий смысл такой:
Считывание
Сборка
Валидация
Используя phonenumbers.parse три раза с параметрами страны None, "RU" и "UA" (можно еще стран добавить), записываем номера в три колонки. Потом чистка от совпадений пар (id, number) для трех колонок тем же pandas и запись в один датафрейм на 2 колонки (id, номер). Для одного id могут быть разные номера при валидации для разных стран.
Примечание: такая разбивка по файлам и фреймам, и поэтапный процесс сборки в один фрейм нужна для предотвращения вылета программы из-за нехватки памяти.