Version imprimable
Bonjour,
en ce moment je m'intéresse aux classes de politique et j'ai lu à plusieurs endroits que les politiques doivent être choisies orthogonales, c'est-à-dire qu'elles ne doivent pas dépendre les unes des autres. J'ai deux petites questions à ce propos :
1. est-il toujours possible de trouver des politiques orthogonales?
2. si la réponse à 1. est négative, quoi faire lorsqu'il y a orthogonalité?
3. quelles sont les conséquences de l'orthogonalité?
Merci d'avance pour vos réponses!
C'est original je sais, mais ma réponse a plus de sens dans la direction inverse.Citation:
Envoyé par Aleph69
3) il est nécessaire qu'elles soient orthogonales. Dans le cas contraire, celà signifie qu'une politique dépends d'un comportement particulier qu'elle ne maitrise pas. Il y a risque que l'utilisateur ne les utilise pas ensemble, ce qui au mieux ne rendra pas le service souhaité.
2) une politique dépends d'une autre politique, c'est qu'il y a un problème de design. Regrouper les deux politiques dans la même est une solution possible.
1) normallement, oui, à moins que la classe dont le comportement est modifié par ce biais ne soit pas bien conçue.
Une autre solution peut aussi être d'extraire une autre politique dont dépendront les deux politiques envisagées.Citation:
Envoyé par Emmanuel Deloget
Bonsoir,
merci pour vos réponses. Après réflexion, je dois effectivement avoir un problème de conception. Il y a quand même de quoi s'arracher les cheveux. En ce moment j'essaie de faire une classe pour représenter des matrices et il n'est pas si évident de trouver des politiques totalement orthogonales pour les décrire. J'étais parti pour définir mes matrices en fonction de trois politiques :
1. une politique de stockage (formats denses, formats creux)
2. une politique de structuration symbolique (générale, diagonale, tridiagonale, bidiagonale, hessenberg, ...)
3. une politique de structuration numérique (symétrique, hermitienne, non-symétrique, non-hermitienne).
Seulement, ces trois politiques sont clairement liées les unes aux autres. Je vais me pencher sur la question mais si quelqu'un a déjà été confronté au problème, je suis preneur de tout conseil.
On avait le meme probleme dans nt2. On l'a résolu en décorrélant les spécifications de policies au niveau utilisateur et celle utilisez en interne.
Parmi toute sles policies spécifiées par 'lutilisateurs, certaines sotn utilisés pour du tag dispatchign par d'autres.
En gros, la policy de stockage est la vrai policy. L'objet Storage est passé à une fonction access qui prend la policy de structure numerique en paramétre.
qui renvoit l'élément de s à la position pos en tenant compte du layout et de la shape.Code:
2
3
L'autre truc qu'on avait testé est de passé Storage, Shape et Layout à une Facade qui construit l'objet de stockage avec la bonne aggrégation de comportement.
Merci pour ta réponse Joel.
C'est une bonne idée de décorréler les politiques de cette manière.
Je viens de télécharger NT2 pour regarder comment tout cela est fait.
J'ai une question concernant les matrices symétriques/hermitiennes. A priori, pour une telle matrice, le choix du format de stockage est assez limité : cela se résume à stocker de manière dense ou creuse la partie triangulaire inférieure ou la partie triangulaire supérieure. Pour ce cas particulier, je ne vois pas comment vous avez pu vous en sortir dans NT2 avec la solution que tu mentionnes, puisque vous semblez avoir mis une sorte de priorité sur le format de stockage par rapport aux autres politiques. Dans ce cas précis, j'ai l'impression que la politique de structuration numérique doit prendre le pas sur la politique de stockage. Vous n'avez pas eu de problème sur ce point précis?
En quoi est-ce que ces différences forment-elles des politiques ? A quel niveau introduisent-t-elle des changements de comportements (c'est le propre d'une politique, après tout) ?Citation:
Envoyé par Aleph69
Quelle sont les combinaisons possibles ?
Peut-on envisager des politiques de politiques (et donc des politiques paramétrables) ?
Bonjour,
Il y a essentiellement deux types de changement de comportement. Le premier concerne bien entendu l'accès aux éléments de la matrice. Le second concerne le choix de l'algorithme employé pour telle ou telle tâche. On ne résout pas un système linéaire de la même manière selon que la matrice associée est diagonale, triangulaire, etc.Citation:
Envoyé par Emmanuel Deloget
Dans la première idée que j'avais à l'esprit, beaucoup mais pas toutes et cela pose problème. C'est la raison d'être de ma question dans mon message précédent. On peut faire des politiques plus ou moins précises. Plus le niveau de précision augmente, plus le nombre de combinaisons non autorisées augmente. Typiquement, on peut s'interroger sur la pertinence de séparer les politiques de structuration (symbolique et numérique). Dans ton message précédent, tu suggères de fusionner les politiques qui ne sont pas orthogonales et cela s'appliquerait plutôt bien dans ce cas (en fait ça résoudrait tous les problèmes je pense). La question est de savoir si on peut faire mieux.Citation:
Envoyé par Emmanuel Deloget
Pourquoi pas!Citation:
Envoyé par Emmanuel Deloget
Tu dois télécharger la version sourceforge qui contient ça, la version github n'est pas a jour de ce coté (et va tres certainement changer de forme). Sidenote: ce vieux code est infamement moche de part les stadnards modernes :aie:Citation:
Envoyé par Aleph69
Sinon, dans nt2 on differencie le stockage de la forme. Tu peut très bien avoir une matrice diagonale (les valeurs non triviales sont sur les indices i,j telles que i==j) mais stockées de maniere dense (N*N éléments) : tu gagnes en vitesse mais pas en mémoire. Si tu demande une diagonale "compacte" (selon la terminologie LAPACK), tu ne stockes que N éléments. Tu gagne en mémoire et un peu moins en vitesse car les accés i,j contiennent une validation. Enfin tu as un stockage diagonale dit sparse qui comme le diagonale compacte ne contient que N éléments mais ne modèlise pas ce qu'on appelle dans NT2 un IndexedContainer et ne propose pas de operator()(i,j) et donc ne manipule toujours que les éléments non triviaux.
Avec un découpage comme celui ci, le stockage modifie les appel à l'allcoateur, la forme le calcul à l'indexage de l'objet stockage. On redevient orthogonale.
Bonjour,
tout d'abord merci beaucoup pour votre aide à tous.
J'ai finalement opté pour une solution de politique paramétrable comme l'a suggéré Emmanuel.
Chaque matrice est définie par sa "structure" et sa "précision". La précision correspond au type numérique des coefficients. La structure est comprise en un sens très large et peut être paramétrable.
Par exemple, la structure "Diagonal" n'est pas du tout paramétrable car il n'y a qu'un seul format de stockage possible. En revanche, la structure "Tridiagonal" peut admettre divers formats de stockage (dense, coo, crs, ccs, etc).
Cette approche me permet de gérer tous les cas dont j'ai besoin sans devoir traiter les combinaisons qui ne me sont pas utiles.