Manipulation d'un vecteur basée sur certaines valeurs de ses élements

Bonjour,

Par plusieurs boucles conditionnelles, j'obtiens un vecteur valeur qui contient 6 valeurs soit de 1 ou de -1.

Je voudrais émettre des conditions sur ce vecteur, du genre prendre en compte certaines combinaisons pour de futures instructions :

la première combinaison est par exemple : [1,1,a,b,c,d] quelle que soit la valeur logique de a,b,c,d !

Existe t'il une instruction qui puisse prendre en compte cela?
du genre :

Code:

---

1 2 3 4 5

if valeur == [1,1,.,.,.,.] instructions else continue

---

Merci !

M.

quelque chose du type

Code:

---

if (vecteur[0]==1 and vecteur[1]==1)

---

Je suis bien d'accord que cela semble le plus logique, mais compte tenu que je dois prendre en compte 6 combinaisons de combinaisons :

C1 = [1,1,.,.,.,.]
C2 = [-1,-1,.,.,.,.]
C3 = [.,.,1,1,.,.]
C4 = [.,.,-1,-1,.,.]
C5 = [.,.,.,.,1,1]
C6 = [.,.,.,.,-1,-1]

Je dois mettre :

Code:

---

1 2	if (C[0] == C[1] or/and C[2] == C[3] or/and C[4] == C[5] ): instructions

---

Y'a t'il une instruction or/and ou and/or?

Je crois que ce code résume tous les cas.

M.

or/and ? Je pense que c'est simplement un or que tu veux. Le ou logique n'est pas un ou exclusif. En français, "ou" a plutôt le sens d'un ou exclusif, d'où l'utilisation de et/ou dans un texte, mais en logique (et donc dans tous les langages de programmation), le "ou" est vrai même quand les deux alternatives sont vraies.

Si tu n'as jamais vu cela (ce qui m'étonnerait tout de même), renseigne-toi sur la logique booléenne, c'est absolument essentiel en informatique.

Code:

---

1 2	if C[0] == C[1] or C[2] == C[3] or C[4] == C[5]: instructions

---

bonjour,

Code:

---

if (C[0] == C[1] or C[2] == C[3] or C[4] == C[5])

---

par rapport à l'exemple que tu donnes cette condition est satisfaisante.

edit: grilled by dividee

Bonjour,

Je retire mon dernier message :mouarf: Trop de programmation tue la logique ^^ !!

Je viens de m'en rendre compte en pensant à la table logique du OU :)

M.

Code:

---

1 2 3 4 5 6 7 8

compte tenu que je dois prendre en compte 6 combinaisons de combinaisons :   C1 = [1,1,.,.,.,.] C2 = [-1,-1,.,.,.,.] C3 = [.,.,1,1,.,.] C4 = [.,.,-1,-1,.,.] C5 = [.,.,.,.,1,1] C6 = [.,.,.,.,-1,-1]

---

Une solution pourrait être d'utiliser héritage et surcharge.

Principe: vous classez vos listes en fonction de ces critères. la nature d'une opération sera spécifique au type de liste.
Note: vous avez déjà classé vos listes mais vous ne leur avez pas encore associé une 'vrai' class.

Soit C la classe correspondant à vos listes L.
Dessous vous avez C1, C2, C3 qui traduisent :

L[0]==L[1]
L[2]==L[3]
L[4]==L[5]

Puis la déclinaison -1/1
C11 = [1,1,.,.,.,.]
C12 = [-1,-1,.,.,.,.]
C21 = [.,.,1,1,.,.]
C22 = [.,.,-1,-1,.,.]
C31 = [.,.,.,.,1,1]
C32 = [.,.,.,.,-1,-1][/CODE]

C1, C2, C3, C4, C5, C6 sont des sous classes de C fonction de la position/valeur de la paire (1, 1) ou (-1, -1) dans L.
La trame est:

Code:

---

1 2 3 4 5 6 7

class C(object): pass class C1(C): pass class C11(C1): pass class C12(C1): pass class C2(C): pass ...

---

Ensuite vous avez une fonction 'factory' qui vous retourne le Cn correspondant au L:

Code:

---

1 2 3 4

def factory(L): u1, u2, v1, v2, w1, w2 = L if (u1, u2) == (1, 1) : return C11(L) ....

---

