Автодополнение, глазное дно и стеклянный компьютер

Добрый день!

Что вы думаете про всё это обучение на больших данных? Отдельные результаты восхищают и впечатляют, конечно, но слегка напрягает тот факт, что мы (люди) плохо управляем процессом. Что значит «плохо управляем»? Давайте рассмотрим для примера статью «Prediction of cardiovascular risk factors from retinal fundus photographs via deep learning».

Вкратце: исследователи натренировали нейронную сеть предсказывать риски сердечных заболеваний по фотографиям глазного дна. Если я верно понял, это исследование возникло по той причине, что опытные врачи тоже это могли делать. Впечатляет же то, что попутно удалось научиться по тем же фотографиям угадывать возраст (с ошибкой всего ~3 года) и пол (с вероятностью целых 97%), причём живые врачи этого не умеют вообще.

Другими словами, перед нами непонятный чёрный ящик, который готов по фотографиям давать точные прогнозы, но не способен объяснить, как он это делает. Хуже того, чёрный ящик старался сотрудничать (можно выяснить, какие области фотографии больше всего повлияли на принятие решения, а потом внимательно разглядывать эти области всем исследовательским коллективом), но это не помогло.

Компьютерной мощи хватает, чтобы делать сложные штуки, а массовость производства всей этой электроники естественным образом приводит к тому, что её цена выдавливает живых людей даже из сложных процессов. Очередной результат — Autocompletion with deep learning — система автодополнения кода, которая, возможно, изменит стиль работы программистов. В видео по ссылкам есть интересные примеры для разных языков программирования.

Программистам и сейчас много кода читать и понимать приходится, а с переходом на подобные системы доля этой активности естественным образом сможет увеличиться, ведь при использовании подобного автоматического дополнения придётся часто выбирать, что же из предложенного «умной» системой включить в код.

И последняя на сегодня ссылка по этой теме — Нейросеть в стекле. Не требует электропитания, распознаёт цифры — интересная иллюстрация для тех, кому хотелось понять что-то про нейронные сети, но всё как-то не до этого было. Ладно, начинать в это вникать надо не с подобных штук, конечно, но сделано красиво.

Хорошей недели!

Злой искусственный интеллект

Добрый день!

Позавчера Bloomberg опубликовал статью, в которую включил несколько забавных историй об искусственном интеллекте из свежей подборки «The Surprising Creativity of Digital Evolution: A Collection of Anecdotes
from the Evolutionary Computation and Artificial Life Research Communities».

Всю коллекцию прочитать тоже интересно и достаточно быстро (там всего 30 страниц, из которых почти треть — это ссылки и титульный лист), но для тех, кто спешит, я перескажу одну историю об игре в Крестики-нолики пять-в-ряд (Гомоку) на бесконечном поле.

Многие разработчики алгоритмов для этой игры исходят из своего жизненного опыта (тетрадного листа хватает для любой партии) и интуиции (если придётся вылезти за пределы заданного поля, то мы просто его чуть-чуть расширим в нужную сторону), которая нас нередко обманывает. Поскольку рационально действующий игрок не делает ходы далеко от основного скопления фишек (такое действие приводит к пустой потере хода, что означает быстрое поражение), то от программы соперника таких ходов тоже никто не ждал.

Как правило в турнирах компьютерных программ договариваются о том, что сделавший некорректный ход считается проигравшим. Соответственно, эволюционирующий бот нащупал неожиданную возможность выигрывать — он стал делать ходы в очень далёкие координаты (он это мог, потому что хранил игровое поле не в виде потенциально гигантского двумерного массива, а в виде списка координат всех ходов). В честной математической игре это бы привело его к проигрышу, но поскольку глупые соперники начинали пытаться выделить невообразимые объёмы оперативной памяти, чтобы запихать в неё всё гигантское почти пустое поле, то эта странная тактика неплохо срабатывала.

При чём же здесь злость искусственного интеллекта? А при том, что никакого зла у него может и не быть. Но из-за того, что он хорошо умеет добиваться своей цели, нам (например, человечеству) надо не оказываться между ИИ и его целью. Все мы знаем истории про коварных Золотых рыбок и прочих джинов, которые так сбывали мечты, что человек потом искренне жалел, что связался. Поэтому формулировать задачу для ИИ надо вдумчиво.

Два года назад на эту тему доходчиво ответил Стивен Хокинг: «The real risk with AI isn’t malice but competence. A superintelligent AI will be extremely good at accomplishing its goals, and if those goals aren’t aligned with ours, we’re in trouble. You’re probably not an evil ant-hater who steps on ants out of malice, but if you’re in charge of a hydroelectric green energy project and there’s an anthill in the region to be flooded, too bad for the ants. Let’s not place humanity in the position of those ants.»

