/* Topic des codeurs couche-tard [1] */

Compteur du TdCCT · Le 24/06/2010, à 09:42

Scores de la période en cours :

1) 230    Pylade
2) 196    samuncle
3) 195    grim7reaper
4) 193    nesthib
5) 167    mathieuI
6) 98    helly
7) 88    cm-t
8) 70    gnuuat
9) 37    tshirtman
10) 34    \\Ouranos//
11) 25    Lagierl
12) 23    petifrancais
13) 20    keny
14) 17    pierguiard
15) 15    ǤƦƯƝƬ
16) 11    edge_one
17) 10    NutMotion
18) 9    Kanor
19) 7    Vista
20) 5    sailing
20) 5    timsy
22) 4    Toineo
22) 4    xapantu
24) 3    gulp
24) 3    Р'tite G☢gole :mad:
26) 2    kouskous
26) 2    Mornagest

\\Ouranos// · Le 24/06/2010, à 09:48

Derrière le compteur !

Pylades · Le 24/06/2010, à 11:40

@tshirtman : pour ma fonction « bet », c’est pire que pas probable que quelqu’un l’aime, puisqu’elle n’a de raison d’être que dans le cadre de ce bidule.

Mais sinon, quand je ferai des trucs utiles, ouais, j’y penserai.

Pylades · Le 24/06/2010, à 13:04

Hey !
Je me pose une question.
J’ai deux manière de faire un truc :

1.

a == 'y' or a == 'Y'

2.

a.lower() == 'y'

Certes la deuxième est plus courte et fait plus python. Mais côté perfs, ce n’est clairement pas la meilleure. Donc au final, pour de vrai vous me conseilleriez de mettre quoi ?

\\Ouranos// · Le 24/06/2010, à 13:11

Pylade a écrit :

Hey !
Je me pose une question.
J’ai deux manière de faire un truc :
1.
a == 'y' or a == 'Y'
2.
a.lower() == 'y'
Certes la deuxième est plus courte et fait plus python. Mais côté perfs, ce n’est clairement pas la meilleure. Donc au final, pour de vrai vous me conseilleriez de mettre quoi ?

Pourquoi plus Python ? Je fais ça en ruby, et avant ton message, je savais même pas que c'était possible en python. Utilise la deuxième. Tu gâches déjà des perfs en utilisant de l'interprété

tshirtman · Le 24/06/2010, à 13:22

y'a

a in ('y','Y')

aussi…

il faut tenir compte de tous les cas quand tu bench

gaby@dormouse [~/usf]python -m timeit -c "a='y'; a in ('y','Y')"
1000000 loops, best of 3: 0.34 usec per loop
gaby@dormouse [~/usf]python -m timeit -c "a='Y'; a in ('y','Y')"
1000000 loops, best of 3: 0.46 usec per loop
gaby@dormouse [~/usf]
gaby@dormouse [~/usf]python -m timeit -c "a=' '; a in ('y','Y')"
1000000 loops, best of 3: 0.55 usec per loop

gaby@dormouse [~/usf]python -m timeit -c "a=' '; a.lower() == 'y'"
1000000 loops, best of 3: 1 usec per loop
gaby@dormouse [~/usf]python -m timeit -c "a='y'; a.lower() == 'y'"
1000000 loops, best of 3: 1.03 usec per loop
gaby@dormouse [~/usf]python -m timeit -c "a='Y'; a.lower() == 'y'"
1000000 loops, best of 3: 1.04 usec per loop

gaby@dormouse [~/usf]python -m timeit -c "a='Y'; a == 'y' or a == 'Y'"
1000000 loops, best of 3: 0.54 usec per loop
gaby@dormouse [~/usf]python -m timeit -c "a='y'; a == 'y' or a == 'Y'"
1000000 loops, best of 3: 0.33 usec per loop
gaby@dormouse [~/usf]python -m timeit -c "a=' '; a == 'y' or a == 'Y'"
1000000 loops, best of 3: 0.55 usec per loop

Dernière modification par tshirtman (Le 24/06/2010, à 13:27)

Pylades · Le 24/06/2010, à 13:23

\\Ouranos// a écrit :

Pourquoi plus Python ?

Parce que j’apprends le python.

\\Ouranos// a écrit :

Utilise la deuxième. Tu gâches déjà des perfs en utilisant de l'interprété

Ouais, je sais, mais spa une raison…

tshirtman a écrit :

y'a
a in ('y','Y')
aussi…

Merci !
En effet, c’est assez séduisant (en plus je peux balancer mon '' en même temps). Je crois que je vais opter pour ça.