On a fait quoi?
Nous avons matérialisé vos classes de listes en 'vraies' class.
C, C1, C11, C12, C2, ... définissent une arborescence dont la racine est C et les feuilles sont C11, C12,...

La factory permet d'associer à tout L une instance c du Cij qui va bien donc
isinstance(c, C), isinstance(c, C1), isinstance(c, C12) vous permettent de savoir ce qu'est c.... C'est proche de ce que vous aviez déjà...

Surcharge:

Citation:

---

Je voudrais émettre des conditions sur ce vecteur, du genre prendre en compte certaines combinaisons pour de futures instructions

---

instruction == methode ou fonction associée à notre c.

Exemple: somme des éléments de L autres que les (1,1) qui nous ont permis de les classer. Appelons la somme
le calcul de la somme varie - est spécialisé - selon que c est C1, C2 ou C3

Code:

---

1 2 3 4 5 6 7 8 9

class C1(C): def somme(self): return sum(self._L[:4]) class C2(C): def somme(self): return sum(self._L[-2:]+self._L[:2]) class C3(C): def somme(self): return sum(self._L[-4:])

---

Cela fait, comment ca va fonctionner:

Code:

---

1 2	c = factory(L) print c.somme()

---

Et voilà...
- W

Très belle solution !

Citation:

---

Envoyé par rambc

Très belle solution !

---

Merci mais Manal est tellement le nez dans ses listes depuis la semaine dernière que je ne suis pas certain qu'il puisse avaler cela.
On verra bien
- W

J'ai un souci avec la solution de wiztricks, qui peut ou non être un problème en fonction de l'interprétation des données.
Un exemple qui illustre ce souci:

Code:

---

C = [1,1,-1,-1,1,1]

---

Cela peut être une instance de C11, de C22 ou de C31. Mais pour bien faire, en toute généralité, cela devrait être une instance des 3. On pourrait le faire en utilisant l'héritage multiple:

Code:

---

1 2	class C112231(C11,C22,C31): pass

---

Mais alors on assiste à une explosion combinatoire du nombre de sous-classes.

Et puis le code est très spécialisé pour les contraintes de bases (L[0] == L[1], etc.) et changer ces contraintes demande de ré-envisager la structure de classes...

J'avoue que je ne suis pas fan de cette solution. On a perdu en agilité pour gagner en structure... Cela se justifierait si ces listes représentent un élément fondamental du domaine d'application, qu'elles sont utilisées un peu partout et que leur maniement est délicat, mais bon... Le mot qui me vient est l'esprit est "overengineering" ;)

Citation:

---

Envoyé par dividee

Cela peut être une instance de C11, de C22 ou de C31. Mais pour bien faire, en toute généralité, cela devrait être une instance des 3. On pourrait le faire en utilisant l'héritage multiple:

---

Pour moi la question étant "associer à une forme (1, 1, *,*,*,*) des fonctions spécifiques" devrait se traiter par foncteur/closure.

J'ai propose une classification hiérarchique en guise d'illustration sur comment se sortir des if ... then ... else... parce que c'est plus lisible.

Il n'y a malheureusement pas grand chose dans les cas d'utilisation pour savoir si l'héritage multiple peut aider à quoi que ce soit d'autre que 'compliquer' un peu/beaucoup.

Je ne comprends pas tes soucis sur l'over-engineering... si les spécifications ne sont pas stables, structures et fonctions devront évoluer.

Classifier permet de réduire le nombre de fonctions et le code en 'structurant': si elle est simple/stable:

• la lisibilité permettra de réduire le temps passé et surtout de se rendre compte assez vite qu'on ne va pas dans la bonne direction,
• la structure permet de tester par petit bout,

Si on ne partitionne pas le domaine avec des 'classifications', ben il va falloir soupouder le code de "if-then-else" si on doit y toucher, difficile de ne rien oublier.... Et ce n'est pas la structure qui va nous sauver.
Donc over-engineering en phase de conception n'est pas toujours un défaut car il force à reformuler et s'assurer qu'on a compris ce qu'on voulait.
- W

Effectivement, on n'en sait pas assez sur le cas d'utilisation et la solution que tu proposes pourrait être judicieuse dans certains cas. Je ne défends certainement pas le fait de saupoudrer le code de if/then/else. Mais ceux-ci pourraient être encapsulés dans une "simple" classe, dans le genre:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

