Discussion :

[Aelurus_]

Bonjour à tous,
j'essaye de réécrire une fonction ou je construis une liste numpy en me demandant si numpy est vraiment utile, j'en arrive à cela :

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
 
from doctest import testmod
import numpy as np
def gen_num_paliers(n):
    """
    retourne une liste incrémentée ascendant et descendant axée sur le
    milleu du nombe passé en argument
    >>> print (gen_num_paliers(9))
    [0 1 2 3 4 3 2 1 0]
    """
    #coeff = np.zeros((n), dtype=int)
    """for i in range(int(n/2)+1):
        coeff[i]=i
        coeff[n-(i+1)]=i"""        
    #coeff = [i for i in range(int(n/2)+1)]
    #tentative de passage sans numpy
    coeff = [i for i in range(int(n/2)+1)]
    coeff = coeff + sorted(coeff[:int(n/2)],reverse=True)
    return coeff

Hormis ma différence de sortie avec les virgules, qui ne devrait pas causer d'erreur dans la suite, je voudrais savoir si ma démarche est bien judicieuse ou y a t'il une autre piste que je pourrais creuser.

Merci

[wiztricks]

Salut,

Que votre fonction retourne un tableau numpy ou une simple liste sera déterminé par ce que vous ferez de ce retour. Et si pour l'instant rien ne vous incite à choisir l'un plutôt que l'autre, choisissez ce qui vous permettra d'avancer le plus facilement (au moins dans un premier temps).

- W

[Aelurus_]

Merci Witricks,

J'utilise les valeurs de la liste uniquement pour un affichage, et après vérification je peux utiliser l'une ou l'autre syntaxe sans différence de sortie.

J'essaye de m'inspirer de la syntaxe que vous m'avez donnée pour écrire une fonction de manière plus concise dans un autre post, pour reprendre les bouts de code qui s'y prête et de les commenter plus proprement avec doctest.

Je constate que j'importe numpy uniquement pour générer une liste d'une dizaine d'entrées Je me suis dit que ce n'était pas très judicieux, je passe aussi de 5 à 3 lignes. Comme mon script est fonctionnel, dans un but d'apprentissage j'essaye de remettre un peu d'ordre et de bonne pratique.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
def gen_nom_paliers(n):
    """
    retourne une liste incrémentée ascendant et descendant axée sur le
    milleu du nombe passé en argument
    >>> print (gen_num_paliers(9))
    [0, 1, 2, 3, 4, 3, 2, 1, 0]
    """
    coeff = [i for i in range(int(n/2)+1)]
    coeff = coeff + sorted(coeff[:int(n/2)],reverse=True)
    return coeff

Je me demande si je ne pourrais pas écrire cette fonction plus simplement, car même si

Code :

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

coeff = coeff + sorted(coeff[:int(n/2)],reverse=True)

est fonctionnel, je ne suis pas convaincu. cela à au moins l'avantage de m'avoir permis d'utiliser la fonction sorted().

[wiztricks]

Salut,

je ne suis pas convaincu. cela à au moins l'avantage de m'avoir permis d'utiliser la fonction sorted().

Vous débutez: l'important est dans ce que vous apprenez en fabriquant du code qui fonctionne.
Posez vous des questions: pourquoi utiliser "sorted" alors que la liste est déjà triée? la parcourir "à l'envers" suffit. Et çà n'a rien à voir avec des lignes de code...

- W

[BufferBob]

salut,

Je me demande si je ne pourrais pas écrire cette fonction plus simplement

comme ça par exemple :

Code :

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

1
2
def gen_nom_paliers(n):
   return list(range(n)) + [n] + list(range(n-1, -1, -1))

[Aelurus_]

Bonjour,

J'essaye d'avoir cette démarche.

Salut,



Vous débutez: l'important est dans ce que vous apprenez en fabriquant du code qui fonctionne.
Posez vous des questions: pourquoi utiliser "sorted" alors que la liste est déjà triée? la parcourir "à l'envers" suffit. Et çà n'a rien à voir avec des lignes de code...

- W

Si j'utilise sorted c'est que je n'ai pas vu comment construire ma liste autrement, je sais que la moitié de ma liste pivote sur son milieu. Je génère donc la première moitié et comme il y a symétrie sur le pivot, j'inverse la liste lui retranche son pivot et l'additionne à la liste non inversée. Au début je remplissais les extrémités en convergeant vers le pivot ^^. Donc sorted() me permet d'inverser la liste.

Je n'avais effectivement pas pensé à lire la liste à l'envers ^^.

Code :

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

coeff = coeff + coeff[int(n/2)-1::-1]

Merci pour l'idée.

BufferBob,
ba oui c'est top aussi, pourquoi est ce que je fais une boucle plustot que d'utiliser range() ^^,

Code :

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

return list(range(int(n/2+1))) + [n] + list(range(int(n/2-1), -1, -1))

Merci aussi pour le +[n], il faut bien entendu additionner une liste à une liste et non faire +n . J'avais fais l'erreur sans la comprendre.


