Машинное обучение в OCaml или Haskell?
Я надеюсь использовать или Haskell или OCaml на новом проекте, потому что R является слишком медленным. Я должен быть в состоянии использовать машины победы поддержки, идеально выделяя каждое выполнение для выполнения параллельно. Я хочу использовать функциональный язык, и у меня есть чувство, что эти два являются лучшими, насколько производительность и элегантность затронуты (мне нравится Clojure, но это не было столь же быстро в коротком тесте). Я склоняюсь к OCaml, потому что, кажется, существует больше поддержки интеграции с другими языками, таким образом, это могло быть лучшее, приспособленное в длительный период (например, OCaml-R).
Кто-либо знает о хорошем учебном руководстве для этого вида анализа или примере кода, или в Haskell или в OCaml?
9 ответов
Хэл Даум написал несколько основных алгоритмов машинного обучения во время своей докторской диссертации. (теперь он доцент и восходящая звезда в сообществе машинного обучения)
На его веб-странице есть SVM, простое дерево решений и логистическая регрессия в OCaml. Прочитав этот код, вы сможете почувствовать, как модели машинного обучения реализованы в OCaml.
Еще одним хорошим примером написания базовых моделей машинного обучения является библиотека Owl для научных и числовых вычислений в OCaml.
Я также хотел бы упомянуть F #, новый язык .Net, похожий на OCaml. Вот модель факторного графа , написанная на F # и анализирующая данные игры в шахматы. Это исследование также есть в публикации NIPS.
Хотя FP подходит для реализации моделей машинного обучения и интеллектуального анализа данных. Но то, что вы можете получить здесь больше всего, - это НЕ производительность. Верно, что FP поддерживает параллельные вычисления лучше, чем императивные языки, такие как C # или Java. Но реализация параллельной SVM или дерева решений имеет очень мало общего с языком! Параллель есть параллель. Численные оптимизации, стоящие за машинным обучением и интеллектуальным анализом данных, обычно необходимы, писать их чисто функционально обычно сложно и менее эффективно. Сделать эти сложные алгоритмы параллельными - очень сложная задача на уровне алгоритмов, а не на уровне языка. Если вы хотите запустить 100 SVM параллельно, здесь поможет FP. Но я не вижу трудностей с запуском 100 libsvm параллельно в C ++, не считая того, что однопоточный libsvm более эффективен, чем плохо протестированный пакет haskell svm.
Тогда что дают языки программирования FP, такие как F #, OCaml, Haskell?
Легко проверить ваш код. Языки FP обычно имеют интерпретатор верхнего уровня, вы можете тестировать свои функции на лету.
Несколько изменчивых состояний. Это означает, что, передавая один и тот же параметр функции, эта функция всегда дает один и тот же результат, поэтому отладка в FP очень проста.
Код лаконичный. Вывод типов, сопоставление с образцом, замыкания и т. Д. Вы больше сосредотачиваетесь на логике предметной области, а не на языковой части. Поэтому, когда вы пишете код, ваш разум в основном думает о самой логике программирования.
Писать код в FP - это весело.
Единственная проблема, которую я вижу, заключается в том, что OCaml не очень поддерживает многоядерный параллелизм, в то время как GHC имеет отличную поддержку и производительность. Если вы хотите использовать несколько потоков выполнения при нескольких вызовах, GHC Haskell будет намного проще.
Во-вторых, FFI Haskell более мощный (то есть, он делает больше с меньшим количеством кода), чем у OCaml, и доступно больше библиотек (через Hackage: http://hackage.haskell.org ), так что я не думаю, что иностранные интерфейсы будут решающим фактором.
Трудно дать однозначный ответ на этот вопрос. У Haskell есть преимущества, о которых упомянул Дон, а также более мощная система типов и более чистый синтаксис. OCaml будет легче изучать, если вы пришли почти с любого другого языка (это потому, что Haskell является функциональным языком), а работа с изменяемыми структурами произвольного доступа может быть немного неуклюжей в Haskell. Вы также, скорее всего, найдете характеристики производительности вашего кода на OCaml более интуитивно понятными, чем на Haskell, из-за ленивой оценки в Haskell.
На самом деле, я бы рекомендовал вам оценить оба варианта, если у вас есть время. Вот некоторые релевантные ресурсы по Haskell:
- http://hackage.haskell.org/package/hslibsvm
- http://hackage.haskell.org/package/HSvm
- Real World Haskell: это отличная свободно распространяемая книга по Haskell
- Learn You a Haskell: этот учебник просто интересно читать
О, если вы будете изучать Haskell дальше, обязательно подпишитесь на списки Haskell Beginners и Haskell Cafe. Сообщество дружелюбно и охотно помогает новичкам (проявляется ли моя предвзятость?).
Что касается многоязычной интеграции, объединение C и Haskell на удивление легко, и я говорю это как человек, который (в отличие от dons ) и в этом я не особо разбираюсь. Любой другой язык, который хорошо интегрируется с C, не должен быть намного сложнее; вы всегда можете вернуться к тонкому слою интерфейса в C, если ничего больше. Хорошо это или плохо, но C по-прежнему остается языком программирования lingua franca , поэтому Haskell более чем приемлем для большинства случаев.
... но. Вы говорите, что вас мотивируют проблемы с производительностью и вы хотите использовать «функциональный язык». Из этого я делаю вывод, что вы ранее не знакомы с языками, о которых спрашиваете. Среди определяющих особенностей Haskell то, что он по умолчанию использует нестрогую оценку и неизменяемые структуры данных , которые невероятно полезны во многих отношениях, но это также означает, что оптимизация Haskell потому что производительность часто резко отличается от других языков, и хорошо отточенные инстинкты могут сбить вас с пути. Вы можете просмотреть темы, связанные с производительностью, на вики-странице Haskell , чтобы понять, в чем заключаются проблемы.
Это не значит, что вы не можете делать то, что хотите в Haskell - вы определенно можете. И лень, и неизменяемость могут фактически использоваться для повышения производительности ( тезис Криса Окасаки дает несколько хороших примеров). Но имейте в виду, что когда дело доходит до производительности, придется немного потрудиться.
И Haskell, и OCaml предоставляют прекрасные преимущества использования языка семейства ML, но для большинства программистов OCaml, вероятно, предложит более мягкую кривую обучения и лучшие немедленные результаты.
Хотя это верно, что многоядерный параллелизм на уровне потока лучше поддерживается в Haskell, похоже, что вы могли бы жить с уровнем процесса параллелизм (из вашей фразы: идеально разделяет каждое выполнение для параллельного выполнения .), который довольно хорошо поддерживается в OCaml. Кейт указал, что Haskell имеет более мощную систему типов, но можно также сказать, что OCaml имеет более мощную модульную систему, чем Haskell.
Как отмечали другие, кривая обучения OCaml будет ниже, чем у Haskell; вы, вероятно, будете более продуктивны в OCaml. Тем не менее, изучение OCaml - отличная ступенька к изучению Haskell, потому что многие из основных концепций очень похожи, поэтому вы всегда можете перейти на Haskell позже и найти там много знакомого. И, как вы отметили, есть мост OCaml-R.
В качестве примеров использования Haskell и Ocaml в машинном обучении см. Материалы на домашних страницах Hal Daume и Lloyd Allison . ИМО, в Ocaml гораздо проще достичь производительности, подобной C ++, чем в Haskell. Благодаря, как уже было сказано, у Haskell гораздо более приятное сообщество (пакеты, инструменты и поддержка), синтаксис и функции (например, FFI, вероятностные монады через классы типов) и поддержка параллельного программирования.
После обновления OCaml-R у меня есть несколько замечаний по интеграции OCaml и R. Возможно, стоит использовать OCaml для вызова кода R , это работает, но еще не совсем понятно. Так что использовать его для пилотирования R. Более тщательная интеграция функциональности R по-прежнему обременительна, поскольку, например, многое еще предстоит сделать для беспрепятственного экспорта системы типов R и данных в OCaml (вам придется поработать).Более того, взаимодействие сборщика мусора R и сборщика мусора OCaml является деликатным моментом: вы освобождаете n значений за время O (n ^ 2), что нехорошо (для решения этой проблемы вам либо нужен более гибкий R API, насколько это возможно). как я понимаю, или реализовать сборщик мусора в самой привязке как большой массив R для правильного взаимодействия между сборщиками мусора).
Вкратце, я бы выбрал подход «пилотный R из OCaml».
Мы приветствуем вклад в уровень взаимодействия сборщика мусора и отображение типов данных R в OCaml.
Возможно, вы захотите взглянуть на это : http://www.haskell.org/pipermail/haskell-cafe/2010-May/077243.html
Если скорость - ваша главная забота, выбирайте C. Haskell довольно хорош в плане производительности, но вы никогда не добьетесь такой же скорости, как C. Насколько мне известно, единственный функциональный язык, который превзошел C в бенчмарке - это Stalin Scheme, но он очень старый, и никто толком не знает, как он работает.
Я писал библиотеки генетического программирования, где производительность была ключевым фактором, и я написал их в функциональном стиле на C. Функциональный стиль позволил мне легко распараллелить их с помощью OMP, и они линейно масштабируются до 8 ядер в одном процессе. В OCaml такого точно не получится, хотя Haskell постоянно совершенствуется в отношении параллелизма и параллельности.
Недостатком использования C было то, что мне потребовались месяцы, чтобы найти все ошибки и остановить дампы ядра, что было чрезвычайно сложно из-за параллелизма. Haskell, вероятно, отловил бы 90% этих ошибок при первой компиляции.
Итак, скорость любой ценой? Оглядываясь назад, я жалею, что не использовал Haskell, поскольку я мог бы смириться с тем, что он был в 2-3 раза медленнее, если бы я сэкономил более месяца времени на разработку.