class MonTruc: def __init__(self, a1, a2, b1, b2, c1, c2): self._values = (a1,a2,b1,b2,c1,c2)   def isFoo(self): v = self._values return v[0] == v[1]   def isBar(self): v = self._values return v[2] == v[3]   def mon_operation(self): if self.isFoo() or self.isBar(): # do things else: # do something else

---

Ainsi, par exemple, si la spécification de change le sens de ce que veut dire "être Foo" , il suffit de changer la méthode isFoo.

Mais c'est déjà trop complexe vis-à-vis de la question posé dans ce post, à mon goût.

Je suis d'accord que s'il y a beaucoup de méthodes comme "mon_operation" qui doivent effectuer les mêmes tests, il vaut mieux passer par un héritage et isoler les if/then/else dans une factory. Mais si ça se trouve les tests sont différents à chaque fois.

J'avoue avoir été influencé par les méthodes agiles et en particulier par le principe KISS. En l'absence de plus de détails, je préfère donner la solution la plus simple. Si après on constate que cela pose un problème, de répétition par exemple, on peut toujours refactoriser. En le faisant à posteriori, au moins on aura une vision beaucoup plus claire de la façon de restructurer le code. Et ainsi on reste beaucoup plus ouvert à tout changement de spécifications.

L'over-engineering, je le conçois plutôt dans un projet où l'analyse a été complètement effectuée et est bouclée avant d'aborder la conception du programme, mais j'ai plutôt l'impression que pour ce genre de projet, de toute façon, ce n'est pas Python qu'on utilisera comme langage principal...

La surcharge des méthodes pour effectuer les opérations spécifiques peut se réaliser avec une méthode 'somme' dans les classes ou à la racine voire les deux.

Code:

---

1 2 3 4 5

def mon_operation(self): if isinstance(self, Foo()) or isinstance(self, Bar()): # do things else: # do something else

---

Comment choisir juste entre les 3?
Je privilégie (en autres):

• lisibilité en conception
• nombre cyclomatique et complexité pour la réalisation.

Maintenant d'un point de vue pédagogique, il est peut être judicieux de rester dans le jargon POO standard pour voir ce qui résonne en face: le but est de valider le modèle ou la conception générale.

Mais l'objectif ici est seulement de sensibiliser manaliac sur l'existence de structure de données autres que les listes qui pourraient répondre à certains de ses besoins: hiérarchie de classes, héritage, surcharge, ...

Les bases et très bourrin.
- W
PS : Et nous sommes encore loin d'associer à associer à une forme (1, 1, *,*,*,*) des fonctions spécifiques qui serait sans doute le plus versatile

Je reprend le fil à son début...prop Kango/Dividee
Avez vous entendu parler de 'any' et de 'all'?
if any([c[i]==c[i+1] for i ....]):

bonjour,

oui mais je n'y ai pas pensé :p. je trouve ça bien avec any.

J'y avais pensé mais comme il n'y avait que 3 tests, je me suis dit que ça ne valait pas la peine. En fait je crois que j'ai une répulsion non justifiée quant à l'utilisation conjointe de range et len ;). Ca remonte sans doute à l'époque où je pensais que len était O(n) sur une liste. Et c'est aussi lié au fait que beaucoup de débutants utilisent cela pour itérer sur les indices alors que c'est rarement nécessaire. Cela dit on peut faire sans, mais c'est pas vraiment plus efficace:

Code:

---

any(x == y for x,y in zip(C,C[1:])[::2])

---

Par contre remplacer la list comprehension par une generator expression est avantageux.

Hmmm... perso, je trouve qu'on maque d'information sur la suite... maintenant, ce qui est apparemment demander est une simple identification...

J'aime bien le coup des classes, mais en l'état cela me paraît "rigide", enfin bon, comme cité plus haut par plusieurs : on manque un peu d'information en aval...

voici ce que j'ai fait de mon côté, cela me semble moins... lourd, mais ce n'est qu'un appréciation toute personnelle.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

