Цитаты о машинном обучении
Обновлено: 21.11.2024
Перевёл после прочтения комментариев к статье «О ненависти к C++». В цитатах можно найти ответы на большинство возникших там вопросов.
50. Программирование сегодня — это гонка разработчиков программ, стремящихся писать программы больше и с лучшей идиотоустойчивостью, и вселенной, которая пытается создавать больших и лучших идиотов. Пока вселенная побеждает.
— Rick Cook
49. Lisp — это не язык, а строительный материал.
— Alan Kay
48. Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
— Edward V Berard
47. Они больше не делают баги, как Банни (Bugs Bunny).
— Olav Mjelde.
46. Низкоуровневый язык — это когда требуется внимание к вещам, которые никак не связаны с программами на этом языке.
— Alan J. Perlis.
45. Программирование на С похоже на быстрые танцы на только что отполированном полу людей с острыми бритвами в руках
— Waldi Ravens.
44. Я всегда мечтал о том, чтобы моим компьютером можно было пользоваться так же легко, как телефоном; моя мечта сбылась: я уже не могу разобраться, как пользоваться моим телефоном.
— Bjarne Stroustrup
43. Обучение программированию не может научить быть экспертом, также как и изучение кистей и красок не может превратить кого-либо в художника.
— Eric S. Raymond
42. Не волнуйтесь, если что-то не работает. Если бы всё работало, вас бы уволили.
— Mosher’s Law of Software Engineering
40. Хорошо, Java, ВОЗМОЖНО, хороший пример того как должен выглядеть язык. Но тогда программы на Java — это хороший пример как НЕЛЬЗЯ писать программы.
— pixadel
39. Учитывая текущее плачевное состояние наших программ, можно сказать, что программирование определенно все ещё черная магия и, пока, мы не можем называть его технической дисциплиной.
— Bill Clinton
38. Использование COBOL калечит разум; исходя из этого, обучение этому языку должно быть признано уголовно наказуемым преступлением.
—
37. версия «спагетти кода» — это, конечно, «лазанья код» (очень много слоев).
— Roberto Waltman
36. FORTRAN — это не цветок, а сорняк: он вынослив, иногда расцветает и произрастает в каждом компьютере
— Alan J. Perlis.
35. Для меня долгое время было загадкой, как очень дорогое и технологичное может быть столь бесполезным. И вскоре я осознал, что компьютер — это глупая машина, обладающая способностями выполнять невероятно умные вещи, тогда как программисты — это умные люди, у которых талант делать невероятные глупости. Короче, они нашли друг друга.
— Bill Bryson
34. По моему эгоистическому мнению, большинство программ на C должны быть отформатированы с отступами на 2 метра вниз и засыпанными землей.
— Blair P. Houghton.
33. Когда говорит: «Я хочу язык программирования, который может делать все, что ему скажу», то я даю этому человеку леденец.
— Alan J. Perlis
32. Эволюция языков: FORTRAN — не строго типизированный язык, С — слабо типизированный язык. Ada — сильно типизированный язык. С++ — сильно раздутый язык.
— Ron Sercely
31. В хорошем дизайне добавление вещи стоит дешевле, чем сама эта вещь.
— Thomas C. Gale
30. Если называть Python заменой BASIC, то тогда и трансформер Optimus Prime — это только замена грузовика.
— Cory Dodt
29. Болтовня ничего не стоит. Покажите мне код.
— Linus Torvalds
28. Как видно, совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.
— Antoine de éry
27. С — это причудливый, несовершенный, но невероятно успешный язык.
— Dennis M. Ritchie.
26. В теории, теория и практика неразделимы. На практике это не так.
— Yoggi Berra
25. Вы не можете создавать хорошие программы без хорошей команды, но большинство софтверных команд ведут себя как проблемная семья.
— Jim McCarthy
23. Программирование — это как бить себя по лицу, рано или поздно ваш нос будет кровоточить.
— Kyle Woodbury
22. Perl — это тот язык, который одинаково выглядит как до, так и после RSA шифрования…
— Keith Bostic
21. Намного легче портировать шелл, чем скрипт на шелле.
— Larry Wall
20. Я изобрел понятие «объектно-ориентированный», но могу заявить, что не имел в виду C++ при этом.
— Alan Kay
19. Изучение программирования имеет такое же отношение к проектированию интерактивных систем, как обучение слепой печати к написанию стихов.
— Ted Nelson
18. Лучшие программисты не чуть-чуть лучше хороших. Они на порядок лучше по любым меркам: концептуальное мышление, скорость, изобретательность и способность находить решения.
— Randall E. Stross
17. Если бы McDonalds была бы софтверной компанией, то у них один из ста Биг Маков был бы отравленным, и их ответ на это был бы: «Мы сожалеем, вот вам купон на ещё два Биг Мака."
— Mark Minasi
16. Опасайтесь багов в приведенном выше коде; я только доказал корректность, но не запускал его.
— Donald E. Knuth.
15. Анализ компьютерных систем — это как воспитание детей; можно нанести огромный вред, но нельзя гарантировать успех.
— Tom DeMarco
14. Меня не интересует, будет ли это работаеть на ваших машинах! Мы не отдаем их заказчику!
— Vidiu Platon.
13. Иногда лучше остаться спать дома в понедельник, чем провести всю неделю отлаживая написанный в понедельник код.
— Christopher Thompson
12. Измерять продуктивность программирования подсчетом строк кода — это так же, как оценивать постройку самолета по его весу.
— Bill Gates
11. Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать.
— Brian W. Kernighan.
10.Люди считают, что программирование — это наука избранных, но в реальности все наоборот — просто много людей создают программы, которые используют чужие программы, как-будто строя стену из маленьких кирпичиков.
— Donald Knuth
9. Сначала учите науку программирования и всю теорию. Далее выработаете свой программистский стиль. Затем забудьте все и просто программируйте.
— George Carrette
8. Многие из вас знакомы с достоинствами программиста. Их всего три, и разумеется это: лень, нетерпеливость и гордыня.
— Larry Wall
7. Большинство программ на сегодняшний день подобны египетским пирамидам из миллиона кирпичиков друг на друге и без конструктивной целостности — они просто построены грубой силой и тысячами рабов.
— Alan Kay
6. Трудность работы с програмистом заключается в том, что вы не можете понять что он делает до тех пор пока не стало слишком поздно.
— Seymour Cray
5. Итерация свойственна человеку, рекурсия божественна.
— L. Peter Deutsch
4. Меня два раза спрашивали [члены Парламента]: «Скажите на милось, мистер Бэббидж, что случится, если вы введете в машину неверные цифры? Cможем ли мы получить правильный ответ?» Я не могу себе даже представить какая путаница в голове может привести к подобному вопросу.
— Charles Babbage
3. Большинство хороших программистов делают свою работу не потому, что ожидают оплаты или признания, а потому что получают удовольствие от программирования.
— Linus Torvalds
2. Всегда пишите код так, будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
— Martin Golding
1. Есть два способа создания дизайна программы. Один из них, это сделать его настолько простым, что в нем, очевидно, не будет недостатков. Другой способ — сделать его настолько запутанным, что в нем не будет очевидных недостатков.
— C.
Следующая цитата
Ошибки на кубит на квантовые ворота можно обрабатывать более эффективно с помощью методов машинного обучения. Для квантовой коррекции ошибок алгоритмы глубокого обучения дают большие обещания.
- машинное обучение цитаты
Исследования ИИ могут иметь необратимые последствия в жизни человеческого рода, поэтому мы должны действовать осторожно.
- мозговитые цитаты
- Прогресс котировки
- цитаты по информатике
- цитаты искусственного интеллекта
- котировки
Искусственный интеллект еще далеко не достиг истинного чувства или осознанности А без осознания это просто механическое устройство, которое может притворяться, что показывает эмоции и чувства, если оно запрограммировано для этого, и, таким образом, оно может одурачить людей живыми, но в своей внутренней схеме это просто следуйте его заранее запрограммированным задачам через блок-схему алгоритма.
- технологические кавычки
- психологические цитаты
- кавычки программирования
- цитаты по информатике
- цитаты искусственного интеллекта
Автоматизация против человеческого труда - ложная дихотомия
- цитаты по информатике
- цитаты искусственного интеллекта
- котировки
- машинное обучение цитаты
Искусственный интеллект определяется как область науки и техники, которая занимается изучением программного и аппаратного обеспечения, чтобы предоставить машинам возможность изучать данные и шаблоны из данных и среды, а также способность автоматически адаптироваться к изменяющимся ситуациям с высокой точностью. Точность и скорость.
- кавычки адаптируемости
- цитаты искусственного интеллекта
- учиться на ошибках цитаты
- котировки
- машинное обучение цитаты
искусственный интеллект заставляет человека стремиться от простых, алгоритмических и повторяющихся задач к решению проблем и внедрению новых идей. Это человеческий разум, а не человеческое тело, которое слишком долго использовалось недостаточн
- кавычки решения проблем
- рабочие места
- творческие цитаты
- котировки инноваций
- цитаты искусственного интеллекта
Вычисление - не то же самое, что мышление, а эмуляция - не то же самое, что воображение.
- мозговитые цитаты
- цитаты по информатике
- цитаты искусственного интеллекта
- машинное обучение цитаты
Люди беспокоятся о том, что компьютеры станут слишком умными и захватят весь мир, но настоящая проблема заключается в том, что они слишком глупы и уже завоевали мир.
- цитаты искусственного интеллекта
- котировки
- машинное обучение цитаты
Если мы пытаемся развить искусственный интеллект, то не нужно беспокоиться, потому что, каким бы умным ни был ИИ, он все равно не сможет бросить вызов программированию своего создателя, но если это искусственное восприятие мы хотим развиваться, тогда мы должны переосмыслить.
- цитаты искусственного интеллекта
- цитаты по компьютерному программированию
- машинное обучение цитаты
Ни человек, ни машина не могут заменить своего создателя.
- человек цитирует
- машинное обучение цитаты
Одной из наиболее важных проблем в машинном обучении - и жизни - является дилемма разведки и эксплуатации. Если вы нашли что-то, что работает, вы должны просто продолжать это делать? Или лучше попробовать новые вещи, зная, что это может быть пустой тратой времени, но также может привести к лучшему решению? Вы бы предпочли быть ковбоем или фермером? Создать компанию или запустить существующую? Идти ровно или играть на поле? Кризис среднего возраста - это стремление к исследованию после многих лет эксплуатации.
Следующая цитата
Стать программистом значит подписаться на обучение длиной в жизнь. Поток нового – новые функции, новые языки, новые инструменты, новые фреймворки – не иссякает никогда. Но вместе с тем, программирование – на удивление верная традициям сфера, где все основывается на принципах, проверенных временем. Мы ввели в оборот объектно-ориентированное программирование, современные аппаратные решения, искусственный интеллект, однако, несмотря на все эти изменения, многие аксиомы, которые были сформулированы еще в прошлом поколении, оказываются верными и на сегодняшний день.
Эту статью я посвятил разбору нескольких из своих любимых высказываний, касающихся программирования. Единственным критерием, по которому я производил отбор, было требование, чтобы цитате сравнялось не менее двадцати лет. Потому что это только устаревшие технологии быстро становятся непригодными к использованию, тогда как древние заповеди наших предков-программистов долго сохраняют актуальность.
1. О косвенности
«Все проблемы в программировании решаются путём создания дополнительного уровня косвенности» — Дэвид Виллер
Вот вам цитата из книги Computer Science Theory and Application, которую все любят повторять и мало кто любит объяснять. Тем не менее, это одна из моих любимых программерских истин – она метко раскрывает саму суть программирования.
Самый простой способ осмыслить косвенность – представить себе слои. Ну например, представим себе, что у вас есть небольшой проект, в рамках которого нужно поместить компонент А внутрь компонента В:
Оба компонента стандартизированы, так что разобрать их на составляющие и поменять принцип работы не получится. Вы могли бы создать отдельный дополнительный компонент ( PlugTwoProngVariant ), но это и куча работы, и ненужное дублирование. Есть выход лучше: добавить между этими двумя компонентами слой-адаптер, который успешно взаимодействовал бы с обоими и служил бы между ними посредником.
Многие скажут вам, что смысл программирования состоит в том, чтобы писать ясные инструкции на языке, который поймет даже самый тупой компьютер. Но цитата Дэвида Виллера предлагает более глубокий взгляд на вопрос. Быть хорошим программистом – значит подниматься по лестнице косвенности, стремясь к самым общим решениям.
Бонусная цитата в тему
Косвенность – мощный инструмент, но за сложность приходится платить. Люди редко приводят то высказывание, которое следует сразу после знаменитой цитаты:
«Обычно это создает новую проблему» — Дэвид Виллер.
Именно благодаря этой истине программисты с давних пор остаются при делах.
2. О простоте
«Простота – предпосылка надежности» — Эдсгер Дейкстра
В мудрых программистах, которые предостерегают нас от усложнения кода без острой необходимости, недостатка нет. Но немногим удалось так явно показать, чем чревата для нас сложность, как пионеру в компьютерных науках Эдсгеру Дейкстра.
Вот в чем тут соль: вы делаете выбор в пользу простоты не просто из желания сделать приятное людям будущего. И не потому что предполагаете возможность повторно использовать этот код в дальнейшем. И не потому что хотите, чтобы он аккуратнее смотрелся на инспекции, и не потому что стремитесь облегчить процесс внесения изменений в будущем (хотя все это, разумеется, ценные преимущества). Вы поступаете так потому, что простота – это предпосылка. Без нее у вас никогда не будет надежного кода, которому можно доверить ведение бизнеса или работу с данными.
Чтобы принять позицию Дейкстра, нам нужно изменить свое понимание того, что такое «хороший код». Это не обязательно самый лаконичный код, или самый быстродействующий, и уж точно не самый заумный. Хороший код – это код, на который можно положиться.
Бонусная цитата в тему
Один из наилучших способов сохранять простоту в коде – помнить, что меньше значит больше. Дейкстра предлагает новую единицу измерения, которая все время будет нам об этом напоминать:
«Если мы хотим подсчитать количество строк кода, следует воспринимать их не как написанные, а как потраченные» — Эдсгер Дейкстра
3. О читабельности и переписывании
«Код сложнее читать, чем писать» — Джоэль Спольски
На первый взгляд, эта цитата Джоэля Спольски, легенды программирования и сооснователя Stack Overflow, кажется разумной, но обманчиво поверхностной. Да, фрагменты кода бывают информационно насыщенными, излишне сжатыми или утомительно длинными. И это относится не только к тому, что писали другие люди. Если вы посмотрите на свои собственные прошлогодние труды, вам понадобится какое-то время, чтобы воссоздать логику, которую вы когда-то знали от и до.
Но наблюдение Спольски разворачивается в нечто интересное. Опасность кода, который с трудом читается, состоит не только в самых очевидных последствиях (его тяжело корректировать и совершенствовать). Есть и другая, большая опасность: сложный для восприятия код кажется хуже, чем есть на самом деле. Фактически, разбираться в чужом коде может показаться такой непосильной задачей, что у вас возникнет искушение совершить то, что Спольски называет грубейшей из всех ошибок – переписать все заново.
Я не говорю, что архитектура системы никогда не выигрывает от подобных переписываний. Разумеется, бывает, что и выигрывает. Но улучшение такого рода дорого обходится. Во всем, что касается тестирования и устранения багов – а это две составляющие разработки, которые отнимают больше времени, чем собственно написание кода – вы возвращаетесь на исходную позицию. Переписывание выглядит заманчиво, потому что укладывается в одно из самых распространенных заблуждений разработчиков – склонность недооценивать трудозатраты на концептуально простые вещи. Именно поэтому 50% времени уходит на заключительные 5% проекта. Элементарные задачи могут отнимать на удивление много времени! А решение проблемы, которую уже решал в прошлом, всегда выглядит проще простого.
Ладно, если переписывать все с нуля, чтобы довести код до совершенства, не следует, то какие есть более удачные альтернативы? Ответ: привлечь каждого разработчика к процессу непрерывного фрагментарного рефакторинга. Так ваш код совершенствуется постоянно, за счет цепочки небольших изменений – реальная выгода с минимальными рисками. Читабельность можно повышать по ходу дела.
Бонусная цитата в тему
Если вы все еще сомневаетесь в важности читабельности, Мартин Фаулер поможет взглянуть на проблему шире:
«Любой дурак может писать код, который будет понятен компьютерам. Хорошие программисты пишут код, который будет понятен людям» — Мартин Фаулер
Иными словами, задача программиста – выдать не просто рабочий код, но код с внутренней логикой.
4. О повторениях
«Не повторяйтесь. Каждый фрагмент знания должен иметь единственное, однозначное, надежное представление в системе» — Энди Хант и Дэвид Томас
Каждый уважающий себя программист знает, что в повторении кроется множество бед. Если вы прописываете одно и то же в нескольких местах, вам приходится больше сил тратить на тестирование и устранение багов. Хуже того, вы создаете условия для возникновения разночтений; например, один фрагмент кода могут впоследствии обновить, а прочие сопутствующие процедуры – не привести в соответствие. Программа с разночтениями – это программа, которой нельзя доверять, а программа, которой нельзя доверять, не может считаться жизнеспособным решением.
Этого бага можно было бы избежать с методом GetTeamUniform()
Однако повторы сеют хаос не только в коде. Данная версия хорошо всем известного принципа DRY (Don’t Repeat Yourself / Не потворяйтесь) толкует принцип устранения дубликатов расширительно, охватывая и другие места, куда могут пробраться повторы. Сейчас разговор идет уже не о дубликатах в коде – мы говорим в том числе и о повторах в масштабах всей системы. А системы кодируют знания в различных форматах. В частности это:
- Операторы
- Комментарии к коду
- Документация для разработчиков или клиентов
- Схемы данных (например, таблицы базы данных)
- Прочие спецификации – планы тестирования, документы по организации процессов, правила сборки
Кстати говоря, не следует думать, что конфликты между претендентами на истину случаются только в небольших проектах или являются следствием низкого качества кода. Один из самых лучших примеров, который полыхнул у всех на виду – битва между XHTML и HTML5. Одна сторона утверждала, что спецификации – это и есть официальная правильная версия, а браузеры должны под нее подстроиться. Другой лагерь возражал, что именно поведение браузеров должно считаться стандартом де-факто – ведь именно так проектировщики всё себе и представляли, когда писали веб-страницы. В конечном итоге, победила та версия истины, которую продвигали браузеры. С тех пор HTML5 – это то, что браузеры реально делают, включая допустимые короткие пути и ошибки.
Бонусная цитата в тему
Возможность того, что код и комментарии к нему вступят в противоречие друг с другом, породила оживленные дискуссии: чего вообще больше от комментариев – пользы или вреда? Сторонники экстремального программирования относятся к ним с откровенным недоверием.
«Код никогда не лжет, а вот с комментариями такое случается» — Рон Джеффрис
5. О сложных проблемах
«В компьютерных науках есть только две сложные проблемы – аннулирование кэша и придумывание названий» — Фил Карлтон
С виду эта цитата кажется просто программисткой шуткой, забавной, но ничем не выделяющейся из прочих. Каждый может прочувствовать контраст между чем-то, что звучит как сложная задача (аннулирование кэша), и чем-то, что звучит как сущий пустяк (придумывание названий). Любой программист хоть раз убивал целые часы на какую-нибудь до смешного мелкую проблему – два параметра, проставленных не в том порядке, переменную, которая где-то с большой буквы, а где-то нет (спасибо, JavaScript!). Пока людям для достижения своих целей приходится работать совместно с компьютерами, программирование всегда будет представлять собой смесь высокоуровневого системного планирования и дурацких опечаток.
Но если вчитаться в слова Фила Картона повнимательнее, мы обнаружим здесь больше простора для размышлений. Придумывать названия сложно не просто потому, что из таких маленьких головных болей у программиста то и дело вся жизнь идет кувырком. Дело тут еще и в том, что названия – это одна из граней основной задачи программиста, проектирования программ. Иными словами, как вообще пишется ясный, аккуратный и непротиворечивый код?
Существует много разновидностей плохих названий. Все мы встречались с переменными, которые нарекли в честь типов данных ( myString , obj ), сокращений ( pc , то есть product catalog), какой-нибудь незначительной детали имплементации ( swappable_name , formUserInput ) или же вообще оставили безымянными ( ret_value , tempArray ). Легко попасться в ловушку и назвать переменную исходя из того, что вы сейчас с ней делаете, а не из ее содержимого. А со значениями логических типов данных вообще беда: что подразумевает progress – что прогресс уже начался, что нужно отобразить информацию о прогрессе в интерфейсе или вообще что-то третье?
Перевод «results_tmp_2? Это что еще за. Ты что, весь мир ненавидишь? Нельзя так называть переменные!» — «Ну, мне нужно было на время сохранить результаты запроса… И я уже один раз так делал, вот и получается results_tmp_2. Стараюсь не пренебрегать семантикой»
Но названия переменных – это еще только начало. Когда вы начинаете придумывать имена классам, встает вопрос о том, как разбивать код на независимые части. Названия публичных членов определяют, каково будет представление интерфейса, с помощью которого разные части приложения будут взаимодействовать между собой. Закрепляя за фрагментом кода название, вы не просто описываете, что он может делать – вы устанавливаете, что он будет делать.
Следующая цитата
Предлагаем почитать перевод статьи Diego Isco с ресурса dev.to. Она будет полезна начинающим специалистам в области ML.
Несколько месяцев назад я изучал проекты, в которых благодаря машинному обучению успешно реализуются невероятные вещи.
И я загорелся этим. Сказал, что хочу этому научиться. Неважно, насколько трудно мне будет. Я хочу научиться, и я научусь.
Будем честны: все мы слышали о зарплатах инженеров по машинному обучению. Взгляните на это.
Впечатляет, правда? Но машинное обучение еще нужно освоить — и вот тут начинается мрак.
Воодушевленный, я начал изучать работы по этой теме, и знаете что? Везде — математика! Навороченные уравнения, линейная алгебра, векторы и странные символы.
В тот вечер я плакал как ребенок. Но, как хороший технарь, утер слезы и решил учиться самостоятельно.
Да, я просто еще один нерд, пытающийся осилить машинное обучение.
Но мне скучно изучать сложные темы. Особенно во время карантина. Поэтому я хочу попробовать что-нибудь другое. Я опишу свой процесс обучения.
Ход обучения
Математика → Статистика → Программирование → Машинное обучение → Любительские проекты
Когда вы будете искать на YouTube видео о машинном обучении, то обязательно наткнетесь на 3 основных — от Siral Raval, Jabril и Daniel Bourke.
Все они — выше всяких похвал. Поэтому я решил взять из этих видео лучшее.
Математика
Много споров по поводу того, насколько хорошо нужно знать математику для освоения машинного обучения. Но знать точно нужно.
Возможно, некоторые из вас чертовски гениальны в математике и вам достаточно вспомнить лишь отдельные вещи. Но большинству простых смертных вроде меня нужно всему учиться с нуля.
Хорошо, а что именно нужно знать? Всего-то линейную алгебру и матанализ.
Напоминаю: я не гений в математике. Я плохо разбираюсь в математике. Я завалил матанализ на всех курсах в университете!
Так вот, можно ли освоить теорию машинного обучения, не будучи гением в математике?
Есть один нюанс. Если вы не дружите с числами, то это потому, что не понимаете основ.
Помните основы? Об основах линейной алгебры и математического анализа рассказывает на канале 3Blue1Brown Грант Сандерсон. Ему надо дать Нобелевскую премию в области образования. Он просто берет математику объясняет ее в потрясающей форме. Как ребенку. Это прекрасно.
Итак, моим первым шагом было понять основы линейной алгебры и математического анализа. Поверьте, после этого все намного проще.
Мы посмотрели и осмыслили эти видео, теперь время применить свои знания на практике — на курсе линейной алгебры от крупнейшего специалиста в сфере преподавания математики — Гилберта Стрэнга из Массачусетского технологического института.
Подумать только: получать такое же образование, что и студенты, заплатившие тысячи долларов за очный курс! Да, диплома одного из лучших университетов мира не будет, но накопленные знания — вот что в итоге имеет значение.
Что ж, мы усвоили этот длинный курс и попрактиковались, теперь черед математического анализа. В Академии Хана есть потрясающая программа, которая дает все, что надо для того, чтобы чувствовать себя уверенно, имея дело с мудреными уравнениями.
Статистика
Многих людей сбивает с толку то, насколько машинное обучение похоже на статистику. На самом деле они тесно связаны друг с другом, так что статистика — ключ к пониманию теории машинного обучения.
Поэтому сосредоточьтесь и учитесь.
А для облегчения этой задачи — бесплатный курс Probability — The Science of Uncertainty and Data от Массачусетского технологического института.
Читая учебную программу, вы можете подумать, что курс базовый, но это не так. Он охватывает достаточно тем, чтобы дать основы для понимания теории вероятности. Всем, кто любит поучиться, вот еще один курс — Statistics and Probability от Академии Хана. Это в дополнение, так что расслабьтесь.
Программирование
Если вы, как и я, инженер-программист, то для вас сейчас будет самое интересное.
Язык программирования, который необходимо знать, это Python. Король машинного обучения. Его простота делает процесс освоения материала очень легким — по крайней мере, поначалу.
Я предполагаю, что вы знаете программирование, так что не хочу пересказывать содержание курсов для изучения Python — их много. Кроме того, есть отличные книги. Вам решать, где набраться знаний.
Кому-то может быть удобнее изучать документацию или пользоваться подпиской на учебную онлайн-платформу, а у кого-то есть любимый учитель на Udemy. Главное, не забывайте практиковаться, чтобы лучше понимать, что происходит при программировании для машинного обучения.
Ладно, допустим, вы не знаете программирования, и это будет ваша первая строчка кода. В таком случае я бы выбрал Datacamp. Смело исследуйте тему самостоятельно и смотрите их курс по Python.
Машинное обучение
Мы уже далеко продвинулись. Изучили математику, статистику, алгоритмы, проплакали несколько ночей. Все ради этого момента.
Курс по машинному обучению от Эндрю Ына — наверное, один из лучших по теме. Он не для новичков, так что не убирайте далеко свои конспекты. Наконец то, как работают алгоритмы машинного обучения, сложится для вас в цельную картинку.
Еще один ресурс — это Introduction to Machine Learning for Coders. Хороший курс с детальными объяснениями алгоритмов машинного обучения.
Советую пройти оба, изучить вопрос с разных сторон, тогда вы сможете сказать, какой курс оказался наиболее понятным.
Не могу не упомянуть еще одну программу, которую очень хвалят. Но она платная: это Introduction to Machine Learning Course нa Udacity. Если у вас отложено немного денег и вы готовы инвестировать в себя, то это подходящий случай, но решайте сами.
Любительские проекты
Теперь вы уже знаете машинное обучение, но этого недостаточно. Вам нужно больше практики. Здесь вам поможет книга Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow.
После этого можно браться за любительские проекты, но уже с лучшими библиотеками машинного обучения. Если вам, как и мне, не нравится опираться на библиотеки без понимания, что к чему, то не волнуйтесь: вы уже разбираетесь. Поэтому я даю эту книгу в самом конце.
Читайте также: