L'apprentissage automatique en OCaml ou Haskell ?

Question

J'espère pouvoir utiliser Haskell ou OCaml sur un nouveau projet car R est trop lent. J'ai besoin de pouvoir utiliser des machines vectorielles de support, idéalement en séparant chaque exécution pour qu'elle se déroule en parallèle. Je veux utiliser un langage fonctionnel et j'ai le sentiment que ces deux-là sont les meilleurs en ce qui concerne les performances et l'élégance (j'aime bien Clojure, mais il n'était pas aussi rapide dans un court test). Je penche pour OCaml parce qu'il semble y avoir plus de support pour l'intégration avec d'autres langages, donc il pourrait être un meilleur ajustement à long terme (par ex. OCaml-R ).

Quelqu'un connaît-il un bon tutoriel pour ce type d'analyse, ou un exemple de code, en Haskell ou en OCaml ?

Answer 1

Hal Daume a écrit plusieurs grands algorithmes d'apprentissage automatique pendant son doctorat (il est aujourd'hui professeur adjoint et étoile montante de la communauté de l'apprentissage automatique).

Sur sa page web, on trouve un SVM, un arbre de décision simple et une régression logistique, tous en OCaml. En lisant ces codes, vous pouvez vous faire une idée de la manière dont les modèles d'apprentissage automatique sont mis en œuvre en OCaml.

Un autre bon exemple d'écriture de modèles d'apprentissage automatique de base est le suivant Bibliothèque de la chouette pour les calculs scientifiques et numériques en OCaml.

J'aimerais également mentionner F#, un nouveau langage .Net similaire à OCaml. Voici un modèle de graphe factoriel écrit en F# et analysant des données de jeu d'échecs. Cette recherche a également fait l'objet d'une publication NIPS.

Alors que la FP convient à la mise en œuvre de modèles d'apprentissage automatique et d'exploration de données. Mais ce que vous pouvez obtenir le plus ici n'est PAS la performance. Il est vrai que la FP supporte mieux le calcul parallèle que les langages impératifs, comme C# ou Java. Mais la mise en œuvre d'un SVM ou d'un arbre de décision parallèle n'a pas grand-chose à voir avec le langage ! Le parallèle est le parallèle. Les optimisations numériques qui sous-tendent l'apprentissage automatique et l'exploration de données sont généralement impératives, les écrire de manière purement fonctionnelle est généralement difficile et moins efficace. Rendre ces algorithmes sophistiqués parallèles est une tâche très difficile au niveau de l'algorithme, pas au niveau du langage. Si vous voulez exécuter 100 SVM en parallèle, FP peut vous aider. Mais je ne vois pas la difficulté d'exécuter 100 libsvm en parallèle en C++, sans compter que le single thread libsvm est plus efficace qu'un paquet svm haskell non testé.

Alors que donnent les langages FP, comme F#, OCaml, Haskell ?

1. Facilité de test de votre code. Les langages FP ont généralement un interpréteur de haut niveau, vous pouvez tester vos fonctions à la volée.

2. Peu d'états mutables. Cela signifie qu'en passant le même paramètre à une fonction, cette fonction donne toujours le même résultat, donc le débogage est facile dans les FP.

3. Le code est succinct. Inférence de type, correspondance de motifs, fermetures, etc. Vous vous concentrez davantage sur la logique du domaine, et moins sur la partie langage. Ainsi, lorsque vous écrivez le code, votre esprit pense principalement à la logique de programmation elle-même.

4. Écrire du code en FP est amusant.

Answer 2

Le seul problème que je vois est qu'OCaml ne supporte pas vraiment le parallélisme multicore, alors que GHC a un excellent support et de bonnes performances. Si vous cherchez à utiliser plusieurs threads d'exécution, sur plusieurs appels, GHC Haskell sera beaucoup plus facile.

Deuxièmement, la FFI Haskell est plus puissante (c'est-à-dire qu'elle fait plus avec moins de code) que celle d'OCaml, et davantage de bibliothèques sont disponibles (via Hackage : http://hackage.haskell.org ), donc je ne pense pas que les interfaces étrangères seront un facteur décisif.

Answer 3