def isGrp(lst,grp): '''nous dit si le vecteur appartient au groupe grp (0, 1 ou 2)''' grp *= 2 return grp , lst[grp]==lst[grp+1] , isPos(lst,grp)   def isPos(lst,grp): '''nous dit si le groupe est positif''' grp *= 2 return lst[grp]==1   #dictionnaire regroupant les différentes opérations #selon le niveau de simplicité des opérations, on #pourrait facilement faire qqch de plus dynamique... #bref, les clés sont des tuples (groupe, positif) # et les valeur des fonctions, (ici, si les opération # necessitent plusieurs lignes de code, on pourrait # aisément passer par une métaclass... mais bon, ici # c'est le concept d'identifiant qui nous importe ops = { (0,0): lambda lst: "...operation...", (0,1): lambda lst: "...operation...", (1,0): lambda lst: "...operation...", (1,1): lambda lst: "...operation...", (2,0): lambda lst: "...operation...", (2,1): lambda lst: "...operation..." }   class C(object): def __init__(s,vec): s.types = [isGrp(vec,x) for x in range(3)] # si le vecteur peut appartenir à plusieurs groupes, au moins ils sont tous là s.vec = vec   def operations(s): for grp, isgrp, ispos in s.types: if isgrp : yield (grp, ops[(grp,ispos)](s.vec))

---

Salut,

Citation:

---

J'aime bien le coup des classes, mais en l'état cela me paraît "rigide", enfin bon, comme cité plus haut par plusieurs : on manque un peu d'information en aval...

---

