La raison pratique c'est de pouvoir stocker des tableaux de données quantitatives (numériques), qualitatives et nominales pour faire de l'apprentissage statistique (les trois types de données pouvant bien sûr coexister dans un même tableau).
A ce stade, les opérations à effectuer ne sont ni plus ni moins celles d'un bête tableur.
Attention, tu peux, effectivement, avoir des données quantitative et des données qualitatives dans ton tableau, mais, si tu effectue des calculs sur les données quantitative, tu ne va absolument pas utiliser les données qualitative pour autre chose que de te permettre de... trier tes données quantitatives, et inversement.
Tu entres donc dans un contexte dans lequel tu a beaucoup plus besoin de tuple (une donnée quantitative correspond à un donnée qualitative) que dans celui dans lequel les deux doivent se retrouver "en vrac" dans ton tableau
Après, il y a effectivement un prétraitement de données et je me retrouve avec des données numériques uniquement (le cas que tu envisages).
Les tableaux sont volumineux et j'y accède souvent : je ne peux pas me permettre de stocker en ram la copie "mixte" et la copie "numérique".
Je suis entièrement d'accord avec toi pour les questions de précision numérique mais dans ce cas particulier je ne suis pas concerné.
C'est donc bien la preuve que tu vas toujours mettre... des valeurs de type identique dans ton tableau, dés lors, pourquoi s'embêter à vouloir que tous ces types de valeurs aient une base commune
De ce que j'ai pu constater, cela ne prend pas du tout de temps tant que je n'ai pas de classe abstraite. Avec l'abstraction de classe et gcc, le temps de calcul d'une addition est quand même multipliée par 13!
Sauf quand tu veux savoir si la couleur de tes pommes est corrélée à celle de tes poires.
Plus sérieusement, merci pour l'idée de la spécialisation ça va me faire gagner un niveau de hiérarchie!
Partager