Reprise du message précédent :

 
J'ai besoin d'une contraction des mots "apple" et "retard".

 
C'est pas bien de fantasmer sur les possibilités de la DCRI au prisme de diverses séries américaines de merde
 

est-ce que l'ensemble est plus petit et plus léger qu'un laptop ?

le nom officiel est appletard

pas forcement mais les polices sont bien plus fines, un ecran de macbook air c'est perpetuellement flou, ca brule les yeux

Non, mais il a une résolution de dingue!

Sous eclipse, comment voir les jars chargés et leur chemin ?

plugin registry

nraynaud porn

c'est machin Blanchard ?

CMAX superior \o/
WHAT WHAT
Grand CMAX MITIJOR \o_

Not across the Road
Along the river \o/

 
et de l'application que je debug ?  

Nan mais tu penses sincèrement et sérieusement qu'à un mois des élections, ils n'ont utilisé que les moyens légaux qu'ils annoncent avant de procéder à son interpellation à son domicile ? Genre pour le vol de scooter du fils sarkozy, on fait des recherches ADN et tout, mais dans ce cas-ci, on a juste interrogé 2 ou 3 fadettes, et fait le tour des revendeurs Yamaha de Toulouse...

Bon, sinon, Python c'est bien, mais y a des fois, ça fait quand même penser un peu à du php.

>>> a,b
(0.02448948650187263, 0.02448948650187218)
 
>>> a==b, str(a)==str(b)
(False, True)
 
>>> str((a,b))
'(0.02448948650187263, 0.02448948650187218)'
 
>>> str(a),str(b)
('0.0244894865019', '0.0244894865019') #enkuler
 
>>> str((b,a))==str((a,b))
False

ergo: (str(a)==str(b) ) != ( str((a,b))==str((b,a)) )

ça a toujours été gratuit
 
http://progit.org/book/fr/

 
Vu les largesses légales octroyées par les différents dispositifs anti-terroristes, je doute qu'il y ait eu besoin de moyens illégaux pour trouver des informations sur le mec, mais ça n'est pas le sujet.
R3g disait en substance : "il était surveillé ? Bah ils l'ont drôlement bien surveillé le mec puisqu'il a dézingué 7 personnes". Mon propos, c'est que la surveillance a ses limites

Old news are not exciting: tuple.__str__ (comme la quasi totalité des __str__ des collections built-in, list et dict font pareil) utilise probablement repr() (pour garder un maximum d'information, vu que c'est la différence contractuelle entre __repr__ et __str__).

Avec des flottants, __str__ a une précision largement inférieure à __repr__ (comme tu as pu le noter), donc tu peux avoir des faux positif si tu compares des flottants sur leur __str__

D'un autre côté j'vois pas le rapport avec PHP, c'est un peu n'importe-quoi ce que tu fais là.

Je suis plus cynique. Ca se trouve, ils savaient déjà qui c'était, mais n'avaient pas les preuves légales pour être sûr que ça passe (ou alors ils ne veulent pas qu'on sache pour leur satellites espions à orbite basse qui peuvent suivre un piéton à la trace même par temps nuageux et même en intérieur), donc ils l'ont laissé abattre une fois de plus, froidement. Ils lui ont même refait le plein dans le scooter pendant la nuit avant le drame, sans qu'il ne s'en rende compte (car ils l'avaient drogué dans son sommeil aussi, et diffusé des cassettes audio d'hypnose pour qu'il vise une autre communauté).
 
   
 
Bon, toujours dans le même sujet, et tout aussi cynique:
   http://forum.hardware.fr/hfr/Discu [...] #t29609227
 
 

C'est bien ça qui me chagrine.

Tapport avec la choucroute ? Bah le fait que la fonction qui je m'attend à ce qu'elle "Return a string containing a nicely printable representation of an object" retourne juste un arrondi plus ou moins arbitraire (j'ai pas cherché d'où venait le choix de la précision).

Finalement je fais du "%.17g" % f, à l'ancienne.

Et j'aime pas repr parce que la couche COM m'envoie parfois des strings et parfois de l'unicode (comme ça lui chante), et évidemment, str(u'toto') est une string, alors que repr(u'toto') est de l'unicode.

Idem avec les dates, où le type est un truc hybride et moche, donc pour comparer une date avec un flottant (chose tout à fait normale avec Excel), on galère.

C'est plus de la faute d'excel que de python tout ça, mais bon. Si les fonction built-ins n'aident pas...

Je pense qu'ils auraient bien attendu 10jours

Ou alors, du genre "bon, on laisse les criminels en puissance bien tranquilles, avec un peu de chances l'un d'entre eux pète les plombs et passe à l'action, et on le chope juste après, normalement le battage médiatique devrait être exploitable pendant deux semaines"

Quand tu sérialises un double t'es bien obligé de renvoyer un arrondi arbitraire si tu veux l'afficher en décimal. non

T'as fait pareil mais avec un arrondi que t'as arbitré quoi.

  repr(u'toto') c'est un str:

et str(u'toto') c'est risqué pour d'autres raisons: c'est équivalent à u'toto'.decode(sys.getdefaultencoding())

là tu me fais très peur c'est quoi ce flottant, un timestamp unix?

Nan mais cette question est bonne, et ma réponse est: je veux la même précision que repr.
 

Mouais, je m'aide de la gentille norme IEEE 754. Je comprendrais si __str__ arbitrait sur du double, ou sur du simple-precision, ou même du quad si c'était raisonnable. Mais là, elle fait entre les 2 premiers, c'est médiocre.
 
 

Ah oui, repr(u'toto'), c'est pire que dans mon souvenir (parce qu'évidemment, je dois comparer ça à autre chose, puis le cracher en xml lisible par des mathématiciens à roulettes). Quand à l'encodage, je m'en tape, on est entre gens raisonnables ici : on ne parle que l'européen (bon, c'est pas vrai, mais les feuilles japonaises sont un peu le cadet de mes soucis là).
 