Pourquoi en gardes-tu la trace?
En poussant le truc un peu, tu aurais pu écrire cela sans classes du tout
(et c'est la réalisation que je préfère basée sur foncteurs/closures).

Principes / on pourrait optimiser mais laissons paraitre la mécanique.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

def C1_sum(u1, u2): return lambda L, u1=u1, u2=u2: sum(L[-4:]) def C3_sum(v1, v2): return lambda L, v1=v1, v2=v2: sum(L[-2:] + L[:2]) def C5_sum(w1, w2): return lambda L, w1=w1, w2=w2: sum(L[:4]) # ca fait l'équivalent de ton 'dict' dans les 'locals'. # je transporte (u1, u2), (v1, v2), (w1, w2), pour montrer qu'on peut # le faire mais aucun intérêt dans le cas 'sum'   def op_sum(L): # on retrouve la factory qui assigne l'opération en fonction de la forme de L u1, u2, v1, v2, w1, w2 = L if u1 == u2: return C1_sum(u1, u2) elif v1 == v2: return C3_sum(v1, v2) elif w1 == w2: return C5_sum(w1, w2) else: pass   L1 = [1, 1, 3, 4, 5, 6] L2 = [1, 2, 1, 1, 5, 6] L3 = [1, 2, 3, 4, 1, 1]   c1 = op_sum(L1) print c1(L1) print op_sum(L2)(L2) print op_sum(L3)(L3)

---

C'est beaucoup plus court, léger,....

Citation:

---

voici ce que j'ai fait de mon côté, cela me semble moins... lourd, mais ce n'est qu'un appréciation toute personnelle.

---

Dans cette histoire, il y a des tas de nuances entre une solution:
- POO classique basée sur une hiérarchie de classes et l'overloading des méthodes.
- plus 'fonctionnelle' (que permet Python).

L'avantage de la POO classique est d'avoir un héritage "théorie des ensemble", logique classique que nous avons tous plus ou moins acquis.

Nous avons tous dans un coin du cerveau cette mécanique un peu "bourrin" mais prête à l'emploi qui nous permet de faire un va et vient +/- isomorphe entre le besoin et la conception.

Cas pratique: Imaginez que vous deviez écrire un document de conception UML de la chose pour permettre au client de s'assurer que ce que vous allez lui livrer répond à ses attentes.

Du Pythonique fonctionnel en UML, j'ai essayé et j'ai abandonné :cry:
Par contre, si vous voulez modéliser un peu votre conception difficile de se passer d'UML....

Une fois que votre conception "vole", i.e. vous avez pu réaliser un prototype de la chose, vous avez des tests fonctionnels et... la possibilité de remettre pas mal de choses à plat.
Mais vous n'êtes plus dans la qualification/compréhension du besoin mais plutôt dans l'art de programmer en Python.
- W

En utilisant les "fonctions génériques" de peak.rules:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

from peak.rules import when   def op_sum(L): # cas général return sum(L)   @when(op_sum, "L[0] == L[1]") def C1_sum(L): return sum(L[2:])   @when(op_sum, "L[2] == L[3]") def C3_sum(L): return sum(L[:2] + L[:-2])   @when(op_sum, "L[4] == L[5]") def C5_sum(L): return sum(L[:4])

---

Code:

---

1 2	>>> op_sum([-1,-1,1,2,3,4]) 10

---

C'est pas joli ça ? :mrgreen:

:ccool:

Mais tu violes une contrainte fonctionnelle que je me suis efforcé de respecter - mais qu'il n'est peut être pas indispensable de s'embêter à...- :
classes et foncteurs retournent une 'chose' applicable à tous les L d'un même type.

--- Parce que ----

Le truc que je n'intuites pas bien avec les décorateurs, c'est la possibilité de factoriser, i.e l'étape suivante pourrait être d'associer une liste d'opérations
à C1, C2, C3... et on souhaite avoir une construction de la relation "paramétrable"

Plutôt que:

Code:

---

1 2 3 4

c1 = op_somme(L1) print c1(L1) print op_somme(L2)(L2) print op_somme(L3)(L3)

---

Nous pourrions écrire:

Code:

---

1 2 3 4 5

c1 = op(L1) # on descend petit à petit somme = c1('somme') print somme(L1) print op(L2)('somme')(L2) # en un seul coup. print op(L3)('somme')(L3)

---

- W

Je ne vois pas trop l'intérêt de passer le même argument 2 fois. Je comprends que la première fois sert à sélectionner la bonne fonction, et la seconde à l'appliquer, mais quel intérêt ?
Peut-on passer un argument différent la seconde fois ?

Code:

---

op_somme(L1)(L2)

---

Le fait que ça ait un sens où non dépendra de l'interprétation à donner à tout cela, mais rien dans ce qu'on sait du problème ne nous laisse supposer que cela ait un sens. Donc pourquoi introduire une couche de complexité supplémentaire, qui introduit une redondance (on doit passer l'argument 2 fois) et donc une source d'erreur potentielle ?

Bon, là ça devient vraiment tordu mais est-ce que ceci fait ce que tu veux ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

from peak.rules import when   def op(L): pass   @when(op, "L[0] == L[1]") def C1_op(L): u1, u2 = L[:2] def op_dispatch(op): raise TypeError('Unknown Operation')       @when(op_dispatch, "op == 'sum'") def C1_sum(op): return lambda L: sum(L[2:]) + u1 + u2 # juste pour montrer qu'on peut utiliser u1 et u2   return op_dispatch

---

J'oserais jamais mettre ça dans un code réel :langue2:

Code:

---

1 2 3 4 5 6

>>> l1 [-1, -1, 1, 2, 3, 4] >>> l2 [1, 2, 3, 4, 5, 6] >>> op(l1)('sum')(l2) 16 # = 3 + 4 + 5 + 6 + -1 + -1

---

Là on se dit que la curryfication automatique aurait du bon ;)

:ccool:

Tu réponds toi même à la question en illustrant ses limites:

Citation:

---

J'oserais jamais mettre ça dans un code réel

---

Quoi que... les mecs qui codent devraient pouvoir écrire en Perl/Ruby/Lisp les délires qui leur passent par la tête: s'ils livrent une boite noire qui fonctionne? Est ce qu'on ouvre son téléphone portable, sa TV, ... non on s'en sert.

Par contre la démarche de conception doit être beaucoup plus 'white-box' car c'est ce qui va permettre de se rendre compte assez tôt qu'on a oublié ou loupé des trucs... Ce qui redonne une certaine place au 'verbeux'.
-W

Citation:

---

Envoyé par Wiztricks

Pourquoi en gardes-tu la trace?
En poussant le truc un peu, tu aurais pu écrire cela sans classes du tout

---

Très juste, bon, ben pour le fun, j'ai réecris sans classe donc ^^, et en écartant l'identification de la valeur positive ou negative du "groupe", ainsi que la possibilité d'une appartenance à plusieurs "groupes" :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

def vec_operate(vec): for x in range(3)): if vec_isGrp(vec,x): return ops[x](vec_isolate(vec)) raise Exception('No Group identified')   def vec_isGrp(lst,grp): '''nous dit si le vecteur appartient au groupe grp désigné''' grp *= 2 return (lst[grp]==lst[grp+1]) and lst[grp] in (1,-1)   def vec_isolate(lst, grp): grp *= 2 return lst[0:grp]+lst[grp+2:]   vec_ops = ( lambda lst: sum(lst), lambda lst: sum(lst)+5, lambda lst: sum(lst)/3 )   #=====================================   def main(): vecs = ( [1,1,42,94,67,20], [-1,-1,58,24,1,1] ) for v in vecs: print vec_operate(v)

