Le mail d'Emmanuel Castella donne à réfléchir.
Je résume.
/1) Pourquoi trouve-t-on une clef sur le randtest.between sur une COA
dans ade4 ?
/2) On vient de la mettre parce que Stéphane Dray a découvert un bug
dans ce genre de test sur une ACM.
Dans une ACM dont les poids des lignes sont imposés de l'extérieur (par
la permutation de l'autre tableau) les poids des colonnes en dérivent.
On n'avait pas pris en compte cet effet de bord.
3) Par précaution, on a mis des clefs partout en attendant de faire le
point.
/4) Alors que penser des tests faits avec ADE-4 ? C'est le même code ?
/5) Bonne question : dans *randtest.between* pas de problème le test
était valide, il l'est encore et la clef est abusive.
Faire sauter les trois lignes de randtest.between
if (!(identical(all.equal(X.lw, rep(1/nrow(X), nrow(X))), TRUE))) {
stop("Not implemented for non-uniform weights")
}
Ici le gag trouvé par Stéphane ne peut pas se produire, la ligne est
toujours associée à son poids et la pondération colonne est invariante.
Le calcul est en langage S dans rtest.between et reproduit en langage C
dans randtest.between.
On a été trop prudent. Par contre un test de co-inertie entre une ACM et
une AFC est effectivement douteux dans ADE-4 et interdit dans ade4.
Merci Emmanuel, on prendra en compte cette modification.
DC
Stéphane Dray a écrit :
> Je n'ai pas accès au code source. Je pense que c'est bon, on fera
> confiance aux auteurs.
> Le fait est qu'il y avait des problèmes au niveau des tests. De
> mémoire, si on couple une afc et une acm en coinertie, les
> ponderations colonnes de l'acm doivent changer, or ce n'était pas le
> cas. Le débat est technique mais aussi théorique: si on dit qu'on
> change les pondérations colonnes, il faut expliquer pourquoi.
> L'utilisateur a accès au code, il faut que tout soit lisible et
> cohérent, basé sur un cadre théorique clairement défini. Il y avait
> egalement d'autres bugs. J'en ai corrigé certains et pour d'autres
> j'ai préferé mettre des stops plutot que reprogrammer au cas par cas.
> C'est expliqué, par exemple, dans l'aide de randtest.coinertia, dans
> laquelle j'ai rajouté une partie 'Note'.
> Le passage ADE4->ade4 a demandé un effort conséquent de programmation
> (demandez à Daniel), l'objectif est que tout soit le plus propre et le
> plus clair possible. On pourrait facilement reprogrammer ce cas
> particulier et bien d'autres... Je ne pense pas que ce soit la
> stratégie du groupe à l'heure actuelle. Il vaudrait mieux se poser les
> problèmes clairement afin de repartir sur des bases saines, d'un point
> de vue théorique, et programmer une stratégie générale. C'est ce qu'on
> observe dans la partie diagonalisation : un cadre général (dudi), une
> fonction (as.dudi) et des cas particuliers (dudi.pca, dudi.coa...). On
> doit refaire la même chose pour les tests, en gérant en plus
> l'interface avec le C (pour la rapidité).
> C'est pour cela qu'on a perdu des fonctions dans le passage (pas de
> test pour les acpvi, cca...)... pour mieux préparer l'avenir.
>
>
This archive was generated by hypermail 2b30 : Sun Dec 04 2005 - 16:09:20 MET