Non, c'est un nombre de jours depuis 1900 sous Windows, et depuis 1904 sous Macintosh. Et les heures/minutes sont les décimales.
 
Par contre, j'ai pas encore compris quel était le type renvoyé par pywin32 pour des vrais Variant(Date). Le type s'appele "time", mais se comporte comme du datetime (avé la fonction Format() et tout).

 
Le nombre d'eons depuis 1970, ramené en float denormalisé. Pourquoi tu fais pas comme ça toi ?  

Enfin au moins on est pas en train de lui augmenter son cheque de la caf et lui envoyer une assistante sociale pour l'aider a traverser cette passe difficile
 
Il aurait attendu trois mois on lui aurait propose un emploi pour se re inserer et une 4eme femme

 
BOUM ! Problème réglé.

Tu peux choisir la précision exactement suffisante pour le déserialiser sans perte non ?

Dans 2.6 c'est 17 décimales, dans 2.7 et 3.2 c'est la représentation la plus courte assurant que float(repr(x)) == x ( http://bugs.python.org/issue1580 )

La définition habituelle de __str__ en Python c'est "sort un truc qui a une bonne tête qu'on puisse afficher" (dans Python 2 en tout cas, dans Python 3 avec 1580 il me semble que float.__str__ == float.__repr__)

Bah oui mais en européen faire str(u) ça va pêter sur les accents, vu que l'encoding par défaut c'est ascii

Tu peux fourrer ça dans un timedelta direct et ajouter ce timedelta à ta date de référence (qui va dépendre de la plateforme), je sais pas si ça correspond à ton besoin:

>>> t = timedelta(18063.847)
>>> d + t
datetime.datetime(1949, 6, 16, 20, 19, 40, 800000)

par contre je laisse la détection de la date de référence à ton amusement.

Sinon si tu joues avec des fichiers excel t'as regardé xlwt? Il s'occupe d'une partie de ces merdes normalement (genre les dates)

Je pense, mais ça va être dépendant de plein de merdes genre la magnitude de ton flottant. T'auras plus vite fait de dumper le binaire en hex et de stocker ça, là t'as une représentation exacte et ça sera probablement plus court (d'ailleurs depuis 2.6 float a une méthode hex et une classmethod fromhex). Mais c'est probablement pas faisable si c'est pour mettre dans un fichier que des gens vont lire

la perpétuité réelle, pour ou contre ?  

Je fais beaucoup de COM, et en plus pas sur des vrais fichiers excel, donc ce genre de manip passe mal.
 
Inversement, je veux bien que python aspire vers une sorte de pureté abstraite sur sa représentation des flottants, mais vu la gueule de l'implémentation CPython, si j'étais lui, je ferais moins le malien (comme dirait Guéant):

>>> x,y
(1.0000000000000004, 1.0000000000000002)
>>> repr(x+x+y), repr(y+x+x)
('3.000000000000001', '3.0000000000000013')
>>> str(x+x+y), str(y+x+x)
('3.0', '3.0')

Si c'est du double, donne moi du double, bordel.  

   
Faut-il appliquer les peines plancher aux délinquants réitérants ?

J'ai pas dit ça

>>> x,y
(1.0000000000000004, 1.0000000000000002)
>>> repr(x+x+y), repr(y+x+x)
('3.000000000000001', '3.0000000000000013')
>>> str(x+x+y), str(y+x+x)
('3.0', '3.0')

Comme je l'ai dit, str essaie de sortir un truc joli, pas un truc correct.

j'ai pas la même valeur pour x+x+y accessoirement (mais en regardant avec des doubles dans ghci c'est chez moi que l'arrondi est pas bon)

Python 2.7 (r27:82500, Sep 16 2010, 18:02:00)
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
 
 
Aucun rapport, mais j'aime beaucoup le dessin de plantu. Très digne.

 

C'est vrai que Wikipedia, c'est pas comme faire des bébés: si on augmente le nombre de singes, on peut faire baisser le nombre de minutes...
http://fr.wikipedia.org/w/index.ph [...] on=history

Free universal construction kit  
http://fffff.at/free-universal-construction-kit/

 
F.U.C.K. \o/

funny, j'ai implémenté ça de la même façon sans savoir qu'Intel avait fait comme ça  

"14h25: Contrairement à ce qu'a annoncé BFMTV, le suspect n'a pas été arrêté, indique une source policière. "
 
lolbfm

Bon, on reprend. Please explain the last line naow.
 

>>> x = 0.024489486501872632
>>> x
0.02448948650187263
>>> "%.17f %.17g"%(x,x)
'0.02448948650187263 0.024489486501872632'