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.
Emmanuel Castella wrote:
> Bonjour
> Merci pour cette réponse. J'aimerais toutefois comprendre ce qu'elle
> signifie pour les utilisateurs de l'ancien ADE-4 (pre-R) qui pouvaient
> (peuvent), sans plus de soucis théoriques, rentrer avec une AFC dans
> Discrimin / LinkPrep / Between Analysis: test, et obtenir avec bonheur
> (et naiveté ?) une jolie "p value"?
> Merci d'avance
> Emmanuel
>
> Stéphane Dray a écrit :
>
>> Bonjour,
>> à ma connaissance, non. Je pense pas que ce soit en projet, quelqu'un
>> me contredira peut-être. La question des tests de permutation avec
>> des poids non uniformes posent de nombreux problèmes théoriques et
>> pratiques. On l'a vérifié il y a très peu de temps avec les tests de
>> coinertie et rlq. Il y avait quelques bugs qui ont été corrigés dans
>> la nouvelle version d'ade4 que vous pouvez télécharger sur CRAN. La
>> liberté de l'utilisateur d'ade4 est grande, il est difficile pour
>> nous de prévoir tous les cas, et c'est pour ça qu'il y a des
>> gardes-fous :
>>
>> if (!(identical(all.equal(X.lw, rep(1/nrow(X), nrow(X))),
>> TRUE))) {
>> stop("Not implemented for non-uniform weights")
>> }
>> C'est assez frustrant pour l'utilisateur, j'en conviens.
>> Le code source d'ade4 est libre, on ne peut pas faire n'importe quoi,
>> l'utilisateur voit tout. On a préferé bloquer là où ça peut faire
>> mal. Au lieu d'apporter des petites briques par ci par la, on a
>> préferé ralentir la construction. Il faudrait un investissement
>> théorique sous la forme d'une publication présentant la stratégie
>> méthodologique et pratique sous la forme d'une programmation propre
>> d'une question générale et assez complexe... pour construire solidement.
>>
>> Cordialement.
>>
>> Emmanuel Castella wrote:
>>
>>> Bonjour
>>> je cherche à tester l'inertie inter-classes d'une AFC inter. Les
>>> fonctions rtest.between et randtest.between me renvoient "Not
>>> implemented for non-uniform weights". Existe-t'il une solution?
>>> Merci beaucoup par avance
>>> E. Castella
>>>
>>
>>
>
>
-- 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 : Fri Dec 02 2005 - 10:37:38 MET