Merci tout les deux

[Sve@r]

Bonjour

coeff = [i for i in range(int(n/2)+1)]

Les listes en intension c'est bien. Mais si on peut s'en passer, c'est encore mieux => coeff = range(int(n/2)+1). Et si (au pire) avoir un objet "range" ne convient pas, reste toujours le cast => coeff = tuple(range(int(n/2)+1)) (et tu remarqueras que je me cantonnes toujours au minimum utile => pas besoin de liste quand un tuple suffit).
La fonction de BufferBob devient donc

Code python :

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

1
2
def gen_nom_paliers(n):
   return tuple(range(n)) + (n,) + tuple(range(n-1, -1, -1))

Et si l'appelant veut une liste, il fait lui-même le cast.

ba oui c'est top aussi, pourquoi est ce que je fais une boucle plustot que d'utiliser range()

Ben voilà !!!

J'avais fais l'erreur sans la comprendre.

Et le message que t'as eu en retour ne t'y a pas aidé ? Toutefois (là encore), petite astuce: list() + [truc] fonctionne car [truc] entre crochets est traduit par une liste. Mais pour les tuples, tuple() + (truc) ne fonctionne pas car (truc) entre parenthèses n'est pas un tuple. Ce ne sont pas les parenthèses qui font le tuple mais la virgule. Les parenthèses aident quand on veut spécifier les bornes dans le cas de tuples en plusieurs dimensions et sont donc parfois tellement nécessaire qu'on prend l'habitude de les mettre tout le temps mais il reste qu'elles ne font pas le tuple. La bonne formulation devient donc tuple() + truc, avec une virgule, et donc pour plus de lisibilité j'écrirai tuple() + (truc,) (comme dans ma version de la fonction de BufferBob).
De là, par symétrie, j'ai pris l'habitude de toujours mettre une virgule aussi pour les listes à un élément => list() + [truc,].

[Aelurus_]

Salut Sve@r,

Que de précisions très instructives.

Bonjour

Les listes en intention c'est bien. Mais si on peut s'en passer, c'est encore mieux

Quand tu dit cela puis je le résumer par un tuple est plus économe en ressource qu'une liste ?

Et effectivement mon besoin est un objet itérable contenant cette incrémentation. Donc un tuple fait très bien le taff, surtout que l'objet ne bouge pas de sa création à la fin de l'exécution.

Bonjour

Et le message que t'as eu en retour ne t'y a pas aidé ?

Comment te dire, je crois que je m'attendais tellement à faire une boulette que je n'ai pas été surpris et n'ai pas cherché à la comprendre....

Vos retour sont un régal, merci ^^, alors petit np.array ou est tu ^^, viens la que je te tuplelise ^^.

[Sve@r]

Quand tu dit cela puis je le résumer par un tuple est plus économe en ressource qu'une liste ?

Je l'ai pas dit dans ce sens. Je voulais dire qu'écrire coeff=[i for i in range(...)] peut s'écrire plus directement et plus simplement coeff=list(range(...)). La liste en intension ne se justifie que s'il y a travail sur les éléments pendant leur récupération (ex coeff=[i**3 for i in range(...)] pour créer une liste contenant les éléments mis au cube) ou filtre des éléments récupérés (ex coeff=[i for i in range(...) if i%2 == 0] pour ne filtrer que les pairs).

Mais sinon oui, une liste étant un objet plus complexe qu'un tuple (on peut l'agrandir, insérer des trucs, supprimer des trucs tandis qu'un tuple est immuable donc ne contient pas toutes ces possibilités), je suis persuadé qu'un tuple est moins gourmand qu'une liste et donc je privilégie le tuple chaque fois que je le peux => coeff=tuple(range(...)).
Et ça reste compatible avec les listes en intension => truc=[i**3 for i in iterable if i%2 == 0] peut aussi s'écrire truc=tuple(i**3 for i in iterable if i%2 == 0). Et (toujours dans un souci de symétrie), si l'appel à "tuple()" est obligatoire pour créer un tuple, alors bien qu'il ne soit pas obligatoire pour les listes (les crochets suffisent) je préfère rester explicite dans tous les cas => truc=list(i**3 for i in iterable if i%2 == 0) pour créer une liste.

alors petit np.array ou est tu ^^, viens la que je te tuplelise ^^.

Ben... vu ton besoin (et pour répondre à ta toute première question), je ne pense pas que numpy se justifie. Toujours aller au plus simple. D'autant plus que rien n'interdit un appelant éventuel de transformer s'il en a envie le retour de ta fonction en np.array.

Donc pour résumer, tu as besoin d'avoir une suite d'éléments, tu réfléchis d'abord à savoir si cette suite devra évoluer ou pas ce qui t'oriente vers la liste ou le tuple. De là, tu peux utiliser le cast list(...) ou tuple(...) pour créer ta suite. Et ce que tu mets entre les parenthèses, c'est soit le créateur initial (range si ce sont des nombres rangés, ou autre), soit une expression dite "en intension" si les éléments doivent être manipulés avant d'être récupérés.