Discussion :

[manaliac]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if valeur == [1,1,.,.,.,.]
  instructions
else
    continue

Merci !

M.

[xavier-Pierre]

quelque chose du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[manaliac]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[dividee]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[kango]

bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[manaliac]

Bonjour,

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

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

M.

[wiztricks]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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:

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Et voilà...
- W

[rambc]

Très belle solution !

[wiztricks]

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

[dividee]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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"

[wiztricks]

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

[dividee]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[wiztricks]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Zavonen]

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 ....]):

[kango]

bonjour,

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

[dividee]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[N.tox]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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))

[wiztricks]

Salut,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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,....

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é
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

[dividee]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

C'est pas joli ça ?

[wiztricks]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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