---

En ce qui concerne l'utilisation de when de peak.rules, je la comprend, mais ne vois pas le besoin de son utilisation dans ce cas... Peut-être ais-je mal compris, c'est fort probable, mais en quoi est-ce plus court/clair que de simples conditions ?:koi:

Salut,

Citation:

---

Envoyé par N.tox

Très juste, bon, ben pour le fun, j'ai réecris sans classe donc ^^, et en écartant l'identification de la valeur positive ou negative du "groupe", ainsi que la possibilité d'une appartenance à plusieurs "groupes" :

---

:ccool: Très joli

mais je ne pense pas que cela respecte:
r = op(type(L))(op_name)(L)

Citation:

---

En ce qui concerne l'utilisation de when de peak.rules, je la comprend, mais ne vois pas le besoin de son utilisation dans ce cas... Peut-être ais-je mal compris, c'est fort probable, mais en quoi est-ce plus court/clair que de simples conditions ?:koi:

---

J'aime bien la solution "peak.rules" parce que la spécialisation est calculée au fur et à mesure qu'on descend dans la précision. Votre solution fait la même chose d'ailleurs.

Pourquoi la forme:
r = op(type(L))(op_name)(L)
a de l'importance (à mes yeux)?

Parce que:
1. elle synthétise le problème à résoudre: appliquer une opération op_name dépendant du type de Liste sur les valeurs de la Liste.
2. le triplet (type, op_name, valeurs) "ramasse" bien les différentes "variables" sur lesquelles appliquer "op"

Oui et alors? Elle donne un indicateur de complexité.
Avec 3 types et 1 opération par type (sum), bof... 3 haricots qui se courent après bof... même pas peur...

Avec 10 types et 10 opérations par type çà grimpe à 100...
Ouch!!! La question qui se pose alors est "quelle design va permettra de réaliser (coder, tester, maintenir) tout çà sans rien oublier et en écrivant le moins de lignes... "classes"? "foncteurs"? "décorateurs"?
- W

Citation:

---

Envoyé par wiztricks

Avec 10 types et 10 opérations par type çà grimpe à 100...
Ouch!!! La question qui se pose alors est "quelle design va permettra de réaliser (coder, tester, maintenir) tout çà sans rien oublier et en écrivant le moins de lignes... "classes"? "foncteurs"? "décorateurs"?
- W

---

Cela va dépendre aussi de la possibilité de "factoriser" les opérations, je suppose. En général, si on a 10 types avec 10 opérations, il est probable qu'une partie au moins des opérations soit commune à plusieurs types. Ou que certaines opérations soient décomposables en une partie commune à plusieurs types (voir tous) et une partie spécialisée.

Si la façon de réaliser l'opération ne dépend que du type d'un seul argument, l'approche orientée object (single-dispatch) est sans doute la plus directe. On a un peu de souplesse du fait qu'on peut créer des types pour les besoins de la conception. Par exemple, même si conceptuellement on n'a qu'un seul type (qui correspond par exemple à la liste des 6 entiers), on peut créer des sous-types en fonction des valeurs qui sont dans la liste, comme le proposait wiztricks dans sa première réponse (il se peut bien sûr que ces types aient droit de séjour au niveau conceptuel aussi...).

Si maintenant la façon de réaliser l'opération dépend du type de plusieurs arguments, il existe des design patterns pour gérer cela dans le cadre de l'orienté object single-dispatch, mais dans ce cas le multiple-dispatch, comme les "multimethods" de Common Lisp par exemple, semble plus adapté. peak.rules permet d'implémenter cela en Python, mais il y a d'autres solutions également.

peak.rules permet d'aller encore plus loin, ce qu'ils appellent des "fonctions génériques", où la fonction a exécuter peut dépendre non seulement du types de arguments, mais de leur valeur (comme l'illustre mes deux bouts de code).

Je me demande dans quelle mesure le fait que ces techniques ne soient pas "mainstream" ne vient pas d'un manque de support méthodologique...

Hmmm... après plusieurs relectures en gardant en tête le "10 types avec 10 fun c pour chaque"

Je comprend largement mieux ton (votre ? Tutoyons-nous, please ^^) choix des classes avec toutes les mécaniques d'héritage et de surcharge... et finalement, de mon point de vue de débutant (3 ans amateur, c'est encore débutant :mouarf:), cela m'apparait comme la solution la plus facilement maintenable... oui, les décorateur me demande une gymnastique mentale plus grande que les classes :?...

