Обработка и очистка будет дальше. Как и логистическая регрессия. Для пробного использования CatBoost никакая особая подготовка данных не нужна, поэтому её не было. CatBoost разбивает признаки на бины и умеет работать с категориальными фичами, поэтому ему ничего из того, что нужно для линейной регрессии, не нужно предварительно делать. И взаимодействие фич между собой он тоже сам подхватывает. Но как-раз от всего этого мне и приходится отказаться, чтобы модель заработала. А в целом ну не знаю, если я получил лучший скор среди всех участников на этой задаче с помощью, как вы говорите, MVP, то чего же тогда можно было добиться с "полным проектом", интересно? )) Матрицу корреляции да, надо бы показать, но у меня пока не получается "объять необъятное". И корреляция не покажет те особенности зависимостей целевой переменной, за которые я в итоге и зацепился, чтобы "вытащить" эту задачу.
О, это отличный поинт. Скорее всего целевая переменная тоже шумная. Я совсем уж опустил детали, в задаче шла речь о том, чтобы показывать нашу ёлочку в телевизоре. В этом случае, конечно, есть некоторые более жёсткие границы "кондиционности" ёлочки, но они всё-равно размытые и шум будет.
Да, могут быть ещё какие-то факторы, которые нам не дали на вход. При работе с "большими данными" всегда есть надежда, что даже если нам дали не все данные, то в тех, которые дали, как-то косвенно есть информация и об отсутствующих данных и модель за это ухватится. Но с вашим примером я действительно не могу придумать, в какой фиче могла бы быть уже учтена подкормка.
Ну, собственно и поэтому всему тоже лучший скор по задаче получается не 1 (максимальное возможное для ROC AUC), а всего лишь 0.67 с копейками. Надо будет дополнить пост. Ох, чую правки никогда не закончатся ))
Я лично подсел на дешёвых китайцев. Мне одинаково удобно пользоваться "обычной" мышкой iMice G-1800 и "вертикальной" Zelotes F-35. Вертикальная мышь специально сделана чуть тяжелее и с широким низом, что уберегает её от опрокидывания. При этом скользит она по коврику легко. Работать предпочитаю вертикальной мышью, хотя разница в ощущениях невелика. Но при использовании вертикальной мышью рука лежит практически в том же положении, как если бы я её просто положил на стол. Рука так меньше напрягается.
Базовые задачи часто решают градиентным бустингом и моделями из scikit‑learn, например XGBoost и CatBoost.
Ну, если XGBoost в каком-то виде таки встроен в scikit‑learn, хотя чаще используется всё же в виде отдельного пакета, то уж CatBoost точно является отдельным пакетом и к scikit‑learn не имеет никакого отношения.
Авторы сравнили линейную регрессию и ARIMA с моделями машинного обучения, например Random Forest и XGBRegressor, и получили более высокую точность у ML‑подходов.
А что, линейная регрессия - это не "ML-подход"? Можно конечно линейную регрессию назвать "статистическим подходом", но я бы лучше сказал про RF и XGB не как про "ML-подходы", а как про "сложные/ансамблевые модели".
По-русски это называется "количественный аналитик". Потому что в оригинале это "quantitative analyst", а не "quantum analyst". В финансах нет ничего "квантового", это не физика. Иногда сокращают до "quant analyst", ну тогда и говорить нужно "квант" и те, кто в теме - поймут о чём речь. А "квантовый аналитик" - это просто искажённая калька с английского.
Толково. Добавил к моим тестам, по времени получается примерно как другие два метода, при этом в среднем тут достаточно двух шагов алгоритма, чтобы найти число.
Тьфу, блин, я неправильно считал. Я считал число итераций цикла. И в случае с set будет 4 шага по циклу, но на первом то шаге мы ничего не сравниваем, сравнения начинаются со второго шага. Значит, интуиция меня всё-таки не обманула - в варианте с set достаточно в среднем 3-х проверок, как я и предполагал. ) Что меньше, чем 4 для random варианта. Кстати, для массивов маленького размера возможно list даже будет быстрее, чем set.
Видео не хотелось бы смотреть ) Почему бы в тексте это решение не показать? ) Но, повторюсь, по факту решение с set и есть O(1), если не брать совсем уж злонамеренные данные.
В итоге я погонял тесты. Интуиция меня всё-таки обманула:
метод с random и метод с set практически одинаковые по скорости работы
среднее число попыток у них одинаковое: 4
при этом у random больше разброс количества попыток и (что логично из этого вытекает) почти в 2 раза больше максимальное число попыток, которое понадобилось
Таким образом, вполне можно считать, что метод с set тоже O(1) и по скорости и по памяти, и при этом он стабильнее, чем метод с random (меньше разброс требуемых попыток, а значит и времени работы метода).
P.S. Конечно, если подавать злонамеренно подготовленные данные, то метод с random предпочтительнее. Метод с set, если ему злонамеренно ставить в конец повторяющееся число, будет всегда перебирать половину массива. Конечно, можно перебирать тогда специально в обратном порядке, но тогда можно ставить эти числа в середину, и перебираться всё-равно будет четверть массива, хоть по порядку перебирай, хоть обратно. Но если злонамеренность не ожидается, то метод с set предпочтительнее.
Плохо только то, что максимальное число попыток теоретически не ограничено. В очень редком случае рандом может выпадать так, что цикл будет продолжаться бесконечно. ) Так что интересно было бы увидеть решение O(1) без рандома. Рандом, кстати, несколько затратный по ресурсам. Это, конечно, константа, но... Кстати, из тех же самых соображений о минимальном числе попыток, ваш самый первый метод с хэшем по идее превращается в такой же константный и интуитивно думаю, что даже с меньшим числом попыток, ведь мы сравниваем очередное число не с одним, а со всеми числами, которые на данный момент есть в словаре.
Да, но люди пройдут ещё не скоро. А так то и Солнечная Система пройдёт, но ещё более не скоро. И даже наша Вселенная тоже пройдёт, но через какое-то вообще невообразимое время.
Это совершенно нормально для экономики. Работники всё время перетекают из одних областей в другие. "20 лет на одном заводе" мало кто пашет, потребности экономики всё время меняются, заводы открываются и закрываются, люди перепрофилируются.
С одной стороны, такое удивляет, а с другой стороны, учитывая, что до точки подачи водителю ещё нужно доехать, плюс посадка-высадка, поиск нового заказа, в итоге может для водителя это получается тоже на то же по заработку, только на короткие дистанции больше возни, а на длинную уж взял заказ и спокойно едешь. Поэтому, видимо, чтобы заинтересовать водителя брать и короткие заказы, их делают дороже.
Но таки предлагают вариант уехать дешевле - по тарифу "Вместе". Иногда по нему вообще никакой выгоды, а иногда в 2 раза можно сэкономить, я иногда пользовался. )
Обработка и очистка будет дальше. Как и логистическая регрессия. Для пробного использования CatBoost никакая особая подготовка данных не нужна, поэтому её не было. CatBoost разбивает признаки на бины и умеет работать с категориальными фичами, поэтому ему ничего из того, что нужно для линейной регрессии, не нужно предварительно делать. И взаимодействие фич между собой он тоже сам подхватывает. Но как-раз от всего этого мне и приходится отказаться, чтобы модель заработала.
А в целом ну не знаю, если я получил лучший скор среди всех участников на этой задаче с помощью, как вы говорите, MVP, то чего же тогда можно было добиться с "полным проектом", интересно? ))
Матрицу корреляции да, надо бы показать, но у меня пока не получается "объять необъятное". И корреляция не покажет те особенности зависимостей целевой переменной, за которые я в итоге и зацепился, чтобы "вытащить" эту задачу.
О, это отличный поинт. Скорее всего целевая переменная тоже шумная. Я совсем уж опустил детали, в задаче шла речь о том, чтобы показывать нашу ёлочку в телевизоре. В этом случае, конечно, есть некоторые более жёсткие границы "кондиционности" ёлочки, но они всё-равно размытые и шум будет.
Да, могут быть ещё какие-то факторы, которые нам не дали на вход. При работе с "большими данными" всегда есть надежда, что даже если нам дали не все данные, то в тех, которые дали, как-то косвенно есть информация и об отсутствующих данных и модель за это ухватится. Но с вашим примером я действительно не могу придумать, в какой фиче могла бы быть уже учтена подкормка.
Ну, собственно и поэтому всему тоже лучший скор по задаче получается не 1 (максимальное возможное для ROC AUC), а всего лишь 0.67 с копейками. Надо будет дополнить пост. Ох, чую правки никогда не закончатся ))
Да уж. Мне вот MicroProse жалко, что закрылась, например )
Я лично подсел на дешёвых китайцев. Мне одинаково удобно пользоваться "обычной" мышкой iMice G-1800 и "вертикальной" Zelotes F-35. Вертикальная мышь специально сделана чуть тяжелее и с широким низом, что уберегает её от опрокидывания. При этом скользит она по коврику легко. Работать предпочитаю вертикальной мышью, хотя разница в ощущениях невелика. Но при использовании вертикальной мышью рука лежит практически в том же положении, как если бы я её просто положил на стол. Рука так меньше напрягается.
Играл я в Lode Runner на ДВК-3, эх, было время )
Экспертам за проверку домашек какие-то копейки платят, глубоко вникать всё-равно никто не будет, если это не индивидуальный менторинг (
Ну, если XGBoost в каком-то виде таки встроен в scikit‑learn, хотя чаще используется всё же в виде отдельного пакета, то уж CatBoost точно является отдельным пакетом и к scikit‑learn не имеет никакого отношения.
А что, линейная регрессия - это не "ML-подход"? Можно конечно линейную регрессию назвать "статистическим подходом", но я бы лучше сказал про RF и XGB не как про "ML-подходы", а как про "сложные/ансамблевые модели".
По-русски это называется "количественный аналитик".
Потому что в оригинале это "quantitative analyst", а не "quantum analyst".
В финансах нет ничего "квантового", это не физика.
Иногда сокращают до "quant analyst", ну тогда и говорить нужно "квант" и те, кто в теме - поймут о чём речь.
А "квантовый аналитик" - это просто искажённая калька с английского.
Ну, у многих алгоритмов худшая сложность отличается от типовой, это нормально.
Толково. Добавил к моим тестам, по времени получается примерно как другие два метода, при этом в среднем тут достаточно двух шагов алгоритма, чтобы найти число.
Тьфу, блин, я неправильно считал. Я считал число итераций цикла. И в случае с
setбудет 4 шага по циклу, но на первом то шаге мы ничего не сравниваем, сравнения начинаются со второго шага. Значит, интуиция меня всё-таки не обманула - в варианте сsetдостаточно в среднем 3-х проверок, как я и предполагал. ) Что меньше, чем 4 дляrandomварианта.Кстати, для массивов маленького размера возможно
listдаже будет быстрее, чемset.Да, у меня тоже была такая мысль - в начале random, а потом уже set )
Видео не хотелось бы смотреть ) Почему бы в тексте это решение не показать? ) Но, повторюсь, по факту решение с
setи есть O(1), если не брать совсем уж злонамеренные данные.В итоге я погонял тесты. Интуиция меня всё-таки обманула:
метод с
randomи метод сsetпрактически одинаковые по скорости работысреднее число попыток у них одинаковое: 4
при этом у
randomбольше разброс количества попыток и (что логично из этого вытекает) почти в 2 раза больше максимальное число попыток, которое понадобилосьТаким образом, вполне можно считать, что метод с
setтоже O(1) и по скорости и по памяти, и при этом он стабильнее, чем метод сrandom(меньше разброс требуемых попыток, а значит и времени работы метода).P.S. Конечно, если подавать злонамеренно подготовленные данные, то метод с
randomпредпочтительнее. Метод сset, если ему злонамеренно ставить в конец повторяющееся число, будет всегда перебирать половину массива. Конечно, можно перебирать тогда специально в обратном порядке, но тогда можно ставить эти числа в середину, и перебираться всё-равно будет четверть массива, хоть по порядку перебирай, хоть обратно. Но если злонамеренность не ожидается, то метод сsetпредпочтительнее.Плохо только то, что максимальное число попыток теоретически не ограничено. В очень редком случае рандом может выпадать так, что цикл будет продолжаться бесконечно. )
Так что интересно было бы увидеть решение O(1) без рандома. Рандом, кстати, несколько затратный по ресурсам. Это, конечно, константа, но...
Кстати, из тех же самых соображений о минимальном числе попыток, ваш самый первый метод с хэшем по идее превращается в такой же константный и интуитивно думаю, что даже с меньшим числом попыток, ведь мы сравниваем очередное число не с одним, а со всеми числами, которые на данный момент есть в словаре.
Да, но люди пройдут ещё не скоро. А так то и Солнечная Система пройдёт, но ещё более не скоро. И даже наша Вселенная тоже пройдёт, но через какое-то вообще невообразимое время.
Это совершенно нормально для экономики. Работники всё время перетекают из одних областей в другие. "20 лет на одном заводе" мало кто пашет, потребности экономики всё время меняются, заводы открываются и закрываются, люди перепрофилируются.
Вот точно. Это примерно как с "пузырём доткомов". Пузырь то лопнул, а интернет цветёт и пахнет.
С одной стороны, такое удивляет, а с другой стороны, учитывая, что до точки подачи водителю ещё нужно доехать, плюс посадка-высадка, поиск нового заказа, в итоге может для водителя это получается тоже на то же по заработку, только на короткие дистанции больше возни, а на длинную уж взял заказ и спокойно едешь. Поэтому, видимо, чтобы заинтересовать водителя брать и короткие заказы, их делают дороже.
Но таки предлагают вариант уехать дешевле - по тарифу "Вместе". Иногда по нему вообще никакой выгоды, а иногда в 2 раза можно сэкономить, я иногда пользовался. )