Version imprimable
bonjour ,
j'aimerai sauvegarder un double dans un fichier , mais j'ai un problème le double ne se sauvegarde pas totalement exemple: valeur=-0.095343822494982647 il sauvegarde sa:-0,0953438224949826 , et qnd je le recupaire du fichier il me donne sa :-0.095343822494982605 comment je fait a ce problème Merci
Essaye ça pour voir :Code:
2
merci pour ta reponse , j' ai essayée sa mais regarde le résultats:
le résultats:Code:
2
il a supprime les 2 derniers chiffres et il a les remplacer par 0?!!!!Code:d = -0.095343822494982600;
Tu as vraiment besoin d'une telle précision ?
Que calcule tu ?
Si t'as besoin de tant de precision, le double suffit plus ; faut utiliser un decimal.
La question à se poser c'est surtout comment tu sauvegarde le double dans le fichier. Et est-ce que ce double doit être lisible (fichier texte)?
moi je transformerais le double en decimal avant de le mettre en string
enfin le double il faut éviter de l'utiliser, ce n'est pas un nombre fixe !
Ca ça m'intéresse!Citation:
Envoyé par sperot51
J'avais eu ce genre de soucis avec un Float, qui avait une drôle de précision (en 10e-14). Je suppose que ce soucis et du même ordre?
Ps: désolé du HS, mais je veux pas créer un sujet pour ça ;)
single et double (.net) et leurs équivalents dans les sgbd (comme le float) sont stockés en mémoire comme une formule mathématique
pour certaines nombre l'affichage de cette formule mathématique arrondi forcément, ce qui est normal, 1/3 par exemple n'as pas de limite de chiffre
le type decimal (decimal ou numéric sur sql server) sont enregistré sous la forme d'un nombre, avec l'emplacement de la virgule
pour des calculs financiers les types single et double sont donc à proscrire car au bout de la feuille de paye, s'il y a des divisions vous avez des centimes qui peuvent disparaitre ! (dans sql server il y a money et smallmoney qui sont fiables aussi)
par contre le type decimal est moins rapide pour des calculs (rien de bien grave cependant)
Et en ces temps difficiles sali-lala doit probablement vouloir utiliser la précision d'un dramatic small money !:mouarf:Citation:
(dans sql server il y a money et smallmoney qui sont fiables aussi)
Money c'est que 5chiffres après la virgule.. smallmoney c'est plus?
Apparement sali-lala s'est perdu dans une infinitésimale dimension pendant que l'on fume la moquette ici bas
Je reviens a ma question pratique : dans quel contexte sali-lala a-t-il besoin d'une telle précision ?
On parle de de quantités plus petites qu'un dix millionniéme de milliardieme
-0.095 343 822 494 982 6 47
-0.095 343 822 494 982 6 05
small veut dire petit ... donc ca me parait difficileCitation:
Envoyé par Lyche
euh, c'en est limite une, non ? :lol:Citation:
Soutenez le CCLQC (Comité Contre Les Questions Cons)
trouvé sur un site :
Citation:
money est un bigint (entier signé 64 bits) divisé par 10000 (8 octets)
o -922337203685477,5808 à 922337203685477,5807
o Equivalent d'un DECIMAL(18,4) / DECIMAL(19,4)
smallmoney est un int (entier signé 32 bits) divisé par 10000 (4 octets)
o -214748,3648 à 214748,3647
o Equivalent d'un DECIMAL(10,4) / DECIMAL(9,4)
Les plus de ce type :
* Rapide en calcul, comme ce sont des entiers
* Petit en taille, respectivement 4 et 8 octets
* Dans certains cas renvoie un symbole monétaire
Les moins de ce type :
* Symbole monétaire renvoyé basé sur les paramètres système
* Nombre de décimal fixe et insuffisant dans certains cas (5 aurait été idéal)
* Non standard, contrairement au type numeric / decimal
* Plage de valeur très restreinte pour le smallmoney
Ouai j'assume, mais il est vendredi et c'est la fatigue qui parle.. Ce que j'entendais par "c'est plus" c'était par rapport au nombre de décimal.. Il est vrai que 4 chiffres c'est parfois pas assez :(
merci a vous tous voici la solution :http://msdn.microsoft.com/fr-fr/libr...sa(VS.95).aspx.
donc il faut sauvgarder comme ça:Code:lignes += pt.ToString("G18");