Connaitre le nombre de chiffres après la virgule d'un nombre
Résolu
Dagry
Messages postés
29
Date d'inscription
samedi 17 mars 2007
Statut
Membre
Dernière intervention
1 septembre 2008
-
29 août 2008 à 21:27
Kevin.Ory Messages postés 840 Date d'inscription mercredi 22 octobre 2003 Statut Membre Dernière intervention 7 janvier 2009 - 12 sept. 2008 à 21:45
Kevin.Ory Messages postés 840 Date d'inscription mercredi 22 octobre 2003 Statut Membre Dernière intervention 7 janvier 2009 - 12 sept. 2008 à 21:45
A voir également:
- Python nombre de chiffre après la virgule
- Limiter le nombre de chiffre apres la virgule python - Forum Visual Basic 6
- Java arrondir 2 chiffres après virgule - Forum Java
- Python arrondir 2 chiffres après la virgule - Forum ASP / ASP.NET
- Générateur de nombre ✓ - Forum PHP
- Python arrondi 2 chiffres après la virgule - Forum Visual Basic 6
57 réponses
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
9 sept. 2008 à 00:04
9 sept. 2008 à 00:04
Resalut, me revoici enfin sur mon sujet favoris du moment
us>
CDec et CDbl sont aussi des fonctions de VB... j'allais à nouveau râler , mais après une petite recherche sur le net, je ne le ferai pas:
Because "These functions are compiled inline" (http://msdn.microsoft.com/fr-fr/library/s2dy91zy(en-us).aspx), VB prend la meilleur décision pour maximiser la conversion d'un type à l'autre. Leur fonctionnement est différent, les fonctions de VB s'adaptent en fonctions des types sources et destination, elles sont donc plus souples et plus performantes suivant les cas. Mais sachant que "The Decimal type is not natively supported by the CLR", on peut dire que notre conversion sera de toute façon complexe (couteuse en CPU). (Intéressant: http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx)
Certaines fonctions de VB sont ma foit bien utiles
"La représentation binaire d'une valeur Decimal comporte un signe
1 bit, un nombre entier 96 bits (79 228 162 514 264 337 593 543 950 335 à moins 79 228 162 514 264 337 593 543 950 335) et un facteur d'échelle servant à
diviser l'entier 96 bits et à spécifier la partie correspondant à une
fraction décimale. (= indique la position de la virgule ) "
http://msdn.microsoft.com/fr-fr/library/system.decimal(VS.80).aspx
Donc plage de valeurs moins étendu qu'un Double, mais très précis et sans arrondis (mais très lourd à gérer, je le rappel).
"Le facteur d'échelle conserve également tous les zéros de fin dans un nombre Decimal . Les zéros de fin n'affectent pas la valeur d'un nombre Decimal dans les opérations arithmétiques ou de comparaison. Toutefois, les zéros de fin peuvent être révélés par la méthode ToString si une chaîne de mise en forme appropriée est appliquée."
Et toi qui aime le condensé (moi aussi ), sache qu'on peut faire la déclaration et l'assignation en 1 ligne :
If e.KeyCode = Keys.Enter Then
Dim x = Math.Abs(CDec(TextBox2.Text))
Dim lg = (x - Math.Floor(x)).ToString.TrimEnd("0"c).Length - 2
MsgBox(IIf(lg > 0, lg, 0))
End If
En admettant que le CDec donnent le même résultat que le Decimal.TryParse...
J'ai viré les type dans les déclarations, c'est correct (VB le fait tout seul) mais moi même je déclare toujours le type, et je le conseil (lg devient un Integer, pourquoi l'avoir déclaré en Long? Impossible d'avoir plus de 2 millards de chiffres après la virgule )
En plus, je ne fais plus la conversion Decimal=>Double=>Decimal. Sachant qu'un Decimal est très lourd à gérer (les conversions de et à Double!), je pense qu'un Trim est plus rapide.
us>
CDec et CDbl sont aussi des fonctions de VB... j'allais à nouveau râler , mais après une petite recherche sur le net, je ne le ferai pas:
Because "These functions are compiled inline" (http://msdn.microsoft.com/fr-fr/library/s2dy91zy(en-us).aspx), VB prend la meilleur décision pour maximiser la conversion d'un type à l'autre. Leur fonctionnement est différent, les fonctions de VB s'adaptent en fonctions des types sources et destination, elles sont donc plus souples et plus performantes suivant les cas. Mais sachant que "The Decimal type is not natively supported by the CLR", on peut dire que notre conversion sera de toute façon complexe (couteuse en CPU). (Intéressant: http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx)
Certaines fonctions de VB sont ma foit bien utiles
"La représentation binaire d'une valeur Decimal comporte un signe
1 bit, un nombre entier 96 bits (79 228 162 514 264 337 593 543 950 335 à moins 79 228 162 514 264 337 593 543 950 335) et un facteur d'échelle servant à
diviser l'entier 96 bits et à spécifier la partie correspondant à une
fraction décimale. (= indique la position de la virgule ) "
http://msdn.microsoft.com/fr-fr/library/system.decimal(VS.80).aspx
Donc plage de valeurs moins étendu qu'un Double, mais très précis et sans arrondis (mais très lourd à gérer, je le rappel).
"Le facteur d'échelle conserve également tous les zéros de fin dans un nombre Decimal . Les zéros de fin n'affectent pas la valeur d'un nombre Decimal dans les opérations arithmétiques ou de comparaison. Toutefois, les zéros de fin peuvent être révélés par la méthode ToString si une chaîne de mise en forme appropriée est appliquée."
Et toi qui aime le condensé (moi aussi ), sache qu'on peut faire la déclaration et l'assignation en 1 ligne :
If e.KeyCode = Keys.Enter Then
Dim x = Math.Abs(CDec(TextBox2.Text))
Dim lg = (x - Math.Floor(x)).ToString.TrimEnd("0"c).Length - 2
MsgBox(IIf(lg > 0, lg, 0))
End If
En admettant que le CDec donnent le même résultat que le Decimal.TryParse...
J'ai viré les type dans les déclarations, c'est correct (VB le fait tout seul) mais moi même je déclare toujours le type, et je le conseil (lg devient un Integer, pourquoi l'avoir déclaré en Long? Impossible d'avoir plus de 2 millards de chiffres après la virgule )
En plus, je ne fais plus la conversion Decimal=>Double=>Decimal. Sachant qu'un Decimal est très lourd à gérer (les conversions de et à Double!), je pense qu'un Trim est plus rapide.
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
9 sept. 2008 à 00:27
9 sept. 2008 à 00:27
candyraton>
"Je pense que Dagry est satisfait des réponses apportée"
J'avoue que je ne fais pas ça que pour lui
"Je ne sais pas non plus si les sources sont des String et si la limite de 29 est genante"
Ouais, si ça se trouve ces chiffres proviennent d'un fichier texte (xml, ini) et tout ceci ne sert à rien... mais comme je l'ai dis, je ne fais pas ça que pour lui
"J'espére que tu vas me donner la réponse!"
Un jour peut-être j'irai demander chez MS, mais pas ajd
"Effectivement, int (2.9) donne bien 2 mais int (-2.9) donne -3; c teffectivement timportant."
Ouais, d'où le Math.Abs dans le code de us
"PAS AVEC CDEC: CDec("000123") donne 123 !!!"
Ouais, mais "000123.123000" donne 123.123000
"(US-30 je crois qu'il faud l'abandonner)(United States?)"
"Je ne crois pas l'avoir dans mon vb6"
Les classes du framework .NET dans VB6? Possible? (pas impossible si ils sont "ComVisible = True" je crois)
"C du devellopement .net, que avec visual studio?
(j'avais cru comprendre que c'etait des bibliotheques compatibles plusieurs languages)"
Ouais, ou une version express, gratuite. Cherche Visual Basic Express si ça t'intéresse. Oui compatible plusieurs langages, mais langage managé .NET (donc pas VB6)
"Je veux pas non plus trop sortir du sujet, déjà trés content d'avoir appris :
"moins performante que les fonction du framework et conversion facile".............."
Ouais, mais ça ne s'applique pas à VB6
"Je pense que Dagry est satisfait des réponses apportée"
J'avoue que je ne fais pas ça que pour lui
"Je ne sais pas non plus si les sources sont des String et si la limite de 29 est genante"
Ouais, si ça se trouve ces chiffres proviennent d'un fichier texte (xml, ini) et tout ceci ne sert à rien... mais comme je l'ai dis, je ne fais pas ça que pour lui
"J'espére que tu vas me donner la réponse!"
Un jour peut-être j'irai demander chez MS, mais pas ajd
"Effectivement, int (2.9) donne bien 2 mais int (-2.9) donne -3; c teffectivement timportant."
Ouais, d'où le Math.Abs dans le code de us
"PAS AVEC CDEC: CDec("000123") donne 123 !!!"
Ouais, mais "000123.123000" donne 123.123000
"(US-30 je crois qu'il faud l'abandonner)(United States?)"
"Je ne crois pas l'avoir dans mon vb6"
Les classes du framework .NET dans VB6? Possible? (pas impossible si ils sont "ComVisible = True" je crois)
"C du devellopement .net, que avec visual studio?
(j'avais cru comprendre que c'etait des bibliotheques compatibles plusieurs languages)"
Ouais, ou une version express, gratuite. Cherche Visual Basic Express si ça t'intéresse. Oui compatible plusieurs langages, mais langage managé .NET (donc pas VB6)
"Je veux pas non plus trop sortir du sujet, déjà trés content d'avoir appris :
"moins performante que les fonction du framework et conversion facile".............."
Ouais, mais ça ne s'applique pas à VB6
cs_candyraton
Messages postés
109
Date d'inscription
dimanche 27 juillet 2008
Statut
Membre
Dernière intervention
2 février 2012
3
9 sept. 2008 à 15:25
9 sept. 2008 à 15:25
oooooooooooooookkkkkkkkkkkkkkkkkkk!!!!!!!!!!
us_30
Messages postés
2065
Date d'inscription
lundi 11 avril 2005
Statut
Membre
Dernière intervention
14 mars 2016
10
9 sept. 2008 à 19:31
9 sept. 2008 à 19:31
Bonjour Kevin,
En effet, c'est mieux...
Rappelons que "x" est supposé être un nombre de type "Decimal". La saisie par la textbox, n'est là que par commodité ici.
Et petite remarque amusante que je viens de constater, l'IDE de VB.NET n'aime pas le type Decimal ! mais seulement le type Double...
En effet, à partir de ton code, si on code " x = 1 / 7 ", ainsi donc :
Dim x As Decimal = 1 / 7
Dim lg = (x - Math.Floor(x)).ToString.TrimEnd("0"c).Length - 2
MsgBox(IIf(lg > 0, lg, 0))
on obtient 15 chiffres significatifs... en fait, il faut s'y prendre ainsi :
Dim x As Decimal = 1
x = x / 7
mais avuons, que c'est plutôt chi--t ! Microsoft, aurait pu regarder cela de plus près... ...
On peut même conclure que coder en dur un nombre en type Decimal, mérite de bien faire attention, car les calculs pourait ne pas donner le résultat avec la précision recherchée...
exemple :
Dim x As Decimal = 1
x = x / 7 + 1 / 7
qui donnerait x en Double... car 1/7 convertira toute la formule en Double... et en réalité, je ne suis pas arrivé à trouver une façon satisfaisante de mettre un nombre en précision Decimal en Dur dans l'IDE... ( 0.1428571428571428571428571429 étant tronqué aussi)...
En réalité, ce type Decimal, me semble être encore un joli casse tête... (j'ose pas encore regarder du côté des fonctions mathématiques avec...)... enfin, si, aller !
Essayons :
Dim x
As
Decimal = 1
x = Math.Sqrt(x / 7)
et paf ! 15 chiffres, pas une de plus !
et même chose, avec le LOG, SIN ... etc... puis en désespoir de cause, essayons avec les puissances (^)... et paf ! encore en précision Double, malgré la déclaration en Decimal !!
Dim x
As
Decimal = 1
Dim y
As
Decimal = 7
Dim z
As
Decimal = 0.5
x = (x / y) ^ z
et si Z=2, c'est encore la même chose... Pourtant, on pourrait espérer une précision plus importante, nan ?...
En d'autres termes, je me demande comment on peut avoir un résultat d'un calcul d'une formule (donc un poil plus compliqué que + et - et * et - ) en précision de type Decimal (28 chiffres après la virgule, hors pb de la partie entière)...
Amicalement,
Us.
En effet, c'est mieux...
Rappelons que "x" est supposé être un nombre de type "Decimal". La saisie par la textbox, n'est là que par commodité ici.
Et petite remarque amusante que je viens de constater, l'IDE de VB.NET n'aime pas le type Decimal ! mais seulement le type Double...
En effet, à partir de ton code, si on code " x = 1 / 7 ", ainsi donc :
Dim x As Decimal = 1 / 7
Dim lg = (x - Math.Floor(x)).ToString.TrimEnd("0"c).Length - 2
MsgBox(IIf(lg > 0, lg, 0))
on obtient 15 chiffres significatifs... en fait, il faut s'y prendre ainsi :
Dim x As Decimal = 1
x = x / 7
mais avuons, que c'est plutôt chi--t ! Microsoft, aurait pu regarder cela de plus près... ...
On peut même conclure que coder en dur un nombre en type Decimal, mérite de bien faire attention, car les calculs pourait ne pas donner le résultat avec la précision recherchée...
exemple :
Dim x As Decimal = 1
x = x / 7 + 1 / 7
qui donnerait x en Double... car 1/7 convertira toute la formule en Double... et en réalité, je ne suis pas arrivé à trouver une façon satisfaisante de mettre un nombre en précision Decimal en Dur dans l'IDE... ( 0.1428571428571428571428571429 étant tronqué aussi)...
En réalité, ce type Decimal, me semble être encore un joli casse tête... (j'ose pas encore regarder du côté des fonctions mathématiques avec...)... enfin, si, aller !
Essayons :
Dim x
As
Decimal = 1
x = Math.Sqrt(x / 7)
et paf ! 15 chiffres, pas une de plus !
et même chose, avec le LOG, SIN ... etc... puis en désespoir de cause, essayons avec les puissances (^)... et paf ! encore en précision Double, malgré la déclaration en Decimal !!
Dim x
As
Decimal = 1
Dim y
As
Decimal = 7
Dim z
As
Decimal = 0.5
x = (x / y) ^ z
et si Z=2, c'est encore la même chose... Pourtant, on pourrait espérer une précision plus importante, nan ?...
En d'autres termes, je me demande comment on peut avoir un résultat d'un calcul d'une formule (donc un poil plus compliqué que + et - et * et - ) en précision de type Decimal (28 chiffres après la virgule, hors pb de la partie entière)...
Amicalement,
Us.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
us_30
Messages postés
2065
Date d'inscription
lundi 11 avril 2005
Statut
Membre
Dernière intervention
14 mars 2016
10
9 sept. 2008 à 22:02
9 sept. 2008 à 22:02
Re,
Encore un truc, qui m'étonne encore plus, avec cet exemple :
Dim x
As
Decimal = 1
x = x / 7
TextBox1.Text = Str(x)
qui renvoi 28 chiffres, alors que :
Dim x
As
Decimal = 1
x = x / 7.0
TextBox1.Text = Str(x)
renvoi que 14 chiffres... Terrible !
Amicalement,
Us.
Encore un truc, qui m'étonne encore plus, avec cet exemple :
Dim x
As
Decimal = 1
x = x / 7
TextBox1.Text = Str(x)
qui renvoi 28 chiffres, alors que :
Dim x
As
Decimal = 1
x = x / 7.0
TextBox1.Text = Str(x)
renvoi que 14 chiffres... Terrible !
Amicalement,
Us.
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
10 sept. 2008 à 12:42
10 sept. 2008 à 12:42
Ah oui, assez étonnant comme résultat en effet (Même si ce n'est pas totalement illogique)
Par défaut, une division donne un résultat en Double, même si le résultat est assigné à une variable Decimal. Mais si tu fais comme ça, ça fonctionne:
Dim x As Decimal = 1 / CDec(7)
Console.WriteLine(x.ToString)
Il y a bien 28 chiffres après la virgule...
Dans ton 2ème message, 7.0 est un Double, tu aura donc un résultat en Double... Pour ce qui est du 7 qui donne un résultat correct, je ne sais pas
Et si tu regarde les fonctions de Math:
Math.Sqrt(d As Double) As Double
Donc ça n'a rien d'étonnant
"Et petite remarque amusante que je viens de constater, l'IDE de VB.NET
n'aime pas le type Decimal ! mais seulement le type Double..."
Comme je l'ai dis avant, le CLR .NET ne gère pas nativement les Decimal. Donc ca me semble assez logique... vais faire un petit test de perf Decimal vs Double, mais je suis sur du résultat...
Par défaut, une division donne un résultat en Double, même si le résultat est assigné à une variable Decimal. Mais si tu fais comme ça, ça fonctionne:
Dim x As Decimal = 1 / CDec(7)
Console.WriteLine(x.ToString)
Il y a bien 28 chiffres après la virgule...
Dans ton 2ème message, 7.0 est un Double, tu aura donc un résultat en Double... Pour ce qui est du 7 qui donne un résultat correct, je ne sais pas
Et si tu regarde les fonctions de Math:
Math.Sqrt(d As Double) As Double
Donc ça n'a rien d'étonnant
"Et petite remarque amusante que je viens de constater, l'IDE de VB.NET
n'aime pas le type Decimal ! mais seulement le type Double..."
Comme je l'ai dis avant, le CLR .NET ne gère pas nativement les Decimal. Donc ca me semble assez logique... vais faire un petit test de perf Decimal vs Double, mais je suis sur du résultat...
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
10 sept. 2008 à 12:56
10 sept. 2008 à 12:56
Dim start As DateTime = Now
For i = 0 To 100000000
Dim x As Decimal = 1 / CDec(7)
Next
Console.WriteLine((Now - start).TotalSeconds)
start = Now
For i = 0 To 100000000
Dim x As Double = 1 / 7
Next
Console.WriteLine((Now - start).TotalSeconds)
Ca affiche :
3.96875
0.46875
CQFD
Donc ouais, il faut faire attention avec ce type Decimal. Même si on travail avec des Decimal, les calculs se font bien souvent avec des Double.
Dim
x
As
Decimal
= 1
Dim
y
As
Decimal
= 7
Dim
z
As
Decimal
= 0.5
x = (x / y) ^ z
Ici, c'est le ^ qui transforme le tout en Double. Si tu remplace le ^ par un * ou un /, ça fonctionne. Comme quoi, il semble être impossible d'obtenir une puissance d'un Decimal (tout en gardant un Decimal).
For i = 0 To 100000000
Dim x As Decimal = 1 / CDec(7)
Next
Console.WriteLine((Now - start).TotalSeconds)
start = Now
For i = 0 To 100000000
Dim x As Double = 1 / 7
Next
Console.WriteLine((Now - start).TotalSeconds)
Ca affiche :
3.96875
0.46875
CQFD
Donc ouais, il faut faire attention avec ce type Decimal. Même si on travail avec des Decimal, les calculs se font bien souvent avec des Double.
Dim
x
As
Decimal
= 1
Dim
y
As
Decimal
= 7
Dim
z
As
Decimal
= 0.5
x = (x / y) ^ z
Ici, c'est le ^ qui transforme le tout en Double. Si tu remplace le ^ par un * ou un /, ça fonctionne. Comme quoi, il semble être impossible d'obtenir une puissance d'un Decimal (tout en gardant un Decimal).
us_30
Messages postés
2065
Date d'inscription
lundi 11 avril 2005
Statut
Membre
Dernière intervention
14 mars 2016
10
10 sept. 2008 à 15:28
10 sept. 2008 à 15:28
Bonjour Kevin,
Oui, j'avais bien compris que mes exemples faisaient un calcul en Double, et non en Décimal. Ce que je souligne, c'est dès qu'on utilise une opération autre que les 4 élémentaires (+, - , * , /) on passe en Double insidieusement... et il reste qu'il est plus que pas facile d'obtenir une racine carré en Decimal... puisque ^ , tout comme math.sqrt, donne un résultat en Double... (cela me semble même pas possible, à vrai dire...)
De plus, si dans :
Dim x AsDecimal = 1
x = x / 7
le résultat est en Décimal, je ne trouve pas que dans :
Dim x AsDecimal = 1
x = x / 7.0
qu'il soit logique de passer en Double...
Le type Décimal est sensé calculer avec des virgules flottantes aussi !?! En clair, le simple fait de mettre une virgule à 7.0, défini un Double... y'a de quoi de se prendre la tête un bon moment, le jour où on voudrait faire du calcul en 28 chiffres après la virgule avec des petits nombres...
Donc Logique, bof (un p'tit oui) , pratique, non ! ...
Et pour en revenir à la question première, on peut penser que le résultat du calcul de Dagry dont il souhait connaître le nombre de décimale après la virgule, est presque surement en Double... Par conséquent, informatiquement on atteindra pas les 19 décimales qu'il évoquait, mais 15 décimales au mieux...
En conséquence, il faut revoir les ambitions pour ce problème de précision...
Et franchement, je trouve un peu fort en chocolat, que Microsoft vante le type Decimal... on va pas très loin avec ! Voir on peut rien en faire !
Finalement, je pense que rester en Double dans les calculs à virgules reste encore la meilleure solution...
Note aussi, un autre truc étonnant, que je viens de constater avec le type System.UInt64, qui permet normalement d'aller de 0 à 18446744073709551615,
or l'IDE refuse qu'on rentre une borne supérieure au type System.Int64 (soit 9223372036854775807)... même si le calcul est possible...
C'est la misère les calculs en VB.NET... Il ne dépasse même pas le VBA ! (ou ce type Decimal existait déjà... avec les mêmes défauts... !!!!!)
Amicalement,
Us.
Oui, j'avais bien compris que mes exemples faisaient un calcul en Double, et non en Décimal. Ce que je souligne, c'est dès qu'on utilise une opération autre que les 4 élémentaires (+, - , * , /) on passe en Double insidieusement... et il reste qu'il est plus que pas facile d'obtenir une racine carré en Decimal... puisque ^ , tout comme math.sqrt, donne un résultat en Double... (cela me semble même pas possible, à vrai dire...)
De plus, si dans :
Dim x AsDecimal = 1
x = x / 7
le résultat est en Décimal, je ne trouve pas que dans :
Dim x AsDecimal = 1
x = x / 7.0
qu'il soit logique de passer en Double...
Le type Décimal est sensé calculer avec des virgules flottantes aussi !?! En clair, le simple fait de mettre une virgule à 7.0, défini un Double... y'a de quoi de se prendre la tête un bon moment, le jour où on voudrait faire du calcul en 28 chiffres après la virgule avec des petits nombres...
Donc Logique, bof (un p'tit oui) , pratique, non ! ...
Et pour en revenir à la question première, on peut penser que le résultat du calcul de Dagry dont il souhait connaître le nombre de décimale après la virgule, est presque surement en Double... Par conséquent, informatiquement on atteindra pas les 19 décimales qu'il évoquait, mais 15 décimales au mieux...
En conséquence, il faut revoir les ambitions pour ce problème de précision...
Et franchement, je trouve un peu fort en chocolat, que Microsoft vante le type Decimal... on va pas très loin avec ! Voir on peut rien en faire !
Finalement, je pense que rester en Double dans les calculs à virgules reste encore la meilleure solution...
Note aussi, un autre truc étonnant, que je viens de constater avec le type System.UInt64, qui permet normalement d'aller de 0 à 18446744073709551615,
or l'IDE refuse qu'on rentre une borne supérieure au type System.Int64 (soit 9223372036854775807)... même si le calcul est possible...
C'est la misère les calculs en VB.NET... Il ne dépasse même pas le VBA ! (ou ce type Decimal existait déjà... avec les mêmes défauts... !!!!!)
Amicalement,
Us.
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
10 sept. 2008 à 17:02
10 sept. 2008 à 17:02
"y'a de quoi de se prendre la tête un bon moment, le jour où on voudrait
faire du calcul en 28 chiffres après la virgule avec des petits
nombres...
Donc Logique, bof (un p'tit oui) , pratique, non ! ..."
Absolument d'accord avec toi
"En conséquence, il faut revoir les ambitions pour ce problème de précision...
"
Toujours d'accord. On ne peut pas dire que nos recherches aient pour but de répondre à Dagry
"Et franchement, je trouve un peu fort en chocolat, que Microsoft vante
le type Decimal... on va pas très loin avec ! Voir on peut rien en
faire !"
Ils parlent de calculs monétaires. Or il est rare de faire des racines et des sinus avec des valeurs monétaire Le type Décimal n'est pas destiné à faire du "calcul mathématique"
"Finalement, je pense que rester en Double dans les calculs à virgules reste encore la meilleure solution...
"
C'est certain
Je rappel que le CLR ne gère pas les Decimal nativement, on peut donc très bien nous même créer un nouveau type et faire les calculs manuellement, comme on le ferait en assembleur, cela viendrait plus ou moins au même...
"or l'IDE refuse qu'on rentre une borne supérieure au type System.Int64"
Problème de l'IDE plutôt alors, pas du CLR et du framework non?
faire du calcul en 28 chiffres après la virgule avec des petits
nombres...
Donc Logique, bof (un p'tit oui) , pratique, non ! ..."
Absolument d'accord avec toi
"En conséquence, il faut revoir les ambitions pour ce problème de précision...
"
Toujours d'accord. On ne peut pas dire que nos recherches aient pour but de répondre à Dagry
"Et franchement, je trouve un peu fort en chocolat, que Microsoft vante
le type Decimal... on va pas très loin avec ! Voir on peut rien en
faire !"
Ils parlent de calculs monétaires. Or il est rare de faire des racines et des sinus avec des valeurs monétaire Le type Décimal n'est pas destiné à faire du "calcul mathématique"
"Finalement, je pense que rester en Double dans les calculs à virgules reste encore la meilleure solution...
"
C'est certain
Je rappel que le CLR ne gère pas les Decimal nativement, on peut donc très bien nous même créer un nouveau type et faire les calculs manuellement, comme on le ferait en assembleur, cela viendrait plus ou moins au même...
"or l'IDE refuse qu'on rentre une borne supérieure au type System.Int64"
Problème de l'IDE plutôt alors, pas du CLR et du framework non?
us_30
Messages postés
2065
Date d'inscription
lundi 11 avril 2005
Statut
Membre
Dernière intervention
14 mars 2016
10
10 sept. 2008 à 19:00
10 sept. 2008 à 19:00
Salut,
Ben, j'ai ouvert Excel pour voir dans l'aide quelques fonctions financières (comprendre monétaires) et, par exemple pour le calcul du TAUX.NOMINAL on a une formule avec une puissance... donc voilà, c'est pour dire qu'on peut aussi utiliser des opérations autres qu'élémentaires... (tu vas dire que la précision à 28 chiffres, n'est pas utile. C'est vrai. Mais autant rester en Double aussi)... De toute façon pour le calcul monétaire, on arrondi toujours à 2 chiffres... Finallement, ce type Decimal me semble vraiment de plus en plus inutile... je reprendrais ta citation, mais ironiquement : "Le type Décimal n'est pas destiné à faire du calcul mathématique " ! (et comble, nan ?)
Pour l'autre type : System.UInt64... c'est plutôt mon ignorance, qui vient d'être éclairée par Charles RACAUD... IL faut écrire le nb ainsi :
Dim x As ULong = 18446744073709551615UL
pour le type Décimal, on pourrait l'écrire avec D à la fin du nb comme identificateur... je ne savais pas. Mais cela ne change pas les remarques précédentes sur la précision du calcul (Conv en Double)... [ à moins qu'il existe un moyen bien caché, après tout... mais je demande à voir le code pour avoir SQRT(2) en 28 décimales... -:); ]
Amicalement,
Us.
Ben, j'ai ouvert Excel pour voir dans l'aide quelques fonctions financières (comprendre monétaires) et, par exemple pour le calcul du TAUX.NOMINAL on a une formule avec une puissance... donc voilà, c'est pour dire qu'on peut aussi utiliser des opérations autres qu'élémentaires... (tu vas dire que la précision à 28 chiffres, n'est pas utile. C'est vrai. Mais autant rester en Double aussi)... De toute façon pour le calcul monétaire, on arrondi toujours à 2 chiffres... Finallement, ce type Decimal me semble vraiment de plus en plus inutile... je reprendrais ta citation, mais ironiquement : "Le type Décimal n'est pas destiné à faire du calcul mathématique " ! (et comble, nan ?)
Pour l'autre type : System.UInt64... c'est plutôt mon ignorance, qui vient d'être éclairée par Charles RACAUD... IL faut écrire le nb ainsi :
Dim x As ULong = 18446744073709551615UL
pour le type Décimal, on pourrait l'écrire avec D à la fin du nb comme identificateur... je ne savais pas. Mais cela ne change pas les remarques précédentes sur la précision du calcul (Conv en Double)... [ à moins qu'il existe un moyen bien caché, après tout... mais je demande à voir le code pour avoir SQRT(2) en 28 décimales... -:); ]
Amicalement,
Us.
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
11 sept. 2008 à 21:42
11 sept. 2008 à 21:42
Ouais bonne remarque pour les UL et et autres D, j'avais pas pensé à ça. J'en connaissais l'existence, mais je n'ai jamais eu besoins d'utiliser ces notations
Il y a qq fonctions statiques dans la structure Decimal, comme Multiply ou Divide, mais rien de plus "poussé" comme des puissances.
Maintenant, si on réfléchis plus loin dans la logique du monétaire. Quel type utiliser pour mémoriser la valeur du solde d'un compte?
Un Double, avec sa 15aine de chiffres significatifs, donne un solde maximum d'environ :
1'000'000'000'000.00 = 1000 milliards
Pour moi c'est suffisant ça ne fait pas de doute, mais qu'en est-il d'une banque?
Voici déjà +1 pour le decimal.
Ensuite, on a vu qu'en Double 1.2 - 1 = 0.199999999999999
Non seulement les clients ne vont pas être content de voir des centimes disparaitre de leurs comptes sans raison, mais en plus cet argent disparait sans laisser de traces, et il a donc un impact sur l'économie globale d'un pays ou plus.
Les arrondis des nombres flottants peuvent être catastrophiques pour la gestion de l'argent, et sont donc absolument inadapté pour cela.
+2 pour le Decimal
Le Decimal est adapté pour la gestion d'un compte, c'est à dire débit, crédit et solde. Si après on veut faire des graphiques, des moyennes ou je ne sais quoi, on pourra utiliser des Double sans pour autant fausser quoi que ce soit.
Bon après tu va me dire, et dans ce cas pourquoi ne pas simplement utiliser un entier?
un Int64 va jusqu'à 92'233'720'368'547'758.07 = 92'233'720 milliards.
Ouais ben ouais... bonne question
Il y a quand même bien plus de chiffres dans un Decimal que dans un entier 64bit, mais pourquoi avoir besoins d'une virgule flottante pour faire du crédit/débit?
Il y a qq fonctions statiques dans la structure Decimal, comme Multiply ou Divide, mais rien de plus "poussé" comme des puissances.
Maintenant, si on réfléchis plus loin dans la logique du monétaire. Quel type utiliser pour mémoriser la valeur du solde d'un compte?
Un Double, avec sa 15aine de chiffres significatifs, donne un solde maximum d'environ :
1'000'000'000'000.00 = 1000 milliards
Pour moi c'est suffisant ça ne fait pas de doute, mais qu'en est-il d'une banque?
Voici déjà +1 pour le decimal.
Ensuite, on a vu qu'en Double 1.2 - 1 = 0.199999999999999
Non seulement les clients ne vont pas être content de voir des centimes disparaitre de leurs comptes sans raison, mais en plus cet argent disparait sans laisser de traces, et il a donc un impact sur l'économie globale d'un pays ou plus.
Les arrondis des nombres flottants peuvent être catastrophiques pour la gestion de l'argent, et sont donc absolument inadapté pour cela.
+2 pour le Decimal
Le Decimal est adapté pour la gestion d'un compte, c'est à dire débit, crédit et solde. Si après on veut faire des graphiques, des moyennes ou je ne sais quoi, on pourra utiliser des Double sans pour autant fausser quoi que ce soit.
Bon après tu va me dire, et dans ce cas pourquoi ne pas simplement utiliser un entier?
un Int64 va jusqu'à 92'233'720'368'547'758.07 = 92'233'720 milliards.
Ouais ben ouais... bonne question
Il y a quand même bien plus de chiffres dans un Decimal que dans un entier 64bit, mais pourquoi avoir besoins d'une virgule flottante pour faire du crédit/débit?
us_30
Messages postés
2065
Date d'inscription
lundi 11 avril 2005
Statut
Membre
Dernière intervention
14 mars 2016
10
12 sept. 2008 à 11:12
12 sept. 2008 à 11:12
lol... Comment ça 1000 millards c'est suffisant ? c'est une goutte d'eau !
(bon, une grosse goutte d'accord...)
Ensuite, on va pas rentrer trop dans ce débat, mais je reste convaincu que le type décimal ne sert à rien.
Ton argumentation pour défendre l'existence de ce type "Décimal", me laissera toujours perplexe... Déjà, tu te mets dans l'hypothèse d'une banque... euh, qui programme pour une banque avec ce type ?... à mon humble avis, pas grand monde... On est donc bien content que Microsoft ait pensé à cette poignée de type, au point de créer un type de nombre que seul eux auront peut-être besoin. Je dis bien "peut-être", car comment faisait-ils avant sans le Décimal ?... donc -1.
De plus, si 1.2 - 1 = 0.199999999999999, j'imagine la tête de mon banquier, quand je vais lui dire de me rendre la monnaie... SVP, monsieur le banquier, voulez-vous bien me rendre mes 0.000000000000001 euros ! Je pense, qu'il va arrondir... D'ailleurs, soit dit en passant, tout compte est arrondi au centime... Très rarement, on va un peu plus loin. Par exemple, pour le prix du pétrole en bourse, on va jusqu'à 3 chiffres après la virgule (mais pas plus loin)... donc -2.
Par conséquent, le Double est tout aussi adapté (et d'ailleurs, je suis certain que c'est avec ce type que les logiciels bancaire travaillent) que le Décimal, pour un "débit, crédit et solde"... donc -3.
Pour l'Int64, je ne saisi pas le sens de ta remarque. Un entier INT64, ne peut pas avoir de partie décimale...
En fin de compte (jeu de mot), si je calcul bien, tu as : +2 et moi -3 ! Or +2-3 = -1... aux arrondis près du Double, ou avec la précision fantoche d'un Décimal...
Amicalement,
Us.
(bon, une grosse goutte d'accord...)
Ensuite, on va pas rentrer trop dans ce débat, mais je reste convaincu que le type décimal ne sert à rien.
Ton argumentation pour défendre l'existence de ce type "Décimal", me laissera toujours perplexe... Déjà, tu te mets dans l'hypothèse d'une banque... euh, qui programme pour une banque avec ce type ?... à mon humble avis, pas grand monde... On est donc bien content que Microsoft ait pensé à cette poignée de type, au point de créer un type de nombre que seul eux auront peut-être besoin. Je dis bien "peut-être", car comment faisait-ils avant sans le Décimal ?... donc -1.
De plus, si 1.2 - 1 = 0.199999999999999, j'imagine la tête de mon banquier, quand je vais lui dire de me rendre la monnaie... SVP, monsieur le banquier, voulez-vous bien me rendre mes 0.000000000000001 euros ! Je pense, qu'il va arrondir... D'ailleurs, soit dit en passant, tout compte est arrondi au centime... Très rarement, on va un peu plus loin. Par exemple, pour le prix du pétrole en bourse, on va jusqu'à 3 chiffres après la virgule (mais pas plus loin)... donc -2.
Par conséquent, le Double est tout aussi adapté (et d'ailleurs, je suis certain que c'est avec ce type que les logiciels bancaire travaillent) que le Décimal, pour un "débit, crédit et solde"... donc -3.
Pour l'Int64, je ne saisi pas le sens de ta remarque. Un entier INT64, ne peut pas avoir de partie décimale...
En fin de compte (jeu de mot), si je calcul bien, tu as : +2 et moi -3 ! Or +2-3 = -1... aux arrondis près du Double, ou avec la précision fantoche d'un Décimal...
Amicalement,
Us.
gillardg
Messages postés
3275
Date d'inscription
jeudi 3 avril 2008
Statut
Membre
Dernière intervention
14 septembre 2014
2
12 sept. 2008 à 11:47
12 sept. 2008 à 11:47
en vb6 il y avait le type Currency
Decimal est en fait un remplacement de Currency
essaie de coller la ligne suivante dans vb200*
Dim x As Currency
tu verras la proposition de correction de vb
Bonjour chez vous !
Decimal est en fait un remplacement de Currency
essaie de coller la ligne suivante dans vb200*
Dim x As Currency
tu verras la proposition de correction de vb
Bonjour chez vous !
us_30
Messages postés
2065
Date d'inscription
lundi 11 avril 2005
Statut
Membre
Dernière intervention
14 mars 2016
10
12 sept. 2008 à 12:22
12 sept. 2008 à 12:22
Bonjour,
Voici ce que propose VB2008 : Dim x As CurrencyManager !!!
Rien à voir !
Le type Décimal existe sous VBA, exactement dans les mêmes termes que dans VB.NET (28 décimales, même plage, et tout et tout)...(currency aussi d'ailleurs). Seul la déclaration était; plus ésotérique. IL faut passer par un Variant avant... Mais les défauts (problèmes) dans les calculs, sont identiques !!
J'ai la grosse impression, que Microsoft ne sont pas foulés beaucoup... Et, par expérience, il est clair qu'il faut mieux laisser tomber ce type Decimal, car au final, on y revient toujours pour tout remettre en Double... question de pratique... Ensuite, qu'en on y réfléchi, la précision à 28 décimales, ne sert jamais. ET pire, même s'il y faut une précision acrue, il conviendra de toujours programmer des garde-fous ! car rien de dit que 28 décimales soient suffisants, en plus...
Amicalement,
Us.
Voici ce que propose VB2008 : Dim x As CurrencyManager !!!
Rien à voir !
Le type Décimal existe sous VBA, exactement dans les mêmes termes que dans VB.NET (28 décimales, même plage, et tout et tout)...(currency aussi d'ailleurs). Seul la déclaration était; plus ésotérique. IL faut passer par un Variant avant... Mais les défauts (problèmes) dans les calculs, sont identiques !!
J'ai la grosse impression, que Microsoft ne sont pas foulés beaucoup... Et, par expérience, il est clair qu'il faut mieux laisser tomber ce type Decimal, car au final, on y revient toujours pour tout remettre en Double... question de pratique... Ensuite, qu'en on y réfléchi, la précision à 28 décimales, ne sert jamais. ET pire, même s'il y faut une précision acrue, il conviendra de toujours programmer des garde-fous ! car rien de dit que 28 décimales soient suffisants, en plus...
Amicalement,
Us.
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
12 sept. 2008 à 20:35
12 sept. 2008 à 20:35
"Ton argumentation pour défendre l'existence de ce type "Décimal", me laissera toujours perplexe..."
Je m'incline
Mon argumentation ne m'a même pas convaincu moi-même. Je tiens à préciser que je me faisais juste l'avocat du Diable, je n'ai moi-même jamais utilisé ce type et ne l'utiliserai sans doute jamais
"Par conséquent, le Double est tout aussi adapté que le Décimal, pour un "débit, crédit et solde""
Pour les 0.000000000000001 euros, je voulais parler des arrondis en général. Ne serait-ce pas possible que dans certains cas l'arrondis provoque des erreurs significatives?
Pour un retrait OK, mais si il y a des milliers de retraits/virement tous les jours, à la fin il y aura quand même une somme d'argent "significative" qui disparaitra. Les arrondis des Double sont rarement indésirable pour un seul calcul, mais peuvent poser problème lorsque il y a de nombreux calculs à la suite (erreur cumulative).
"Pour l'Int64, je ne saisi pas le sens de ta remarque. Un entier INT64, ne peut pas avoir de partie décimale..."
Elle peut être "virtuelle". La virgule dans une somme d'argent ne "flotte" pas, je veux dire qu'une somme aura toujours un même nombre de décimal. On peut donc très bien enregistrer les sommes en centimes et faire un /100 à l'affichage, cela évite l'utilisation de nombres à virgules flottantes, plus lents et sujet à des arrondis. Dans des cas comme ceux-ci, on à pas besoins d'aller à des e308 ou e-307, le solde est bien un nombre entier, même si l'unité est le centime et non l'euro. (cette méthode de "virgule virtuelle" comme je l'appel, n'a rien d'exceptionnel. C'est simplement un rapport entre la valeur et l'affichage (scrollbar))
Donc oui, je suis entièrement d'accord avec toi au sujet du Decimal qui me semble bien inutile, mais je reste sur ma position au sujet du Double dans le monde de l'argent...
"En fin de compte (jeu de mot), si je calcul bien, tu as : +2 et moi -3
! Or +2-3 = -1... aux arrondis près du Double, ou avec la précision
fantoche d'un Décimal...
"
Ouais je ne les ai pas mis cette fois
"Voici ce que propose VB2008 : Dim x As CurrencyManager"
Moi pas: "'Currency' n'est plus un type pris en charge ; utilisez le type 'Decimal' à la place.", et c'est bien ce qu'il propose (VB2008 Express)
C'était quoi la question initiale déjà?
Je m'incline
Mon argumentation ne m'a même pas convaincu moi-même. Je tiens à préciser que je me faisais juste l'avocat du Diable, je n'ai moi-même jamais utilisé ce type et ne l'utiliserai sans doute jamais
"Par conséquent, le Double est tout aussi adapté que le Décimal, pour un "débit, crédit et solde""
Pour les 0.000000000000001 euros, je voulais parler des arrondis en général. Ne serait-ce pas possible que dans certains cas l'arrondis provoque des erreurs significatives?
Pour un retrait OK, mais si il y a des milliers de retraits/virement tous les jours, à la fin il y aura quand même une somme d'argent "significative" qui disparaitra. Les arrondis des Double sont rarement indésirable pour un seul calcul, mais peuvent poser problème lorsque il y a de nombreux calculs à la suite (erreur cumulative).
"Pour l'Int64, je ne saisi pas le sens de ta remarque. Un entier INT64, ne peut pas avoir de partie décimale..."
Elle peut être "virtuelle". La virgule dans une somme d'argent ne "flotte" pas, je veux dire qu'une somme aura toujours un même nombre de décimal. On peut donc très bien enregistrer les sommes en centimes et faire un /100 à l'affichage, cela évite l'utilisation de nombres à virgules flottantes, plus lents et sujet à des arrondis. Dans des cas comme ceux-ci, on à pas besoins d'aller à des e308 ou e-307, le solde est bien un nombre entier, même si l'unité est le centime et non l'euro. (cette méthode de "virgule virtuelle" comme je l'appel, n'a rien d'exceptionnel. C'est simplement un rapport entre la valeur et l'affichage (scrollbar))
Donc oui, je suis entièrement d'accord avec toi au sujet du Decimal qui me semble bien inutile, mais je reste sur ma position au sujet du Double dans le monde de l'argent...
"En fin de compte (jeu de mot), si je calcul bien, tu as : +2 et moi -3
! Or +2-3 = -1... aux arrondis près du Double, ou avec la précision
fantoche d'un Décimal...
"
Ouais je ne les ai pas mis cette fois
"Voici ce que propose VB2008 : Dim x As CurrencyManager"
Moi pas: "'Currency' n'est plus un type pris en charge ; utilisez le type 'Decimal' à la place.", et c'est bien ce qu'il propose (VB2008 Express)
C'était quoi la question initiale déjà?
us_30
Messages postés
2065
Date d'inscription
lundi 11 avril 2005
Statut
Membre
Dernière intervention
14 mars 2016
10
12 sept. 2008 à 21:23
12 sept. 2008 à 21:23
Bonsoir Kevin,
Nous sommes d'accord... Effectivement, arrêtons peut-être là ces posts qui finissent par s'écarter du sujet initial...
"Ne serait-ce pas possible que dans certains cas l'arrondis provoque des erreurs significatives?"
> Oui, dans certains cas, mais presque impossible avec les 4 opérations élémentaires, pour la bonne raison, que statistiquement, il y a nécessairement une compensation des arrondis en plus et en moins... Il faudrait un nombre de calcul gigantesque pour avoir une différence significative... C'est plutôt dans des calculs scientifique, que cela peut se produire rapidement... mais bon.
Pour l'Int64, Ok, juditieux.
Mais, cela suppose que + et - ... Sinon, le calcul de la virgule flottante est à gérer...
"je reste sur ma position au sujet du Double dans le monde de l'argent"
Bien. Tant pis pour ton banquier ! (il va s'arracher les cheveux...)
'Currency'... n'est pas mieux que Décimal... L'important est de ne pas oublier que le moindre calcul "sophistiqué" passe en Double...
A noter aussi, qu'il reste sous VB2008 que 3 types numériques décimales (Single, Double, Décimal)...
Donc au final, je ne vois que Double... (...euh, j'ai bu ?...)
Amicalement,
Us.
Nous sommes d'accord... Effectivement, arrêtons peut-être là ces posts qui finissent par s'écarter du sujet initial...
"Ne serait-ce pas possible que dans certains cas l'arrondis provoque des erreurs significatives?"
> Oui, dans certains cas, mais presque impossible avec les 4 opérations élémentaires, pour la bonne raison, que statistiquement, il y a nécessairement une compensation des arrondis en plus et en moins... Il faudrait un nombre de calcul gigantesque pour avoir une différence significative... C'est plutôt dans des calculs scientifique, que cela peut se produire rapidement... mais bon.
Pour l'Int64, Ok, juditieux.
Mais, cela suppose que + et - ... Sinon, le calcul de la virgule flottante est à gérer...
"je reste sur ma position au sujet du Double dans le monde de l'argent"
Bien. Tant pis pour ton banquier ! (il va s'arracher les cheveux...)
'Currency'... n'est pas mieux que Décimal... L'important est de ne pas oublier que le moindre calcul "sophistiqué" passe en Double...
A noter aussi, qu'il reste sous VB2008 que 3 types numériques décimales (Single, Double, Décimal)...
Donc au final, je ne vois que Double... (...euh, j'ai bu ?...)
Amicalement,
Us.
Kevin.Ory
Messages postés
840
Date d'inscription
mercredi 22 octobre 2003
Statut
Membre
Dernière intervention
7 janvier 2009
11
12 sept. 2008 à 21:45
12 sept. 2008 à 21:45
"arrêtons peut-être là ces posts qui finissent par s'écarter du sujet initial..."
J'avoue avoir de la peine
"Pour l'Int64, cela suppose que + et - ... Sinon, le calcul de la virgule flottante est à gérer...
"
Pas forcément, on peut très bien faire des divisions avec des entiers, simplement que les résultats seront arrondis à l'entier le plus proche, ce qui peut-être voulu.
Bah je te dis déjà merci pour cette intéressante discussion. Ca change de certains autres sujets
Bonne soirée
J'avoue avoir de la peine
"Pour l'Int64, cela suppose que + et - ... Sinon, le calcul de la virgule flottante est à gérer...
"
Pas forcément, on peut très bien faire des divisions avec des entiers, simplement que les résultats seront arrondis à l'entier le plus proche, ce qui peut-être voulu.
Bah je te dis déjà merci pour cette intéressante discussion. Ca change de certains autres sujets
Bonne soirée