Позволю себе перевести: «Настоящий риск ИИ не в его злобе, а в его компетентности. Сверхразумный ИИ будет потрясающе хорош в достижении целей, но если они не совпадают с нашими, то мы в беде. Вероятно, вы не коварный ненавистник муравьёв, уничтожающий их из злобы, но если вы строите ГЭС, а в низине есть муравейник, то муравьям не повезло. Давайте не будем ставить человечество в положение тех муравьёв».

Кстати, о муравьях и человечестве мы уже пару раз говорили:
- Сопоставление размеров,
- Не попадайте в муравьеворот (здесь даже о нехватке памяти есть).

Хорошего завершения выходных и удачного начала недели!

Pascal или C для школьников?

Добрый день!

Буквально месяц назад мы отметили 60 лет ENIAC, первого электронного цифрового вычислителя общего назначения, а за три месяца до этого праздновали 200 лет со дня рождения Ады Лавлейс, первого программиста человечества. Поэтому сейчас самый подходящий момент, чтобы подумать об обучении программированию.

Представьте, что у нас есть выбор только между Паскалем и Си. Вроде бы разница мала, так как уже многие десятки лет существуют конвертеры, способные преобразовать код с одного из этих языков на другой, причём в большинстве случаев исправлять результат работы конвертеров даже не приходится. Это нам указывает на огромное сходство языков.

Но есть и отличия. Давайте попробуем их вспомнить.

Итак, плюсы и минусы языков Си и Паскаль:
- В Си есть qsort (наличие развитой сортировки, которой можно подсунуть свою функцию сравнения, сразу сокращает и упрощает код),
- В Паскале есть строки (пусть их длина ограничена 255 символами, но начать с ними работать гораздо проще, а возможностей для ошибок — меньше),
- В Си краткий синтаксис (многих в Паскале раздражало постоянное написание "begin"/"end", а в Си мы пишем "{"/"}"),
- В Паскале LL(1) грамматика (глядя на начало строки, мы это начало сразу понимаем, в то время как в Си, например, с "int " может начинаться что угодно: хоть переменная, хоть указатель на переменную, хоть функция),
- Есть много популярных языков с Си-подобным синтаксисом (C++/C#/Java/...), поэтому поучиться Си стоит,
- В Паскале легко выводить значения разных типов (сравните "write(a, ', ', b);" с "printf("%d, %f", a, b);" — во втором случае пришлось вспоминать, какого типа наши переменные a и b.

Долгое время Pascal считался хорошим языком для обучения. Кстати, отсутствие qsort сразу же приводило к необходимости реализовать сортировку, что не было вредно. Но сейчас на Паскале почти не пишут, поэтому причин учить этому языку школьников практически нет. Насколько я понимаю, главная причина — в ЕГЭ по программированию есть вопросы по Паскалю. Но такое заталкивание языка в детей явно не добавляет им мотивации.

А какие положительные и отрицательные моменты Паскаля и Си вы помните? Можно учить оба, помня, что это почти одно и то же? Или только Си? Готовиться ли к ЕГЭ?

Хорошей недели!

Ссылки по теме:
- Три программы,
- Программисты-олимпиадники,
- Слишком универсально.

Три программы

Тема правильного образования вечна, она всегда будет вызывать массу споров (если бы всё было просто, то и путёвого специалиста было бы легко найти). В современном мире очень важно понимать возможности вычислительных машин (даже тем, кто не собирается идти в программирование), потому что знание компьютеров требуется почти во всех областях знаний. Недавно мы вспоминали, почему мало иметь мощный компьютер и знать язык программирования, а сегодня я хочу предложить три задачки начального уровня, которые могут увлечь ребёнка.

Вообще, на начальном этапе увлечь - это самое важное. Не столько стоит уделять внимание конкретным технологиям, которые осваивает чадо, сколько самому факту - если ребёнку интересна задача, то он осваивает что угодно в сотни раз быстрее и глубже.

Итак, задачи:

1. «Быки и коровы». Правила классические: один задумывает, например, четырёхзначное число, а другой пытается его угадать. Игра проходит так:
а) угадывающий называя свою версию (делает ход),
б) загадавший сообщает, сколько цифр из версии совпало с цифрами загаданного числа по позиции (это количество быков), а сколько совпало по значению, но не совпало по месту (количество коров).
в) если угадывающий назвал загаданное число (тест совпал с загадкой), то игра прекращается, иначе возвращаемся к пункту (а) - угадывающий пробует назвать другое число.

Поясню для тех, кто не знал этой игры. Пусть загадано число 9245, а угадывающий делает ход 1234. Тогда ему приходит следующий ответ от загадавшего: 1 бык (совпали вторые цифры по позиции) + 1 корова (так как в обоих числах есть четвёрки, но они на разных позициях). Это очень полезная информация для отгадывающего, теперь он знает, что среди цифр 1, 2, 3 и 4 ему интересны две, причём одна из них уже стоит на своём месте.

