Numpy or not Numpy

Version imprimable

Numpy or not Numpy

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:

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

23/08/2020, 22h30
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

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:

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:

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

24/08/2020, 09h23
wiztricks

Salut,

Citation:

Envoyé par Aelurus_

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
24/08/2020, 09h24
BufferBob
salut,

Citation:

Envoyé par Aelurus_

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

comme ça par exemple :
Code:

1 2 def gen_nom_paliers(n): return list(range(n)) + [n] + list(range(n-1, -1, -1))
24/08/2020, 11h13
Aelurus_

Bonjour,

J'essaye d'avoir cette démarche.

Citation:

Envoyé par wiztricks

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:

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:

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
24/08/2020, 15h51
Sve@r
Bonjour

Citation:

Envoyé par Aelurus_

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:

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.

Citation:

Envoyé par Aelurus_

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

Ben voilà !!!

Citation:

Envoyé par Aelurus_

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,].
24/08/2020, 18h09
Aelurus_

Salut Sve@r,

Que de précisions très instructives.

Citation:

Envoyé par Sve@r

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.

Citation:

Envoyé par Sve@r

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 ^^.
24/08/2020, 20h43
Sve@r

Citation:

Envoyé par Aelurus_

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.

Citation:

Envoyé par Aelurus_

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.