En ce qui concerne l'intégration multilingue, la combinaison de C et Haskell est remarquablement facile, et je le dis en tant que personne qui est (contrairement à dons ) Je ne suis pas vraiment un expert en la matière. Tout autre langage qui s'intègre bien au C ne devrait pas être beaucoup plus difficile ; vous pouvez toujours vous rabattre sur une fine couche d'interface en C si ce n'est pas le cas. Pour le meilleur ou pour le pire, le C reste le lingua franca de programmation, donc Haskell est plus qu'acceptable dans la plupart des cas.

...mais. Vous dites que vous êtes motivé par des questions de performance, et que vous voulez utiliser "un langage fonctionnel". J'en déduis que vous n'êtes pas familier avec les langages dont vous parlez. Parmi les caractéristiques qui définissent Haskell, il y a le fait qu'il utilise, par défaut, les fonctions suivantes évaluation non stricte y structures de données immuables -- qui sont tous deux incroyablement utiles à bien des égards, mais cela signifie également que l'optimisation de Haskell pour les performances est souvent très différente de celle d'autres langages, et que des instincts bien rodés peuvent vous égarer de manière déconcertante. Vous voudrez peut-être parcourir sujets relatifs aux performances sur le wiki Haskell pour avoir une idée des problèmes.

Ce qui ne veut pas dire que vous ne pouvez pas faire ce que vous voulez en Haskell - vous le pouvez certainement. La paresse et l'immuabilité peuvent en fait être exploitées pour améliorer les performances ( La thèse de Chris Okasaki fournit quelques exemples intéressants). Mais sachez qu'il y aura une certaine courbe d'apprentissage lorsqu'il s'agira de gérer les performances.

Haskell et OCaml offrent tous deux les beaux avantages de l'utilisation d'un langage de la famille ML, mais pour la plupart des programmeurs, OCaml est susceptible d'offrir une courbe d'apprentissage plus douce et de meilleurs résultats immédiats.

Answer 4

Il est difficile de donner une réponse définitive à cette question. Haskell a les avantages que Don a mentionnés, ainsi qu'un système de types plus puissant et une syntaxe plus propre. OCaml sera plus facile à apprendre si vous venez de n'importe quel autre langage (parce que Haskell est aussi fonctionnel que les langages fonctionnels), et travailler avec des structures mutables à accès aléatoire peut être un peu compliqué en Haskell. Vous trouverez aussi probablement les caractéristiques de performance de votre code OCaml plus intuitives que celles de Haskell en raison de l'évaluation paresseuse de Haskell.

Vraiment, je vous recommande d'évaluer les deux si vous avez le temps. Voici quelques ressources pertinentes sur Haskell :

• http://hackage.haskell.org/package/hslibsvm
• http://hackage.haskell.org/package/HSvm
• Haskell dans le monde réel : il s'agit d'un excellent livre disponible gratuitement pour Haskell.
• Apprendre un Haskell Ce tutoriel est tout simplement amusant à lire.

Oh, si vous vous intéressez de plus près à Haskell, n'oubliez pas de vous inscrire à l'événement Débutants en Haskell y Café Haskell listes. La communauté est amicale et désireuse d'aider les nouveaux arrivants (mon parti pris se manifeste-t-il ?).

Answer 5

Si la vitesse est votre principale préoccupation, optez pour le C. Haskell est assez bon en termes de performances, mais vous n'arriverez jamais à être aussi rapide que le C. À ma connaissance, le seul langage fonctionnel qui a dépassé le C dans un benchmark est Stalin Scheme, mais il est très ancien et personne ne sait vraiment comment il fonctionne.

J'ai écrit des bibliothèques de programmation génétique où les performances étaient essentielles et je les ai écrites dans un style fonctionnel en C. Le style fonctionnel m'a permis de les paralléliser facilement en utilisant OMP et elles évoluent linéairement jusqu'à 8 cœurs dans un seul processus. Vous ne pouvez certainement pas faire cela en OCaml, bien que Haskell s'améliore sans cesse en matière de concurrence et de parallélisme.

L'inconvénient d'utiliser le C est qu'il m'a fallu des mois pour finalement trouver tous les bogues et arrêter les vidages du noyau, ce qui était extrêmement difficile en raison de la concurrence. Haskell aurait probablement détecté 90 % de ces bogues dès la première compilation.

La vitesse à tout prix ? Avec le recul, je regrette de ne pas avoir utilisé Haskell, car je pouvais supporter d'être 2 à 3 fois plus lent si j'avais gagné plus d'un mois en temps de développement.