Обычно люди играют в «Быки и коровы» словами (например, пятибуквенными или шестибуквенными), но с компьютером это не так интересно (так как он может делать перебор по словарю), поэтому пусть он пока оперирует числами.

Цель в игре понятна: угадать число за минимальное количество ходов. Проверять программу тоже понятно как: попробовав загадать все возможные числа (их мало - всего 10000), набрать статистику: среднее и максимальное количество попыток на угадывание.

Хорошо, когда этой же задачкой увлекаются несколько школьников. Тогда у них развивается конкуренция: один пишет простейшего игрока, который гарантированно справляется с задачкой за 33 хода, а другой неожиданно приносит версию, которой хватает 27 ходов. Тогда первый отвечает очередным улучшением алгоритма - достигая ещё более радикального снижения среднего числа попыток и т. д. Игра интересная, в ней есть, где думать. Кстати, она приучает к тому, что полезно сначала человеческими мозгами сыграть несколько сотен партий, а уже потом садиться за клавиатуру реализовывать что-то :)

2. «Тетрис» и «Падликс» Сначала пишется обычный тетрис, который состоит из двух компонент:
а) Игровой сервер. Он хранит состояние стакана, положение текущей фигуры, набранные очки. Он же выбирает случайно следующую фигуру, когда текущая фигура коснулась дна или других элементов в стакане.
б) Игрок. На начальном этапе он просто принимает команды с клавиатуры (повернуть, сдвинуть или уронить текущую фигуру).

Когда это сделано, возникает естественный соблазн - сделать компьютерного игрока, чтобы машина играла в тетрис сама с собой. Сначала пишутся простейшие игроки, которые ставят фигуры «как попало», но постепенно удаётся создавать всё более смышлёные программы, которые уверенно разгребают последовательности из десятков тысяч фигур. Здесь, опять же, очень хорошо, когда есть единомышленники, создающие конкурирующих игроков. Можно скармливать одну последовательность фигур двум или более игрокам, наблюдая за качеством их работы (для этого обычно улучшают игровой сервер, чтобы он отображал одновременно два или три стакана, а фигуры в них отправлял одинаковые).

Уже на этом этапе есть масса интересной исследовательской деятельности, но можно пойти дальше. А что если следующая фигура в нашем тетрисе будет генерироваться не случайно, а специальным злым роботом «Падликс»? Человек, который наблюдал за работой играющего в тетрис робота, наверняка замечал, что есть последовательности фигур, с которыми тому трудно справиться. Зная это, можно делать свою программу, которая именно такие последовательности начнёт формировать (и вызывать её игровым сервером вместо генератора случайных чисел).

Здесь открываются новые просторы для улучшения основного игрока: хочется сделать так, чтобы свой игрок в тетрис, получая фигуры от своего «Падликса» набирал много очков, а вражеский игрок на этой же последовательности фигур быстро заваливал стакан. Новый виток конкуренции провоцирует разработку новых умных алгоритмов. Это весело и интересно, поэтому может длиться многими месяцами. Результат очевиден:
а) ребёнок осваивает язык программирования до такого уровня, что уже не замечает сложностей при реализации непростых алгоритмов;
б) большой опыт отладки относительно сложных приложений толкает школьника к более аккуратному программированию (чтобы быть уверенным почти во всех своих строчках, а не выискивать потом неделями ошибки);
в) десятипальцевый слепой метод осваивается сам собой (у меня примерно так было :)

Первые две программы были о математических алгоритмах, которые могут быть близки далеко не всем. А следующая подойдёт, например, филологам-полиглотам:

3. «Умный тренажёр». Классе в шестом-седьмом у меня была проблема с запоминанием неправильных английских глаголов, поэтому я написал тренажёр, который разными способами предлагал показать, какие глаголы я знаю, а какие ещё надо поучить. Важный момент - правильный подход к трате времени: если я недавно правильно отвечал на данный вопрос, то тренажёр его повторит не скоро, а если были ошибки, то вопрос по тому же глаголу будет скоро задан ещё несколько раз в различных вариациях. Здесь можно придумать много хитроумных способов проверять знания, поэтому простор для творчества огромен.

Сложностей с реализации этой задачки быть не должно, она самая простая из этих трёх. Но пользы от неё вполне достаточно:
а) появляется опыт создания приложения с удобным интерфейсом (если будет неудобно, то с этим придётся самому постоянно сталкиваться),
б) во время реализации и отладки тренажёра как-то само собой незаметно в память закладываются сотня неправильных английских глаголов, что тоже полезно :)

