Je suis du même avis. En plus, en enlevant les lignes de code commentées inutiles, en utilisant mieux les classes générées avec les DataSet typés (comme EMIRapportDataSet.MarketingRow) et en compressant un peu les tests divers, on aurait un code 3 fois moins long et bien plus lisible. Et même avec ça, je ne vois toujours pas l'intérêt.

Ca marche au premier abord, mais il y a quelques problemes :

1) gain += -proba*Math.log(proba) -> Nan  si proba==0 et ca arrive souvent. Normalement, la fonction d'entropie renvoie 0 si proba==0, et cela change la structure de l'arbre, puisqu'on additionne des NaN ce qui fausse tout (autrement dit l'arbre est faux).

2) Le calcul du gain ne fait meme pas intervenir les classes a predire et de toute facon on est tres loin de la vraie formule de calcul du gain (voir : http://www.supinfo-projects.com/fr/2006/algo%5Fid3%5Fc45/3/ ). Peut-etre que le but n'etait pas de calculer le gain, mais alors appeler la fonction "gainAttribut" induit en erreur.

En clair, ca vaut pas du tout une moyenne de 9 puisque c'est faux.

remplacez le </HTML> par </html>  (derniere ligne) sinon on a le fameux point d'interrogation !!
pas serieux ca...

danious