А по зарплате как? )) У меня основная проблема, что из Senior Developer переходить в даже в Middle DS как-то не очень вкусно, а то норовят вообще Junior+ DS предложить.
Так то из Middle Developer в Junior DS перейти вообще не проблема, конечно. В Junior можно и вообще сразу после курсов каких-нибудь прийти )
Ну, такое. Я лично не люблю заниматься чисто SQL-ем и вообще одной лишь подготовкой данных. Походив по DS собеседованиям я понял, что Data Engineer — это не моё. Но и один только Data Science, где больше аналитика, статистика и т.д. для программиста тоже не то. Мне вот нужно что-то среднее — какие-то исследования делать, где и подготовка данных и построение моделей, но без сильного углубления в аналитику/статистику и без ухода чисто в подготовку данных. Сложно угодить на человека, которому нужна творческая практическая работа, а не теория и не рутина.
С точки зрения практики PCA вроде как лучше разделяет данные, но зато, как указано выше в цитате, TruncatedSVD может работать с разреженными матрицами, что иной раз очень экономит память и там, где PCA просто не может переварить данные, TruncatedSVD спокойно справляется. А разреженные матрицы гигантских размеров встречаются не так уж и редко — например, при обработке текстов в виде «мешка слов».
Даже бэкэндщику в DS перейти и то не так просто. Я вот пытался недавно, и, посмотрев на предложенную мне зарплату, пока предпочёл остаться в бэкэнде. Но буду пытаться ещё. )
А вот из бэкэнда в девопс как-раз недавно один мой бывший коллега перешёл. Ему нравится. И это не такая редкая история, я знаю ещё случаи.
Из плюсов только душ в вагоне, ну и большой второй туалет — который для инвалидов, но им вроде все могут пользоваться. А так да — это ж штаб, там всегда суета. Хотя формально там и меньше пассажиров едет, а по факту всё время беготня, что-то обсуждают в коридоре и т.д.
Последние где-то полгода регулярно пользуюсь душем в штабном вагоне фирменных поездов Саратов-Москва, стоит всего 150р (если полотенце и прочие принадлежности свои). Очень удобно принять душ в начале дня, если сразу с поезда потом на работу или по делам и нет возможности домой заскочить.
Иной раз только бывает сложно через весь поезд в штабной вагон идти в душ и потом обратно, если мой вагон в другом конце поезда и народу много едет из-за праздников, например.
Часто вообще бывает достаточно сделать map/reduce через pool.map/imap. Есть разные подходы к мультизадачности/асинхронности и это хорошо, когда они все реализованы в языке и доступны к использованию.
А если серьёзно, то вообще данный вид асинхронности придумали не столько для скорости, сколько для того, чтобы не тратить ресурсы впустую на ожидание окончания каких-либо операций. Теоретически, пока мы ждём окончания какой-то async операции мы пока можем другой какой-то код повыполнять, который не зависит от результата этой операции. Но в итоге всё упирается в детали реализации и выгоды может, конечно, и не быть. А может и быть, если всё удачно сложилось.
Как программист, у которого основной язык C#, должен заметить, что в C# async/await сделан во многом похожим образом, так что я думаю, тут довольно большая часть претензий должна быть к общеязыковой парадигме async/await, а не к Питону, который тут виноват только в некоторых особенностях реализации. В целом к этой парадигме просто надо привыкнуть и она, конечно, не панацея от всего.
И всё же в русском языке принято переводить и говорить «параллельный запуск» и «параллельный режим», а не использовать кальку с английского «конкурентный».
Ну вообще-то примерно все определения, которые вы привели, описывают вполне одно и то же, просто с разной степенью развёрнутости. Под регрессией в ML обычно понимается предсказание значения непрерывной переменной в зависимости от значений других переменных (не обязательно, кстати, непрерывных, в отличие от целевой переменной).
Единственный, кто тут не совсем прав — это Microsoft. «Predicting future stock prices based on historical data and current market trends.» — это всё-таки уже то, что вы называете forecasting, а в ML это чаще всё же называют time series analysis/modeling/predicting.
Это довольно разные задачи и они, совершенно определённо, различаются теми, кто занимается ML.
Кстати, что касается не-ML-специфичных терминов (таких как стэкинг, бустинг, кросс-валидация и т.д., которые относятся именно к ML), обычно вполне можно полагаться на термины, принятые в статистике. Та же регрессия наверняка в статистике описана довольно чётким и однозначным образом. Я бы полагался на хорошо устоявшийся статистический базис в таких вопросах.
Приведите примеры что ли для начала. И, кроме того, основным источником знаний в этой области до сих пор являются статьи на английском, там путаницы обычно меньше.
В реальной жизни, да и на тех же соревнованиях по Data Science TPOT, к сожалению, не сильно помогает — там всё обычно упирается в какую-то супер-фичу, которую можно придумать только исследуя данные руками. Но каких-то идей, что можно ещё попробовать сделать с данными, TPOT может подкинуть. Ну и в целом полезно знать, что нынче полно есть инструментов разной степени сложности и полезности для, так называемого, AutoML. :) Глядишь, через какое-то время весь Data Science будет делаться через очень продвинувшийся к тому времени автоматический алгоритм.
Хорошо, если данные приходят в одном формате и из одного источника. Практика показывает, что зоопарк со временем растёт и данные приходится собирать в самом разном виде из самых разных источников. И везде их надо по-своему как-то обрабатывать, универсальные методы далеко не всегда помогают.
Так то из Middle Developer в Junior DS перейти вообще не проблема, конечно. В Junior можно и вообще сразу после курсов каких-нибудь прийти )
А вот из бэкэнда в девопс как-раз недавно один мой бывший коллега перешёл. Ему нравится. И это не такая редкая история, я знаю ещё случаи.
Иной раз только бывает сложно через весь поезд в штабной вагон идти в душ и потом обратно, если мой вагон в другом конце поезда и народу много едет из-за праздников, например.
Единственный, кто тут не совсем прав — это Microsoft. «Predicting future stock prices based on historical data and current market trends.» — это всё-таки уже то, что вы называете forecasting, а в ML это чаще всё же называют time series analysis/modeling/predicting.
Это довольно разные задачи и они, совершенно определённо, различаются теми, кто занимается ML.
Кстати, что касается не-ML-специфичных терминов (таких как стэкинг, бустинг, кросс-валидация и т.д., которые относятся именно к ML), обычно вполне можно полагаться на термины, принятые в статистике. Та же регрессия наверняка в статистике описана довольно чётким и однозначным образом. Я бы полагался на хорошо устоявшийся статистический базис в таких вопросах.