Данный перечень программ здесь приведён, поскольку я своими глазами видел, что их реализация может не только затянуть школьника, но и быть ему полезной для развития. А с какими хорошими обучающими примерами знакомы вы?

Хороших выходных!

Программисты-олимпиадники

Данная заметка, конечно, будет не только о программистах, но на их примере очень легко показать плюсы и минусы олимпиадного подхода.

Люди обычно думают, что сильный олимпиадник - это очень эффективный и талантливый работник. Но почему-то жизнь показывает, что это так совсем не каждый раз. Вернее, в отсутствии талантов обвинить олимпиадников трудно, но быть уверенным в их высокой эффективности на работе тоже нельзя.

Я и сам имел олимпиадные успехи в школе и на первых курсах университета, поэтому видел различные ситуации (участники олимпиад друг друга знают). В этой заметке сделана попытка систематизировать отличия между «настоящей» работой и решением олимпиадных задач.

Прежде всего, в реальном мире мы сталкиваемся с плохо формализованными проблемами. Как правило, заказчик примерно представляет, чего хочет, но для реализации проекта надо его долго и дотошно спрашивать. Надо задавать правильные вопросы, улавливая в невнятных ответах фрагменты истинной постановки задачи. Хуже всего, если заказчик упирается в некоторые параметры задачи (несущественные), требуя достижения именно их, но никак не может уточнить то, что необходимо исполнителям. Это приводит к тому, что большая часть работы до момента сдачи проекта будет проделана зря - в последний момент выяснится, что надо было делать совсем другое. Конечно, сейчас рынок уже не дикий - юристы вынудят заказчика доплатить за переделку, однако приятного в этом мало для компании-исполнителя. Кроме того, многих огорчает сам факт, что несколько (десятков) профессионалов тратили своё время на выполнение работы, которая была никому не нужна (согласитесь, приятно не просто получать деньги, а делать нужное дело за деньги).

Специалист, взращённый на олимпиадах, может сделать очень многое и очень быстро. Но он привык получать чёткое описание задачи. Постановка может включать какие угодно жёсткие ограничения (по времени и памяти), но олимпиадник приложит усилия, чтобы в них влезть.

А в реальной жизни ограничения почти всегда не играют определяющей роли. Если сказано, что программа должна использовать не более гигабайта памяти для вычислений, то ничего страшного, если на каких-то входных данных понадобится 1200 мегабайт. И если заказчик ограничивает время работы 15 секундами, то, скорее всего, можно работать 17 (а то и 20). Потому что заказчику необходим модуль, возвращающий результат нужного качества в рамках ограничений, которые он придумал из головы. Другими словами, качество результата очень важно, а частичное выполнение ограничений - это вопрос, почти не создающий проблем при сдаче проекта.

Организация тестирования на олимпиадах и при настоящем программировании отличается кардинально: если олимпиадникам только сообщают, смогла их программа пройти все тесты, придуманные жюри, или нет, то реальный заказчик заинтересован, чтобы программисты как можно раньше увидели, какие входные данные приводят к неудовлетворительным результатам.

Более того, олимпиадник старается проверять свою реализацию на различные граничные эффекты, а в настоящем мире это никому не надо - главное, чтобы приложение работало на нормальных данных. А небольшие сложности на вырожденных примерах - это мелочи, которые обычно не останавливают вменяемого заказчика.

Естественное следствие из частичной формулировки задачи с последующим уточнением - программу придётся много раз переделывать, существенно меняя функциональность отдельных модулей. Почти всегда задача доопределяется в процессе реализации, поэтому наивно надеяться на то, что написанный код останется неизменным. Это значит, что главное в реализации - понятность и модифицируемость. Но у олимпиадника другие привычки: для него понятность программы стоит на последнем месте (ведь её век очень короток - никто кроме него самого не будет читать этот код). А самое главное для программиста-олимпиадника - скорость работы его детища. Поэтому в коде присутствуют всевозможные оптимизационные конструкции, которые существенно понижают читаемость программы, но позволяют отыгрывать драгоценные миллисекунды.

Как мы видим, различия в потребностях компаний и предложениях сильных олимпиадников огромны (и мы не говорим даже о проблеме заужения восприятия из-за высокой квалификации в отдельных областях, мешающей решать простые задачи). Но умный человек на то и умный, чтобы понимать, когда надо меняться. Иногда отделы кадров категорически против людей с олимпиадным прошлым - скорее всего, у них уже был негативный опыт, который они не хотят повторять. Если компания вам действительно интересна, то имеет смысл на собеседовании отчётливо показать, что вам понятны их страхи. Вменяемый руководитель, видя специалиста, понимающего разницу между олимпиадным программированием и тем, что ему надо, не будет долго сомневаться. Потому что он знает, что сильный олимпиадник, принимающий особенности «обычной работы», может творить чудеса.