Dernière modification par Pylade (Le 24/06/2010, à 13:28)

Pylades · Le 24/06/2010, à 21:37

@tshirtman : j’ai fait un bench, moyenne de plusieurs essais. « t » représente n’importe quoi (et ça ne change pas quelle que soit la longueur de la chaîne.
Voici les résultats (pour Python 2.6, Python 3.0 est un peu plus lent) :

On peut donc en conclure qu’effectivement l’usage de lower plombe les perfs, mais aussi que la multiplication des or est aussi peu appréciable. Finalement, c’est bien in qui remporte la compétition haut la main, tant sur le plan de la clarté que des perfs.
J’ai bien fait de le choisir.

Sinon :

>>> len('é')
1

Ça prend en compte l’encodage ! Hé, mais c’est civilisé comme langage.
Je commence à apprécier le très haut niveau, tiens…

Par ailleurs

>>> ''.__sizeof__()
58
>>> 't'.__sizeof__()
60
>>> 'te'.__sizeof__()
62
>>> 'tes'.__sizeof__()
64
>>> 'test'.__sizeof__()
66

Jusque là, tout va bien, on utilise bien deux bytes de plus à chaque caractère ajouté, mais tout va bien…

Mais là, c’est le drame :

>>> 'test…'.__sizeof__()
68

Comment peut-il n’utiliser que deux bytes supplémentaires pour un caractère codé sur trois bytes ?
Y a-t-il un mécanisme un peu complexe derrière, similaire à la « palette de couleurs » utilisée pour l’encodage d’images en 256 couleurs ?

cm-t · Le 24/06/2010, à 23:36

'Nuit;

Dernière modification par cm-t (Le 25/06/2010, à 00:00)

gnuuat · Le 24/06/2010, à 23:43

liste = ['P', 'L', 'O', 'P']
print [elem.lower() for elem in liste]

edit :

from string import lower

liste = ['P', 'L', 'O', 'P']
print map(lower, liste)

Dernière modification par gnuuat (Le 24/06/2010, à 23:49)

helly · Le 25/06/2010, à 00:05

plopapoints

tshirtman · Le 25/06/2010, à 00:07

Pylade a écrit :

Voici les résultats (pour Python 2.6, Python 3.0 est un peu plus lent) :
http://pix.toile-libre.org/upload/thumb/1277406915.jpg

On peut donc en conclure qu’effectivement l’usage de lower plombe les perfs, mais aussi que la multiplication des or est aussi peu appréciable. Finalement, c’est bien in qui remporte la compétition haut la main, tant sur le plan de la clarté que des perfs.
J’ai bien fait de le choisir.

et il est plus court que les "or" et plus souple que le lower , mais c'est bien sur la meilleure solution vu que c'est celle que j'utilise

Sinon :
>>> len('é')
1
Ça prend en compte l’encodage ! Hé, mais c’est civilisé comme langage.
Je commence à apprécier le très haut niveau, tiens…

ouais, y'a eu un gros boulot en python3 la dessus, y'avait des soucis en 2.x

[…]
Mais là, c’est le drame :
>>> 'test…'.__sizeof__()
68
Comment peut-il n’utiliser que deux bytes supplémentaires pour un caractère codé sur trois bytes ?
Y a-t-il un mécanisme un peu complexe derrière, similaire à la « palette de couleurs » utilisée pour l’encodage d’images en 256 couleurs ?

je ne suis pas sur de comprendre, tout prends max 2 bytes en utf-8 non?

\\Ouranos// · Le 25/06/2010, à 00:15

tshirtman a écrit :

Pylade a écrit :
Voici les résultats (pour Python 2.6, Python 3.0 est un peu plus lent) :
http://pix.toile-libre.org/upload/thumb/1277406915.jpg
On peut donc en conclure qu’effectivement l’usage de lower plombe les perfs, mais aussi que la multiplication des or est aussi peu appréciable. Finalement, c’est bien in qui remporte la compétition haut la main, tant sur le plan de la clarté que des perfs.
J’ai bien fait de le choisir.
et il est plus court que les "or" et plus souple que le lower , mais c'est bien sur la meilleure solution vu que c'est celle que j'utilise

Кຼزດ · Le 25/06/2010, à 00:56

plop

\\Ouranos// · Le 25/06/2010, à 01:05

Je proteste.

grim7reaper · Le 25/06/2010, à 01:07

BN World !

samυncle · Le 25/06/2010, à 01:35

bonne nuit

Pylades · Le 25/06/2010, à 01:52

tshirtman a écrit :

Pylade a écrit :
Voici les résultats (pour Python 2.6, Python 3.0 est un peu plus lent) :
http://pix.toile-libre.org/?img=1277406915.jpg

Bah quoi ?
/me avait la flemme de recopier ce qu’il a gribouillé.

tshirtman a écrit :

Pylade a écrit :
[…]
Mais là, c’est le drame :
>>> 'test…'.__sizeof__()
68
Comment peut-il n’utiliser que deux bytes supplémentaires pour un caractère codé sur trois bytes ?
Y a-t-il un mécanisme un peu complexe derrière, similaire à la « palette de couleurs » utilisée pour l’encodage d’images en 256 couleurs ?
je ne suis pas sur de comprendre, tout prends max 2 bytes en utf-8 non?

Nan, en UTF-8 le codage va de un à quatre octets. Et ce caractère est codé sur trois octets.

nesthib · Le 25/06/2010, à 02:02

plop de 2h

(et effectivement … est codé sur 3 octets : e280a6)

\\Ouranos// · Le 25/06/2010, à 02:17

Déjà deux heures.

samυncle · Le 25/06/2010, à 02:30

.

samυncle · Le 25/06/2010, à 03:03

.

Pylades · Le 25/06/2010, à 03:05

Pas foutu grand-chose, aujourd’hui…

Bonne nuit à tous.

nesthib · Le 25/06/2010, à 03:19

tshirtman · Le 25/06/2010, à 07:53

@pylade: alors un truc qui m'étonnerait pas trop trop… ce serait que les chaines en python soient des chaines de pointeurs et non de caractères… chaque pointeur serait alors un pointeur vers l'instance unique du caractère en mémoire… (ça marche comme ça pour pas mal de choses).

Dernière modification par tshirtman (Le 25/06/2010, à 08:00)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#451 Le 24/06/2010, à 09:42

Re : /* Topic des codeurs couche-tard [1] */

#452 Le 24/06/2010, à 09:48

Re : /* Topic des codeurs couche-tard [1] */

#453 Le 24/06/2010, à 11:40

Re : /* Topic des codeurs couche-tard [1] */

#454 Le 24/06/2010, à 13:04

Re : /* Topic des codeurs couche-tard [1] */

#455 Le 24/06/2010, à 13:11

Re : /* Topic des codeurs couche-tard [1] */

#456 Le 24/06/2010, à 13:22

Re : /* Topic des codeurs couche-tard [1] */

#457 Le 24/06/2010, à 13:23

Re : /* Topic des codeurs couche-tard [1] */

#458 Le 24/06/2010, à 21:37

Re : /* Topic des codeurs couche-tard [1] */

#459 Le 24/06/2010, à 23:36

Re : /* Topic des codeurs couche-tard [1] */

#460 Le 24/06/2010, à 23:43

Re : /* Topic des codeurs couche-tard [1] */

#461 Le 25/06/2010, à 00:05

Re : /* Topic des codeurs couche-tard [1] */

#462 Le 25/06/2010, à 00:07

Re : /* Topic des codeurs couche-tard [1] */

#463 Le 25/06/2010, à 00:15

Re : /* Topic des codeurs couche-tard [1] */

#464 Le 25/06/2010, à 00:56

Re : /* Topic des codeurs couche-tard [1] */

#465 Le 25/06/2010, à 01:05

Re : /* Topic des codeurs couche-tard [1] */

#466 Le 25/06/2010, à 01:07

Re : /* Topic des codeurs couche-tard [1] */

#467 Le 25/06/2010, à 01:35

Re : /* Topic des codeurs couche-tard [1] */

#468 Le 25/06/2010, à 01:52

Re : /* Topic des codeurs couche-tard [1] */

#469 Le 25/06/2010, à 02:02

Re : /* Topic des codeurs couche-tard [1] */

#470 Le 25/06/2010, à 02:17

Re : /* Topic des codeurs couche-tard [1] */

#471 Le 25/06/2010, à 02:30

Re : /* Topic des codeurs couche-tard [1] */

#472 Le 25/06/2010, à 03:03

Re : /* Topic des codeurs couche-tard [1] */

#473 Le 25/06/2010, à 03:05

Re : /* Topic des codeurs couche-tard [1] */

#474 Le 25/06/2010, à 03:19

Re : /* Topic des codeurs couche-tard [1] */

#475 Le 25/06/2010, à 07:53

Re : /* Topic des codeurs couche-tard [1] */

Pied de page des forums