Ce qui me chagrine avec ta formule
r = op(type(L))(op_name)(L)
c'est que "op(type(L))" retourne une fonction que l'on appelle via "(op_name)" qui retourne elle-même une fonction que l'on appelle via "(L)" pour enfin obtenir le résultat voulu... j'ai bien compris ?
Si c'est bien ça, cela me parait bien complexe pour une problématique de simple identification... peut-être cette impression évoluera-t-elle avec l'expérience...

Enfin je dis ça mais cela ne m'a pas empêcher de produire un autre code basé sur une classe (avant la relecture), où le "type" du vecteur est en fait un entier (où binairement le dernier bit est un positive flag, et le nombre sans le dernier bit, le "groupe") :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

class metatuple(type): '''metaclass permettant d'utiliser la clarté et la propreté syntaxique d'une classe     pour obtenir un tuple constitué de fonctions complexes (multi-lignes), ordonnées''' def __new__(cls,nm,bs,at): return tuple( (v for n,v in sorted(at.items()) if n[0]=='f' ]) )   class Vec(object): def __init__(s,v): s.val = v s.type = s.id(v)   def id(s,v,totalGroups=3): '''doit nous retourner un nombre nous renseignant a la fois sur le groupe du vecteur, ainsi que sur sa "polarite", lecture binaire''' for x in range(totalGroups): x,g = x*2,x if (v[x]==v[x+1]) and (v[x] in (1,-1)): return ( g << 1 ) + ( v[x]==1 ) raise Exception('Vector not identified')   def op(s,*args): return s.ops[s.type](*args)   class ops(object): __metaclass__=metatuple def f0(): print 'group:0 neg' def f1(): print 'group:0 pos' def f2(): print 'group:1 neg' def f3(): print 'group:1 pos' def f4(): print 'group:2 neg' def f5(): print 'group:2 pos'   #======================================   def main(): Vec([1,1,42,94,67,20]).op() Vec([-1,-1,58,24,1,1]).op()   main()

---

De vos points de vue, est-ce se compliquer la vie ? est-ce lisible ?
Et quelle sont vos suggestions/critiques/remarques ?

Salut

Bah lisible... Z'ont qu'à apprendre.
J'ai passé un peu de temps à jouer avec.
Et je l'ai substantiellement modifié...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

def get_id(v,totalGroups=3): '''doit nous retourner un nombre nous renseignant a la fois sur le groupe du vecteur, ainsi que sur sa "polarite", lecture binaire''' for x in range(totalGroups): x*=2 if (v[x]==v[x+1]) and (v[x] in (1,-1)): return ((x/2)<<1)+int(v[x]==1) raise Exception('Vector not identified')   def s1(self, L): return sum(L[-4:]) def s3(self, L): return sum(L[-2:] + L[:2]) def s5(self, L): return sum(L[:4])   class Somme(object):   f0 = s1 f1 = s1 f2 = s3 f3 = s3 f4 = s5 f5 = s5   class Vec(object): _instances = {} _operations = dict( somme = Somme(), )   def __new__(cls, L): type_ = get_id(L) if type_ not in cls._instances: instance = object.__new__(cls) setattr(instance, 'type', type_) cls._instances[type_] = instance return cls._instances[type_]     def __call__(self, opname): return getattr(self._operations[opname], 'f%d' % self.type)     #======================================   def main(): L = [1,1,42,94,67,20] print Vec(L)('somme')(L) L = [-1,-1,58,24,1,1] print Vec(L)('somme')(L)   main()

---

Les grosses différences sont que je ne crée qu'un Vec par type et que pour avoir f(L)(opname)(L), je suis passé par __call__
Mais ca revient au même: classifier/dispatcher/pythoniser
- W

:lefou:
Ouiiiiii... le couillon ! Je comprend mieux ta formule... j'étais arrivé dans mon dernier code à la même chose... sauf que l'appel du "type" d'operation via une chaine en tant que paramètre, permet une meilleure dynamisation éventuelle, donc souplesse et évolution...

J'adore cette structure :) (est-elle la "meilleure" ?... je me poserais la question plus tard, pour l'heure, je dois partir)