Closed jchiquet closed 5 years ago
I feel that we won't handle many cases if the covariates cannot be inputted as a list of matrices with dimension n_nodes * n_nodes
@Demiperimetre I think you are right, and it would not be a big deal (even if a bit fastidious) to handle covariates in the code only with arrays. In fact, it would even simplify the code.
However, there is just one place where there is a problem : when dealing with the centred-node MAR sampling with covariates, we need a N x M covariance matrix.
So I know how to pass from this NxM matrix to an NxNxM array with a similarity, but the other way around is more complicated.
Any comment/idea ?
Ma question pour @TabouyT et @Demiperimetre est:
est-il possible de spécifier un modèle pour le processus générant les données manquantes centré sur les noeuds, avec covariables et ceci uniquement à partir d'une liste de M matrices NxN de covariable.
Quand vous aurez répondu à cette question, je saurai quoi faire dans le code. Si ça n'est pas possible, alors l'imputation dans le cas neoud centré avec covariable nécessitera une la matrix N x M d'origine, et ceci uniquement dans ce cas là.
Non je pense que c'est un problème mais serait il possible de dire que le format de cov est une liste de matrice pas forcément de taille N*N et dans le cas de covariables sur les nœuds ce serait jusste une matrice colonne ? Puisque le type d'échantillonnage est donné on aurait des conditions permettant de définir comment accèder aux covariables, ou est ce trop pénible ?
Le lun. 25 mars 2019 à 04:31, Julien Chiquet notifications@github.com a écrit :
Ma question est:
est-il possible de spécifier un modèle pour le processus générant les données manquantes centré sur les noeuds, avec covariables et ceci uniquement à partir d'une liste de M matrices NxN de covariable.
Quand vous aurez répondu à cette question, je saurai quoi faire dans le code. Si ça n'est pas possible, alors l'imputation dans le cas neoud centré avec covariable nécessitera une la matrix N x M d'origine, et ceci uniquement dans ce cas là.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/jchiquet/missSBM/issues/1#issuecomment-476099553, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad_FVrdPqzjGtWS2rvxUITBT538A2c7eks5vaIl2gaJpZM4Zdw0F .
-- Pierre Barbillon https://www6.inra.fr/mia-paris/Equipes/Membres/Pierre-Barbillon
Non je pense que c'est un problème mais serait il possible de dire que le format de cov est une liste de matrice pas forcément de taille N*N et dans le cas de covariables sur les nœuds ce serait juste une matrice colonne ?
Alors, on récapitule @Demiperimetre
Que préférez-vous ?
Oui ta proposition est raisonnable, des listes me semblent une bonne idée.
Je vais encore jouer le relou mais j'ai l'impression qu'on pourrait avoir des cas où les covariables servent pour l'échantillonnage et pas forcément dans la génération du réseau. Par exemple, on pourrait avoir un échantillonnage sur les nœuds mais ne servant pas dans la génération du SBM et des covariables sur les arêtes poru la génération du SBM. As tu réfléchi à ces cas, Timothée ? Serions capables de gérer ça ?
Le lun. 25 mars 2019 à 09:18, Julien Chiquet notifications@github.com a écrit :
Non je pense que c'est un problème mais serait il possible de dire que le format de cov est une liste de matrice pas forcément de taille N*N et dans le cas de covariables sur les nœuds ce serait juste une matrice colonne ?
Alors, on récapitule @Demiperimetre https://github.com/Demiperimetre
- si l'échantillonage est noeud-centré; l'utilisateur doit fournir pour les covariables une matrix N x M ou une liste de M vecteurs de taille N
- si l'échantillonage est dyade-centré; l'utilisateur doit fournir pour les covariables un array N x N x M ou une liste de M matrices de taille N x N
Que préférez-vous ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jchiquet/missSBM/issues/1#issuecomment-476192141, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad_FVoQeT7pElwrptY48hJVOBUkYyLNzks5vaMyXgaJpZM4Zdw0F .
-- Pierre Barbillon https://www6.inra.fr/mia-paris/Equipes/Membres/Pierre-Barbillon
j'ai l'impression qu'on pourrait avoir des cas où les covariables servent pour l'échantillonnage et pas forcément dans la génération du réseau. Par exemple, on pourrait avoir un échantillonnage sur les nœuds mais ne servant pas dans la génération du SBM et des covariables sur les arêtes pour la génération du SBM. Serions capables de gérer ça ?
A priori, ces trois tâches (simulation, sampling et estimation) sont complètement découplées dans le package donc la réponse est "oui".
Tout à fait d’accord, échantillonnage et sbm sont dissociés.
Timothée
Le 25 mars 2019 à 14:45, Julien Chiquet notifications@github.com a écrit :
j'ai l'impression qu'on pourrait avoir des cas où les covariables servent pour l'échantillonnage et pas forcément dans la génération du réseau. Par exemple, on pourrait avoir un échantillonnage sur les nœuds mais ne servant pas dans la génération du SBM et des covariables sur les arêtes pour la génération du SBM. Serions capables de gérer ça ?
A priori, ces trois tâches (simulation, sampling et estimation) sont complètement découplées dans le package donc la réponse est "oui".
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
New Interface partially available (one can specify a slit of matrices of vector to the estimate function).
This basically closes the issues related to covariates "model 2" in Timothée's notes.
We should now add the model 1 for covariates, but this would correspond to a specific issue.
The networkSampling_fit should be splitted into two subclasses, with/without covariates.
The same for the class networkSampling_sampler.
See the structure of SBM_fit for a reference.