C'est du Python, time() donne juste le timestamp actuel (en type float, en plus).
Pourquoi en float et pas en long int ?
Pour avoir une partie décimale, peut-être ?
À quoi bon mesurer du temps avec des float, le type de nombre le plus imprécis qui soit venu au monde.
C'est beaucoup moins précis d'avoir 1277554952.652647 que 1277554952, c'est évident.
Les erreurs d'imprécision du genre 1/3 = 0.33333333333333331 n'arrivent pas partout. Et dans le cas cité plus haut, la partie décimale est suffisamment petite pour que ça n'arrive pas de toute façon.
J'ai fait un petit programme incrémentant 10000 fois de 0,3 un float, un double et un int, l'imprécision du float est énorme.
Il est sans doute préférable de faire des listes chaînées de int (vive l'assembleur...) que d'utiliser un nombre à virgule flottante lorsqu'il s'agit de calculs précis.
Je doute que ça soit le programme lui-même qui s'amuse à incrémenter sans cesse le timestamp, il doit le récupérer quelque part…
PS : j'ai fait le test, en partant d'un nombre a = 0.3, je me retrouve avec 3000.3000000003585 à la fin…
Mais avec un nombre de fois aussi immense qu'avec le timestamp, ça doit beaucoup jouer, donc il doit faire autrement.
Zul Sépare ton float en deux int, un pour la partie entière et un pour la partie décimale
Enfin, dans la mesure du possible
Comme une démonstration a l'air de devoir s'imposer, voici quelques captures d'écran :
http://s2.noelshack.com/old/up/capture_dacran_20100627__122226-eb0cc63a21.png
i est un double, j est un float et k est un int (incrémenté à l'aide d'un autre double).
On s'aperçoit que le float perd en précision seulement après quelques incréments. Voyez ce que ça donne à partir de k = 19 :
http://s2.noelshack.com/old/up/capture_dacran_20100627__122302-8d41fdd70.png
Lorsque k = 9999, j vaut environ 9996 et i est resté précis jusqu'au bout :
http://s2.noelshack.com/old/up/capture_dacran_20100627__122337-f40bc2f815.png
Alors, les float, moi j'oublie.
float vient d'être rayé de mon catalogue de types
VampireCow J'ai connu des commentaires plus constructifs de ta part
Ah bon ?
Oh oui !
CrazyNaly
Posté le 12 juillet 2009 à 23:31:54
T'inquiètes pas, je ne suis pas du genre à faire des remarques qui servent à rien
Bon alors j'ai trouvé le courage de lire ton texte, et...
...
...
Il est bien écrit! Sérieusement. Ce qui est bien aussi, c'est le début, j'ai remarqué que tu as mis un peu de suspense dans ton texte en montrant le nom du perso après son portrait et celui de sa soeur, c'est vraiment bien pensé.
Je n'ai pas trop compris ce qui précède un peu la fin, avec l'homme et la femme, mais j'imagine que c'est ce qui doit donner au lecteur l'envie de connaître la suite, n'est-ce pas?
J'ai vu aussi qu'il y avait rarement des fautes, il y en a quand même donc ça m'a un tout petit peu dérangé, mais ça me fait toujours ça même quand il y en a qu'une seule donc t'en fais pas et continue dans cette voie
Enfin bref, pas mal du tout pour un début (désolée d'écrire des longs commentaires, sans rancune!^^)
Bon, c'était spectaculaire non plus, mais bon
Non mais, de façon générale et dans la mesure du possible, mieux vaut éviter les manipulations avec des nombres à virgule sur un ordi, c'est souvent imprécis…
Les créateurs des langages le savent certainement bien mieux que nous. Je ne sais pas comment cette fonction time() fonctionne, la doc ne l'indique pas clairement, mais elle marche bien. J'ai utilisé la fonction localtime() qui renvoie la date correspondant au timestamp donné, et qui utilise celui donné par la fonction time() si on ne précise pas d'argument, et elle renvoie l'heure actuelle, à la seconde près.
Ah et, en Python, après 10 000 000 d'incrémentations de 0.3 (cette expression n'a pas de sens…), j'obtiens 3000000.2996692173.
La différence commence effectivement à un peu creuser.
Oui mais, vois-tu, au bout de 10 digits, même un double n'est pas capable de donner une précision correcte.
Je n'ai pas ces problèmes de choix de type, moi.
N'empêche, tout nombre à virgule flottante a une précision limitée.
Non, sans blague.
Je resterais donc sur ma position.
2 int > 1 double
2 long > 2 int.
Je sait qu'aujourd'hui ces deux types prennent le même espace en mémoire, mais le long est obligatoirement codé sur 4 octets. Alors, par convention...
Le nom « int » est mieux que « long », il est plus logique.