Ok pour l'AFC,
mais on considère le cas extrement tordu d'une ACM inter avec
ponderations non uniformes...
La procédure est fausse si on enlève le stop.
A+
Daniel Chessel wrote:
> 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.
>>
>>
>
>
>
-- Stéphane DRAY (dray@biomserv.univ-lyon1.fr ) Laboratoire BBE-CNRS-UMR-5558, Univ. C. Bernard - Lyon I 43, Bd du 11 Novembre 1918, 69622 Villeurbanne Cedex, France Tel: 33 4 72 43 27 57 Fax: 33 4 72 43 13 88 http://www.steph280.freesurf.fr/
This archive was generated by hypermail 2b30 : Tue Dec 06 2005 - 11:57:41 MET