Search
Write a publication
Pull to refresh
147
0
Yury Kashnitsky @yorko

Staff GenAI Field Solution Architect, Google Cloud

Send message
А можно поделиться этими мыслями корифея? Вспоминается только формула привлекательности женщины.
Спасибо! 3-минутный гуглеж мне не помог найти хотя бы одну ее «приличную» фотографию.
Есть еще одно приложение, где часто возникает необходимость проверки изоморфизма подграфу (задача NP-полна) — машинное обучение на графах. Успешнее всего применяется в химинформатике при анализе зависимости типа «структура-свойство» (QSAR). Обучающая выборка может выглядеть так: молекулярные графы этих веществ — положительные объекты (обладают свойством, например, токсичностью, канцерогенностью, мутагенностью и т.д.), молекулярные графы других веществ — отрицательные объекты (то есть вешества соот-но не токсичны, не канцерогенны, не мутагенны). Самая простая идея — настроить подграфы всех обучающих графов и представить каждый граф бинарным вектором, где 1 стоит там, где соответствующий «маленький» граф изоморфен подграфу обучающейго графа. (Банальный пример: помеченные графы A-B-C и B-C-D представятся векторами [1,1,1,0,1,1,0] и [0,1,1,1,0,1,1], в признаковом пространстве подграфов [A, B, C, D, A-B, B-C, C-D]). Вычислительная сложность такого представления очень высокая, потому что подграфов очень много, а также много раз необходимо проверять изоморфизм подграфу. Тем не менее, GBoost работает именно так — это «обычный» бустинг вот в таком признаковом пространстве подграфов, где «деревянным» методом важности признаков определяются важные для классифкации подграфы (их потом можно принести и показать эксперту, и он скажет, что да, например, такой подграф — бензольное кольцо — действительно свидетельствует о таком-то свойстве вещества).
Но state-of-the-art в классификации графовых данных — это ядерные методы, в большинстве из которых все равно надо часто проверять изоморфизм подграфу.
Репозиторий с IPython-тетрадками по языку Python и структурам данных.
Мне также по душе пришлись интерактивные тьюториалы Dataquest.
Там помимо чистых введений в R и Python есть материалы по визуализации, хранению данных, по алгоритмам и структурам данных, по машинному обучению и Kaggle, а также по анализу больших данных с Apache Spark (к которому обертка есть и на R).
Мне из таких игр понравился Числобой с симпатичной графикой.
Неплохой способ попрактиковаться с питоновскими библиотеками — это повторить написанное на R
Вот тьюториал с неплохим обзором пути, по которому обычно идут исследователи данных
Да, поскольку это документация конкретного класса. Пишут просто «A decision tree classifier. Read more in the User Guide.» В гайде уже описывается метод, а не конкретный класс. По абзацу на ID3, С4.5 и CART и в конце говорится, что в sklearn это оптимизированный CART.
Хотя согласен можно было и в документации DecicionTreeClassifier написать, что это CART.
Да, «Machine Learning in Action» я советовал в своем курсе, но именно чтоб разобраться в деталях алгоритма, «залезть под капот», там хорошо объясняют. Согласен, что без NumPy и прочих питоновских библиотек код там смотрится жалко.
У Scikit-learn документация отличная, исходники мне не приходилось прямо читать и править. Так что для начинающих — то что надо. Но API несложный, свой класс Estimator можно быстро написать.
А уж потом допиливать решения для продакшн — это другое дело. Возможно, тут скоро изменятся приоритеты — TensorFlow
Про GIL и Python немало статей здесь же на Хабре, в наш курс мы этот материал не включали, он не совсем для начинающих.
Это же MLСlass, только недавно зарегался. Ребята молодцы, развиваются семимильными шагами! Давно хотел чтобы российские исследователи данных собрались под одной крышей.
Писал похожий материал, только обзор конкретных курсов — habrahabr.ru/post/248069
Могу добавить, что не стоит браться за курс, если потом не собираешься использовать полученные знания. Звучит банально, но я прошел 4 курса из специализации Data Science, когда-то разбирался в языке R, но все равно предпочитаю Python, и по сути многие часы про ggplot и прочие детали визуализации в R прошли для меня почти впустую.
Я пока c реально большими данными не работал, но кажется, серьезная сложность при переходе от подготовленных Kaggle датасетов к реальным данным с пропусками, ошибками, несоответствием форматов и прочим безобразием — это парсинг данных. На курсере в специализации «Data Science» говорится о некоторых приемах data munging, и что на это дело в работе исследователя данных уходит 90% времени.
Есть какие-то рекомендации, где научиться экономить время на подготовку данных, или это уже только с опытом приходит?
по-моему, неплохо вариант — «исследователь данных».
А вот оригинальная статья, в которой, отмечается, что пока обычные американцы и американки толстели с 1950-х годов по 2000-ые, модели Playboy, наоборот, худели. Но и, к сожалению, заодно и худели грудью. Или это результат борьбы с некачественными имплантантами…
По сути преобразование из дюймов в сантиметры — линейное, и ничего не должно было кардинально поменяться. Где было 25 дюймов, стало 64 см, если правильно округлять (так то 63.5, и если над данными работают разные люди, то кто-то мог взять и «округлить» до 63).
Причина «провалов» таится, во-первых, в округлении, а во-вторых, в слишком подробных гистограммах.
Если посмотреть на изначальные данные в дюймах, то получится вот что:

table(height$V1)

 59   60 60.5   61   62 62.5   63 63.5   64 64.5   65 65.5   66 66.5   67 67.5   68 68.5   69 69.5   70 
   2    4    1    5   29    4   38    1   54   13   85   20   86    5   99   10   78   19   31    5   18 
70.5   71   72   73   74 
   1    9    1    1    1 

Как видно, дробные значения люди указывают намного реже. Это известный прикол в статистических исследованиях. Демографы всегда делают поправки на округление данных.

Ну и если рисовать слишком подробные гистограммы, то конечно, они получаются более рваные.

hist(height$V1, breaks= 20, col="Green", xlab = "Height in inches", main = "Height")
> hist(height$V1, breaks= 100, col="Red", xlab = "Height in inches", main = "Height")

кстати, судя по ответу одного из разработчиков Яндекса, их асессоры отчасти этим и занимаются.
Ниче так предложение было бы для Amazon Mechanical Turk! сразу желающие нашлись бы, и не только домохозяйки
1. Добавить — в смысле породить из имеющихся? Тут можно тогда feature importance считать, например, с помощью прироста информации.
2. Вручную перебирать или автоматически генерить такие комбинации признаков — вряд ли перспективно, хотя точно не знаю. Просто SVM и нейронные сети как раз это и делают — строят очень сложную нелинейную функцию от входных признаков. А нужная комбинация найдется в процессе оптимизации.

Information

Rating
Does not participate
Location
Den Haag, Zuid-Holland, Нидерланды
Works in
Date of birth
Registered
Activity