ELKI (également sur GitHub ) est un projet open source d'exploration de données et de science des données. Il est unique par son architecture modulaire: vous pouvez combiner des algorithmes, des fonctions de distance et des index d'accélération avec très peu de limitations (bien sûr, les algorithmes qui n'utilisent pas de distances ne peuvent pas être combinés avec des distances). Ce n'est pas le code le plus simple en raison de son efficacité. Pour l'exploration de données, vous devez faire attention à la mémoire - l'utilisation ArrayList<Integer>
est un pas si vous voulez une évolutivité.
En raison de l'architecture modulaire, il est facile de contribuer uniquement à de petits modules, comme une fonction ou un algorithme à distance unique.
Nous gardons une liste de idées de projets d'exploration données , grossièrement regroupées par difficulté. La plupart des projets consistent à implémenter une variante d'un algorithme. ELKI vise à permettre des études comparatives d'algorithmes, nous essayons donc de permettre toute combinaison, et couvrons également des variantes d'algorithmes. Par exemple, avec k-means, nous avons non seulement l'algorithme de Lloyds, mais 10 variantes du thème général de k-means. Plus de 220 articles ont été (au moins partiellement) réimplémentés dans ELKI.
En mettant tout en œuvre dans le même outil, nous obtenons des résultats beaucoup plus comparables. Si vous utilisez R pour l'analyse comparative, vous comparez généralement des pommes et des oranges. k-means dans R lui-même est en fait un ancien programme Fortran, et très rapide. k-means dans R mais dans le package "flexclust" est 100x plus lent, car il est écrit en vrai code R. Alors ne faites pas confiance à un benchmark dans R ... aussi, les modules R ont tendance à être incompatibles, donc vous ne pouvez souvent pas utiliser la distance A des modules A avec l'algorithme B du module B. dans ELKI, nous essayons de partager autant de code que dans toutes les implémentations pour réduire ces artefacts (il ne sera bien sûr jamais possible d'avoir un benchmark 100% juste - il y a toujours de la place pour l'optimisation), mais aussi pour permettre de combiner facilement des modules.
Vous pouvez commencer par quelque chose de petit, comme la variante Hartigan & Wong k-means, puis continuer dans les k-means sphériques (qui sont destinés aux données rares, où différentes optimisations de performances peuvent devenir nécessaires) et continuer à ajouter un meilleur support pour les données catégorielles; ou en ajoutant une fonctionnalité d'indexation.
J'aimerais aussi voir une meilleure interface utilisateur pour ELKI , mais c'est un effort majeur.