Je travaille sur des valeurs décimales d'une précision pouvant aller à 8
chiffres après la virgule. Je décide donc de définir les données au type
Double. Mais j'ai des problèmes au niveau du résultat, exemple :
Private Sub Command1_Click()
Dim angle As Integer, tour As Integer, i As Double
Dim angdes As Double, angdeb As Double, angG As Double
tour = 360
angle = 0
angG = tour / 14
For i = 0 To tour Step angG
angdeb = angle + i
MsgBox angdeb & "/" & i
If angdeb = 360 Then MsgBox "toto"
Next i
End Sub
1) Déjà au niveau de la boucle, la valeur i ne va pas jusque 360?????.
Pourtant angG * 14 = 360 .....
Il faudrait que le rajoute par exemple 1 à tour : For i = 0 To tour +1 Step
angG ????? mais ce n'est pas souhaitable..
2) Même si je modifie l'entrée de la boucle, la conditionnelle ne s'effectue
pas lorsque angdeb = 360 ??????. Il faudrait que je modifie int(angdeb)
malheureusement je perds de la précision pour les autres valeurs
3) Si je passe tous les types Double en Single cela fonctionne mais je perd
de la précision et ce n'est pas souhaitable
Une petite explication serait souhaitable et comment résoudre ce
problème?????
"TouTi" <gelapplication[nospam]@tiscali.fr> a écrit dans le message de news:43ec9375$0$21291$
> For i = 0 To 14 > angdeb = angG * i > MsgBox angdeb & "/" & i > If angdeb = 360 Then MsgBox "toto" > Next i
Oui c'est d'accord
mais je ne peux pas utiliser cette méthode
Hello Touti,
il y a 2 ou 3 choses à savoir sur les types non entiers.
1/ Ne jamais utiliser une variable ayant un type flottant (double, single, etc) comme indice de boucle 2/ ne jamais tester d'égalité mais toujours des inégalités
Si on ne respecte pas ces règles, et bien ma foi, les programmes peuvent marcher ou non, donner les résultats attendus ou non, calculer juste ou non, etc. Bienvenue alors dans le monde de l'incertitude, de l'à peu près et des comportements innatendus. Avec en plus des choses amusantes liées à la représentation interne des types double ou singles :-))
Mais comme dit un célèbre humoriste "M'enfin, c'est vous qui voyez..."
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
"TouTi" <gelapplication[nospam]@tiscali.fr> a écrit dans le message de
news:43ec9375$0$21291$8fcfb975@news.wanadoo.fr...
> For i = 0 To 14
> angdeb = angG * i
> MsgBox angdeb & "/" & i
> If angdeb = 360 Then MsgBox "toto"
> Next i
Oui c'est d'accord
mais je ne peux pas utiliser cette méthode
Hello Touti,
il y a 2 ou 3 choses à savoir sur les types non entiers.
1/ Ne jamais utiliser une variable ayant un type flottant
(double, single, etc) comme indice de boucle
2/ ne jamais tester d'égalité mais toujours des inégalités
Si on ne respecte pas ces règles, et bien ma foi, les
programmes peuvent marcher ou non, donner les résultats
attendus ou non, calculer juste ou non, etc.
Bienvenue alors dans le monde de l'incertitude, de l'à peu
près et des comportements innatendus. Avec en plus des
choses amusantes liées à la représentation interne des types
double ou singles :-))
Mais comme dit un célèbre humoriste "M'enfin, c'est vous qui voyez..."
--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
"TouTi" <gelapplication[nospam]@tiscali.fr> a écrit dans le message de news:43ec9375$0$21291$
> For i = 0 To 14 > angdeb = angG * i > MsgBox angdeb & "/" & i > If angdeb = 360 Then MsgBox "toto" > Next i
Oui c'est d'accord
mais je ne peux pas utiliser cette méthode
Hello Touti,
il y a 2 ou 3 choses à savoir sur les types non entiers.
1/ Ne jamais utiliser une variable ayant un type flottant (double, single, etc) comme indice de boucle 2/ ne jamais tester d'égalité mais toujours des inégalités
Si on ne respecte pas ces règles, et bien ma foi, les programmes peuvent marcher ou non, donner les résultats attendus ou non, calculer juste ou non, etc. Bienvenue alors dans le monde de l'incertitude, de l'à peu près et des comportements innatendus. Avec en plus des choses amusantes liées à la représentation interne des types double ou singles :-))
Mais comme dit un célèbre humoriste "M'enfin, c'est vous qui voyez..."
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
Aski
Salutatoi Jean-Marc,
Tu as donc déclaré :
Hello Touti,
il y a 2 ou 3 choses à savoir sur les types non entiers.
1/ Ne jamais utiliser une variable ayant un type flottant (double, single, etc) comme indice de boucle
C'est ce que je pensais, d'où l'intérêt d'un Do Loop. Par contre la'ide en ligne ne le spécifie pas.
Salutatoi Jean-Marc,
Tu as donc déclaré :
Hello Touti,
il y a 2 ou 3 choses à savoir sur les types non entiers.
1/ Ne jamais utiliser une variable ayant un type flottant
(double, single, etc) comme indice de boucle
C'est ce que je pensais, d'où l'intérêt d'un Do Loop.
Par contre la'ide en ligne ne le spécifie pas.
il y a 2 ou 3 choses à savoir sur les types non entiers.
1/ Ne jamais utiliser une variable ayant un type flottant (double, single, etc) comme indice de boucle
C'est ce que je pensais, d'où l'intérêt d'un Do Loop. Par contre la'ide en ligne ne le spécifie pas.
Jean-Marc
"Aski" a écrit dans le message de news:%
Salutatoi Jean-Marc,
Tu as donc déclaré :
> Hello Touti, > > il y a 2 ou 3 choses à savoir sur les types non entiers. > > 1/ Ne jamais utiliser une variable ayant un type flottant > (double, single, etc) comme indice de boucle
C'est ce que je pensais, d'où l'intérêt d'un Do Loop. Par contre la'ide en ligne ne le spécifie pas.
C'est clair. Il s'agit la plus d'une règle de bon usage du langage (et même de bonne pratique de programmation) que d'une limitation du langage. Il a plein d'exemples de ce type. Un manuel technique du langage ne donne pas de conseils de programmation, il se borne à décrire ce qui existe et ce qui est permis (c'est à dire syntaxiquement correct).
Dans le même style, il n'est pas obligatoire de mettre Option Explicit. On peut donc coder comme un barbare,sans déclarations, sans types, etc. On peut aussi mettre des goto partout, utiliser des globales, mélanger les booléens et les entiers, faire des fonctions à points de sortie multiples, utiliser exit for et exit do à tout bout de champ, mettre des on error resume next partout, utiliser le type currency, donner aux variables des noms tels que "a", "tr", "bq" ou "k", hard coder les chemins de fichiers, mettre les constantes en dur dans le code, mettre le code fonctionnel dans l'interface graphique, écrire 14 for imbriqués, faire des Next sans écrire la variable du For! Toutes ces choses sont permises!
Bien sur, faire ces choses est l'équivalent de se jeter d'un avion sans parachute. Ce n'est pas explicitement interdit si on fait ça dans un lieu bien désert, mais je ne suis pas persuadé que ce soit une bonne idée pour autant!
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
"Aski" <aski@asci.asc> a écrit dans le message de
news:%238hOQAnLGHA.2912@tk2msftngp13.phx.gbl...
Salutatoi Jean-Marc,
Tu as donc déclaré :
> Hello Touti,
>
> il y a 2 ou 3 choses à savoir sur les types non entiers.
>
> 1/ Ne jamais utiliser une variable ayant un type flottant
> (double, single, etc) comme indice de boucle
C'est ce que je pensais, d'où l'intérêt d'un Do Loop.
Par contre la'ide en ligne ne le spécifie pas.
C'est clair. Il s'agit la plus d'une règle de bon usage du langage (et
même de bonne pratique de programmation) que d'une limitation du
langage. Il a plein d'exemples de ce type. Un manuel technique du
langage ne donne pas de conseils de programmation, il se borne à
décrire ce qui existe et ce qui est permis (c'est à dire syntaxiquement
correct).
Dans le même style, il n'est pas obligatoire de mettre Option Explicit.
On peut donc coder comme un barbare,sans déclarations, sans types, etc.
On peut aussi mettre des goto partout, utiliser des globales, mélanger
les booléens et les entiers, faire des fonctions à points de sortie
multiples, utiliser exit for et exit do à tout bout de champ, mettre
des on error resume next partout, utiliser le type currency, donner aux
variables des noms tels que "a", "tr", "bq" ou "k", hard coder les
chemins de fichiers, mettre les constantes en dur dans le code, mettre
le code fonctionnel dans l'interface graphique, écrire 14 for
imbriqués, faire des Next sans écrire la variable du For! Toutes ces
choses sont permises!
Bien sur, faire ces choses est l'équivalent de se jeter d'un avion sans
parachute. Ce n'est pas explicitement interdit si on fait ça dans un
lieu bien désert, mais je ne suis pas persuadé que ce soit une bonne
idée pour autant!
--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
> Hello Touti, > > il y a 2 ou 3 choses à savoir sur les types non entiers. > > 1/ Ne jamais utiliser une variable ayant un type flottant > (double, single, etc) comme indice de boucle
C'est ce que je pensais, d'où l'intérêt d'un Do Loop. Par contre la'ide en ligne ne le spécifie pas.
C'est clair. Il s'agit la plus d'une règle de bon usage du langage (et même de bonne pratique de programmation) que d'une limitation du langage. Il a plein d'exemples de ce type. Un manuel technique du langage ne donne pas de conseils de programmation, il se borne à décrire ce qui existe et ce qui est permis (c'est à dire syntaxiquement correct).
Dans le même style, il n'est pas obligatoire de mettre Option Explicit. On peut donc coder comme un barbare,sans déclarations, sans types, etc. On peut aussi mettre des goto partout, utiliser des globales, mélanger les booléens et les entiers, faire des fonctions à points de sortie multiples, utiliser exit for et exit do à tout bout de champ, mettre des on error resume next partout, utiliser le type currency, donner aux variables des noms tels que "a", "tr", "bq" ou "k", hard coder les chemins de fichiers, mettre les constantes en dur dans le code, mettre le code fonctionnel dans l'interface graphique, écrire 14 for imbriqués, faire des Next sans écrire la variable du For! Toutes ces choses sont permises!
Bien sur, faire ces choses est l'équivalent de se jeter d'un avion sans parachute. Ce n'est pas explicitement interdit si on fait ça dans un lieu bien désert, mais je ne suis pas persuadé que ce soit une bonne idée pour autant!
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
Aski
Salutatoi Jean-Marc,
Tu as donc déclaré :
C'est clair. Il s'agit la plus d'une règle de bon usage du langage (et même de bonne pratique de programmation) que d'une limitation du langage. Il a plein d'exemples de ce type. Un manuel technique du langage ne donne pas de conseils de programmation, il se borne à décrire ce qui existe et ce qui est permis (c'est à dire syntaxiquement correct).
Dans le même style, il n'est pas obligatoire de mettre Option Explicit. On peut donc coder comme un barbare,sans déclarations, sans types, etc. On peut aussi mettre des goto partout, utiliser des globales, mélanger les booléens et les entiers, faire des fonctions à points de sortie multiples, utiliser exit for et exit do à tout bout de champ, mettre des on error resume next partout, utiliser le type currency, donner aux variables des noms tels que "a", "tr", "bq" ou "k", hard coder les chemins de fichiers, mettre les constantes en dur dans le code, mettre le code fonctionnel dans l'interface graphique, écrire 14 for imbriqués, faire des Next sans écrire la variable du For! Toutes ces choses sont permises!
Bien sur, faire ces choses est l'équivalent de se jeter d'un avion sans parachute. Ce n'est pas explicitement interdit si on fait ça dans un lieu bien désert, mais je ne suis pas persuadé que ce soit une bonne idée pour autant!
Tout ceci me fait regretter le Turbo Pascal. C'était le bon temps. ;-)
Salutatoi Jean-Marc,
Tu as donc déclaré :
C'est clair. Il s'agit la plus d'une règle de bon usage du langage
(et même de bonne pratique de programmation) que d'une
limitation du langage. Il a plein d'exemples de ce type. Un
manuel technique du langage ne donne pas de conseils de
programmation, il se borne à décrire ce qui existe et ce qui est
permis (c'est à dire syntaxiquement correct).
Dans le même style, il n'est pas obligatoire de mettre Option
Explicit. On peut donc coder comme un barbare,sans déclarations,
sans types, etc. On peut aussi mettre des goto partout, utiliser
des globales, mélanger les booléens et les entiers, faire des
fonctions à points de sortie multiples, utiliser exit for et exit
do à tout bout de champ, mettre des on error resume next partout,
utiliser le type currency, donner aux variables des noms tels que
"a", "tr", "bq" ou "k", hard coder les chemins de fichiers, mettre
les constantes en dur dans le code, mettre le code fonctionnel
dans l'interface graphique, écrire 14 for imbriqués, faire des
Next sans écrire la variable du For! Toutes ces choses sont permises!
Bien sur, faire ces choses est l'équivalent de se jeter d'un avion
sans parachute. Ce n'est pas explicitement interdit si on fait ça
dans un lieu bien désert, mais je ne suis pas persuadé que ce
soit une bonne idée pour autant!
Tout ceci me fait regretter le Turbo Pascal. C'était le bon temps. ;-)
C'est clair. Il s'agit la plus d'une règle de bon usage du langage (et même de bonne pratique de programmation) que d'une limitation du langage. Il a plein d'exemples de ce type. Un manuel technique du langage ne donne pas de conseils de programmation, il se borne à décrire ce qui existe et ce qui est permis (c'est à dire syntaxiquement correct).
Dans le même style, il n'est pas obligatoire de mettre Option Explicit. On peut donc coder comme un barbare,sans déclarations, sans types, etc. On peut aussi mettre des goto partout, utiliser des globales, mélanger les booléens et les entiers, faire des fonctions à points de sortie multiples, utiliser exit for et exit do à tout bout de champ, mettre des on error resume next partout, utiliser le type currency, donner aux variables des noms tels que "a", "tr", "bq" ou "k", hard coder les chemins de fichiers, mettre les constantes en dur dans le code, mettre le code fonctionnel dans l'interface graphique, écrire 14 for imbriqués, faire des Next sans écrire la variable du For! Toutes ces choses sont permises!
Bien sur, faire ces choses est l'équivalent de se jeter d'un avion sans parachute. Ce n'est pas explicitement interdit si on fait ça dans un lieu bien désert, mais je ne suis pas persuadé que ce soit une bonne idée pour autant!
Tout ceci me fait regretter le Turbo Pascal. C'était le bon temps. ;-)
Jean-Marc
"Aski" a écrit dans le message de news:%23xu%
Salutatoi Jean-Marc,
Tu as donc déclaré :
Tout ceci me fait regretter le Turbo Pascal. C'était le bon temps. ;-)
Conclusion: on peut programmer comme un goret, quel que soit le langage employé. On peut aussi programmer très proprement, même avec un langage qui n'aide pas. C'est une question d'état d'esprit. Je dis toujours: "Il n'y a *PAS* de mauvais langages. Il n'y a que de mauvais *programmeurs*". Un bon programmeur fera du code propre et lisible même en Assembleur, en Fortran ou en Cobol. Un mauvais produira des trucs mer*iques même avec des langages de haut niveau très structurés et structurants genre Java ou Ada.
VB est plus ou moins entre les 2, plutot un lanage de haut niveau avec quelques faiblesses structurelles. Il est à peu près aussi facile d'écrire proprement que salement. Question de goût, de discipline, de culture, d'état d'esprit, etc.
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
"Aski" <aski@asci.asc> a écrit dans le message de
news:%23xu%23TdnLGHA.1676@TK2MSFTNGP09.phx.gbl...
Salutatoi Jean-Marc,
Tu as donc déclaré :
Tout ceci me fait regretter le Turbo Pascal. C'était le bon temps. ;-)
Conclusion: on peut programmer comme un goret, quel que soit
le langage employé. On peut aussi programmer très proprement,
même avec un langage qui n'aide pas. C'est une question d'état
d'esprit. Je dis toujours:
"Il n'y a *PAS* de mauvais langages. Il n'y a que de mauvais
*programmeurs*". Un bon programmeur fera du code propre et
lisible même en Assembleur, en Fortran ou en Cobol. Un mauvais
produira des trucs mer*iques même avec des langages de haut
niveau très structurés et structurants genre Java ou Ada.
VB est plus ou moins entre les 2, plutot un lanage de haut niveau
avec quelques faiblesses structurelles. Il est à peu près aussi
facile d'écrire proprement que salement. Question de goût, de
discipline, de culture, d'état d'esprit, etc.
--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
Tout ceci me fait regretter le Turbo Pascal. C'était le bon temps. ;-)
Conclusion: on peut programmer comme un goret, quel que soit le langage employé. On peut aussi programmer très proprement, même avec un langage qui n'aide pas. C'est une question d'état d'esprit. Je dis toujours: "Il n'y a *PAS* de mauvais langages. Il n'y a que de mauvais *programmeurs*". Un bon programmeur fera du code propre et lisible même en Assembleur, en Fortran ou en Cobol. Un mauvais produira des trucs mer*iques même avec des langages de haut niveau très structurés et structurants genre Java ou Ada.
VB est plus ou moins entre les 2, plutot un lanage de haut niveau avec quelques faiblesses structurelles. Il est à peu près aussi facile d'écrire proprement que salement. Question de goût, de discipline, de culture, d'état d'esprit, etc.
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
TouTi
> il y a 2 ou 3 choses à savoir sur les types non entiers. 1/ Ne jamais utiliser une variable ayant un type flottant (double, single, etc) comme indice de boucle 2/ ne jamais tester d'égalité mais toujours des inégalités
Et oui.... c'est ce que j'ai pu déterminé après mes essais de code.
C'est en codant et en vérifiant ce que l'on fait, que l'on apprend le plus...
-- Guy
> il y a 2 ou 3 choses à savoir sur les types non entiers.
1/ Ne jamais utiliser une variable ayant un type flottant
(double, single, etc) comme indice de boucle
2/ ne jamais tester d'égalité mais toujours des inégalités
Et oui.... c'est ce que j'ai pu déterminé après mes essais de code.
C'est en codant et en vérifiant ce que l'on fait, que l'on apprend le
plus...
> il y a 2 ou 3 choses à savoir sur les types non entiers. 1/ Ne jamais utiliser une variable ayant un type flottant (double, single, etc) comme indice de boucle 2/ ne jamais tester d'égalité mais toujours des inégalités
Et oui.... c'est ce que j'ai pu déterminé après mes essais de code.
C'est en codant et en vérifiant ce que l'on fait, que l'on apprend le plus...
