Gérer des données d'orientation en ACP
dans Statistiques
Bonjour,
Imaginez que vous avez des données, à analyser en ACP, qui contiennent un certain nombre de variables numériques parfaitement "classiques" sur vos individus, ainsi que des données d'orientation / angulaires. Ces données d'orientation peuvent s'exprimer en degrés (sur une échelle de 360° donc) par rapport à un axe de référence. On a évidemment un problème ici par rapport au cadre classique de l'ACP : en réalité, un individu à 359° a une orientation très proche d'un individu à 1°, mais les deux sont drastiquement opposés si l'information est traitée "classiquement".
Quelle serait selon vous la meilleure façon de prendre en compte ce genre de données d'orientation dans une ACP, pour que les proximités entre individus soient respectées dans tous les cas ?
Merci !
Imaginez que vous avez des données, à analyser en ACP, qui contiennent un certain nombre de variables numériques parfaitement "classiques" sur vos individus, ainsi que des données d'orientation / angulaires. Ces données d'orientation peuvent s'exprimer en degrés (sur une échelle de 360° donc) par rapport à un axe de référence. On a évidemment un problème ici par rapport au cadre classique de l'ACP : en réalité, un individu à 359° a une orientation très proche d'un individu à 1°, mais les deux sont drastiquement opposés si l'information est traitée "classiquement".
Quelle serait selon vous la meilleure façon de prendre en compte ce genre de données d'orientation dans une ACP, pour que les proximités entre individus soient respectées dans tous les cas ?
Merci !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
je pense qu'une piste serait de remplacer la variable 'angle' par 2 nouvelles variables : cos(angle) et sin(angle).
Ca me paraît le plus naturel. C'est l'idée qui vient en premier.
Mais, après réflexion, il reste un petit problème (tout petit), c'est que les résultats vont dépendre d'une donnée arbitraire, qui est l'angle de départ.
Si tu ajoutes 20° à tous tes angles, tu ne changes rien à tes données, c'est juste une convention différente (en tout cas, c'est ce que je pressens), mais ça va donner des résultats un peu différents dans ton ACP
Peut-être que tu peux faire des tests, en prenant même 3 nouvelles variables : cos(angle), cos(angle +120°) et cos(angle+240°)
Ca me paraît un assez bon moyen pour limiter le côté 'arbitraire' de l'angle de départ. Avec en contrepartie, de la redondance dans les données.
Attention : je dis cos(angle+120°) pour prendre le même langage que toi... mais en programmation, il faudra certainement faire cos(angle + 2*pi/3)
Dans à peu près tous les outils informatiques, les angles se mesurent en radians et non en degrés.
> je pense qu'une piste serait de remplacer la variable 'angle' par 2 nouvelles variables : cos(angle) et sin(angle).
Salut,
Merci pour ton idée ! Effectivement j'y avais pensé... mais je n'avais pas pensé au problème que tu évoques ensuite :-D (Surtout qu'en plus, malheureusement, l'axe de référence est relativement arbitraire : il n'y a pas de raison évidente de choisir celui-là plutôt qu'un autre.) Mais ce sera déjà beaucoup mieux.
Merci !
$$
H\mapsto\frac{1}{2} \sum_{i,j}\|\pi_H(x_i)-\pi_H(x_j)\|^2=\frac{1}{2} \sum_{i,j}\|\pi_H(x_i-x_j)\|^2.
$$ L’inconvénient est qu'on a une somme de $n(n-1)/2$ termes, l'avantage est qu'on n'a pas à se soucier d'une origine. Sur la composante périodique cela permet de définir $(\theta_i-\theta_j)^2\leq \pi^2$ comme le carré du plus petit arc entre les deux,