À partir du moment où deux nombres consécutifs de la suite égalent 2,
tous les suivants sont égaux à 2 :
2003 - 6002 /2 + 4000 / (2*2) = 2.
Bonne journée,
Serge
À partir du moment où deux nombres consécutifs de la suite égalent 2,
tous les suivants sont égaux à 2 :
2003 - 6002 /2 + 4000 / (2*2) = 2.
Bonne journée,
Serge
À partir du moment où deux nombres consécutifs de la suite égalent 2,
tous les suivants sont égaux à 2 :
2003 - 6002 /2 + 4000 / (2*2) = 2.
Bonne journée,
Serge
Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
"bcar" a écrit dans le message de news: isnou5$jjf$Bonjour
Tout simplement parce que tu utilise des double
Je t'invite à découvrir la représentation numérique d'un nombre à
virgule flottante
http://fr.wikipedia.org/wiki/Virgule_flottante
Pour faire simple dans ton exemple, tu utilise 5/3
or 5/3 = 1.6666666666666666....
or ton type double va le stocker 1.66666666666667
donc tes calculs vont dévier très légèrement au fur et à mesure.
C'est donc ton algorithme qui ne convient pas.
Pour diminuer l'erreur ou la retarder tu pourrais déjà utiliser le type
Decimal (avec le type variant et la fonction CDec)
Je n'ai pas fais le calcul excat mais qu'est-ce qui te fais croire que
u(19) = 1,999998093.
j'ai plutôt l'impression (intuitivement et en calculant les premiers
termes) que ta suite va effectivement converger vers 2000.
bcar
Le 08/06/2011 13:04, Tatanka a écrit :Mais, quelle est l'utilité de la boucle?
Un simple exemple de calcul itératif qui
mène à un résultat absurde. J'obtiens aussi 2000 sous Excel 2010
alors que le bon résultat est 1,999998093.
Grosse erreur, n'est-il pas ?
Serge
"Jacquouille" a écrit dans le message de news: 4def53d4$0$14257$Bonjour:
Il me donne également 2000 avec 2003.
Mais, quelle est l'utilité de la boucle?
Jacquouille
" Le vin est au repas ce que le parfum est à la femme."
"Tatanka" a écrit dans le message de groupe de discussion : isniei$el6$
Bonjour Messieurs Dames,
Sous Excel 2010, cette macro me donne 2000 pour u(19) :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
Obtenez-vous le même résultat avec d'autres versions d'Excel ?
Merci de me le faire savoir,
Serge
Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
"bcar" <bcar44@laposte.net> a écrit dans le message de news: isnou5$jjf$1@writer.imaginet.fr...
Bonjour
Tout simplement parce que tu utilise des double
Je t'invite à découvrir la représentation numérique d'un nombre à
virgule flottante
http://fr.wikipedia.org/wiki/Virgule_flottante
Pour faire simple dans ton exemple, tu utilise 5/3
or 5/3 = 1.6666666666666666....
or ton type double va le stocker 1.66666666666667
donc tes calculs vont dévier très légèrement au fur et à mesure.
C'est donc ton algorithme qui ne convient pas.
Pour diminuer l'erreur ou la retarder tu pourrais déjà utiliser le type
Decimal (avec le type variant et la fonction CDec)
Je n'ai pas fais le calcul excat mais qu'est-ce qui te fais croire que
u(19) = 1,999998093.
j'ai plutôt l'impression (intuitivement et en calculant les premiers
termes) que ta suite va effectivement converger vers 2000.
bcar
Le 08/06/2011 13:04, Tatanka a écrit :
Mais, quelle est l'utilité de la boucle?
Un simple exemple de calcul itératif qui
mène à un résultat absurde. J'obtiens aussi 2000 sous Excel 2010
alors que le bon résultat est 1,999998093.
Grosse erreur, n'est-il pas ?
Serge
"Jacquouille" <j.thiernesse@skynet.be> a écrit dans le message de news: 4def53d4$0$14257$ba620e4c@news.skynet.be...
Bonjour:
Il me donne également 2000 avec 2003.
Mais, quelle est l'utilité de la boucle?
Jacquouille
" Le vin est au repas ce que le parfum est à la femme."
"Tatanka" a écrit dans le message de groupe de discussion : isniei$el6$1@speranza.aioe.org...
Bonjour Messieurs Dames,
Sous Excel 2010, cette macro me donne 2000 pour u(19) :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
Obtenez-vous le même résultat avec d'autres versions d'Excel ?
Merci de me le faire savoir,
Serge
Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
"bcar" a écrit dans le message de news: isnou5$jjf$Bonjour
Tout simplement parce que tu utilise des double
Je t'invite à découvrir la représentation numérique d'un nombre à
virgule flottante
http://fr.wikipedia.org/wiki/Virgule_flottante
Pour faire simple dans ton exemple, tu utilise 5/3
or 5/3 = 1.6666666666666666....
or ton type double va le stocker 1.66666666666667
donc tes calculs vont dévier très légèrement au fur et à mesure.
C'est donc ton algorithme qui ne convient pas.
Pour diminuer l'erreur ou la retarder tu pourrais déjà utiliser le type
Decimal (avec le type variant et la fonction CDec)
Je n'ai pas fais le calcul excat mais qu'est-ce qui te fais croire que
u(19) = 1,999998093.
j'ai plutôt l'impression (intuitivement et en calculant les premiers
termes) que ta suite va effectivement converger vers 2000.
bcar
Le 08/06/2011 13:04, Tatanka a écrit :Mais, quelle est l'utilité de la boucle?
Un simple exemple de calcul itératif qui
mène à un résultat absurde. J'obtiens aussi 2000 sous Excel 2010
alors que le bon résultat est 1,999998093.
Grosse erreur, n'est-il pas ?
Serge
"Jacquouille" a écrit dans le message de news: 4def53d4$0$14257$Bonjour:
Il me donne également 2000 avec 2003.
Mais, quelle est l'utilité de la boucle?
Jacquouille
" Le vin est au repas ce que le parfum est à la femme."
"Tatanka" a écrit dans le message de groupe de discussion : isniei$el6$
Bonjour Messieurs Dames,
Sous Excel 2010, cette macro me donne 2000 pour u(19) :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
Obtenez-vous le même résultat avec d'autres versions d'Excel ?
Merci de me le faire savoir,
Serge
Bonjour,
on peut dire pareil pour 2000
2003-3,001+0,001 00
Michel
"Tatanka" a écrit dans le message de news: isns69$8t6$À partir du moment où deux nombres consécutifs de la suite égalent 2,
tous les suivants sont égaux à 2 :
2003 - 6002 /2 + 4000 / (2*2) = 2.
Bonne journée,
Serge
Bonjour,
on peut dire pareil pour 2000
2003-3,001+0,001 00
Michel
"Tatanka" <ramanujan@videotron.ca> a écrit dans le message de news: isns69$8t6$1@speranza.aioe.org...
À partir du moment où deux nombres consécutifs de la suite égalent 2,
tous les suivants sont égaux à 2 :
2003 - 6002 /2 + 4000 / (2*2) = 2.
Bonne journée,
Serge
Bonjour,
on peut dire pareil pour 2000
2003-3,001+0,001 00
Michel
"Tatanka" a écrit dans le message de news: isns69$8t6$À partir du moment où deux nombres consécutifs de la suite égalent 2,
tous les suivants sont égaux à 2 :
2003 - 6002 /2 + 4000 / (2*2) = 2.
Bonne journée,
Serge
Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
algorithme.
Et pourtant tu l'as
si tu veux calculer le terme u(n), il te faut faire
u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et moins
sujet aux erreurs)
C'est un bon exemple pour te montrer que les erreurs d'approximation (du
à la numérisation de tes fractions) peux entrainer des erreurs
conséquentes très rapidement.
Il faut donc trouver des algorithmes qui résistent à ce genre de problème
Tu découvrira peut être bientôt qu'en stockant tes résultats
intermédiaires tu peux obtenir des résultats différents (pendant les
calculs, les types utilisés par la machine peuvent différer des types
définis dans les calculs. Enfin le calcul numérique est plein de
joyeusetés de ce type.
bcar
Le 08/06/2011 14:38, Tatanka a écrit :Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
"bcar" a écrit dans le message de news: isnou5$jjf$Bonjour
Tout simplement parce que tu utilise des double
Je t'invite à découvrir la représentation numérique d'un nombre à
virgule flottante
http://fr.wikipedia.org/wiki/Virgule_flottante
Pour faire simple dans ton exemple, tu utilise 5/3
or 5/3 = 1.6666666666666666....
or ton type double va le stocker 1.66666666666667
donc tes calculs vont dévier très légèrement au fur et à mesure.
C'est donc ton algorithme qui ne convient pas.
Pour diminuer l'erreur ou la retarder tu pourrais déjà utiliser le type
Decimal (avec le type variant et la fonction CDec)
Je n'ai pas fais le calcul excat mais qu'est-ce qui te fais croire que
u(19) = 1,999998093.
j'ai plutôt l'impression (intuitivement et en calculant les premiers
termes) que ta suite va effectivement converger vers 2000.
bcar
Le 08/06/2011 13:04, Tatanka a écrit :Mais, quelle est l'utilité de la boucle?
Un simple exemple de calcul itératif qui
mène à un résultat absurde. J'obtiens aussi 2000 sous Excel 2010
alors que le bon résultat est 1,999998093.
Grosse erreur, n'est-il pas ?
Serge
"Jacquouille" a écrit dans le message de news: 4def53d4$0$14257$Bonjour:
Il me donne également 2000 avec 2003.
Mais, quelle est l'utilité de la boucle?
Jacquouille
" Le vin est au repas ce que le parfum est à la femme."
"Tatanka" a écrit dans le message de groupe de discussion : isniei$el6$
Bonjour Messieurs Dames,
Sous Excel 2010, cette macro me donne 2000 pour u(19) :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
Obtenez-vous le même résultat avec d'autres versions d'Excel ?
Merci de me le faire savoir,
Serge
Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
algorithme.
Et pourtant tu l'as
si tu veux calculer le terme u(n), il te faut faire
u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et moins
sujet aux erreurs)
C'est un bon exemple pour te montrer que les erreurs d'approximation (du
à la numérisation de tes fractions) peux entrainer des erreurs
conséquentes très rapidement.
Il faut donc trouver des algorithmes qui résistent à ce genre de problème
Tu découvrira peut être bientôt qu'en stockant tes résultats
intermédiaires tu peux obtenir des résultats différents (pendant les
calculs, les types utilisés par la machine peuvent différer des types
définis dans les calculs. Enfin le calcul numérique est plein de
joyeusetés de ce type.
bcar
Le 08/06/2011 14:38, Tatanka a écrit :
Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
"bcar" <bcar44@laposte.net> a écrit dans le message de news: isnou5$jjf$1@writer.imaginet.fr...
Bonjour
Tout simplement parce que tu utilise des double
Je t'invite à découvrir la représentation numérique d'un nombre à
virgule flottante
http://fr.wikipedia.org/wiki/Virgule_flottante
Pour faire simple dans ton exemple, tu utilise 5/3
or 5/3 = 1.6666666666666666....
or ton type double va le stocker 1.66666666666667
donc tes calculs vont dévier très légèrement au fur et à mesure.
C'est donc ton algorithme qui ne convient pas.
Pour diminuer l'erreur ou la retarder tu pourrais déjà utiliser le type
Decimal (avec le type variant et la fonction CDec)
Je n'ai pas fais le calcul excat mais qu'est-ce qui te fais croire que
u(19) = 1,999998093.
j'ai plutôt l'impression (intuitivement et en calculant les premiers
termes) que ta suite va effectivement converger vers 2000.
bcar
Le 08/06/2011 13:04, Tatanka a écrit :
Mais, quelle est l'utilité de la boucle?
Un simple exemple de calcul itératif qui
mène à un résultat absurde. J'obtiens aussi 2000 sous Excel 2010
alors que le bon résultat est 1,999998093.
Grosse erreur, n'est-il pas ?
Serge
"Jacquouille" <j.thiernesse@skynet.be> a écrit dans le message de news: 4def53d4$0$14257$ba620e4c@news.skynet.be...
Bonjour:
Il me donne également 2000 avec 2003.
Mais, quelle est l'utilité de la boucle?
Jacquouille
" Le vin est au repas ce que le parfum est à la femme."
"Tatanka" a écrit dans le message de groupe de discussion : isniei$el6$1@speranza.aioe.org...
Bonjour Messieurs Dames,
Sous Excel 2010, cette macro me donne 2000 pour u(19) :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
Obtenez-vous le même résultat avec d'autres versions d'Excel ?
Merci de me le faire savoir,
Serge
Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
algorithme.
Et pourtant tu l'as
si tu veux calculer le terme u(n), il te faut faire
u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et moins
sujet aux erreurs)
C'est un bon exemple pour te montrer que les erreurs d'approximation (du
à la numérisation de tes fractions) peux entrainer des erreurs
conséquentes très rapidement.
Il faut donc trouver des algorithmes qui résistent à ce genre de problème
Tu découvrira peut être bientôt qu'en stockant tes résultats
intermédiaires tu peux obtenir des résultats différents (pendant les
calculs, les types utilisés par la machine peuvent différer des types
définis dans les calculs. Enfin le calcul numérique est plein de
joyeusetés de ce type.
bcar
Le 08/06/2011 14:38, Tatanka a écrit :Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
"bcar" a écrit dans le message de news: isnou5$jjf$Bonjour
Tout simplement parce que tu utilise des double
Je t'invite à découvrir la représentation numérique d'un nombre à
virgule flottante
http://fr.wikipedia.org/wiki/Virgule_flottante
Pour faire simple dans ton exemple, tu utilise 5/3
or 5/3 = 1.6666666666666666....
or ton type double va le stocker 1.66666666666667
donc tes calculs vont dévier très légèrement au fur et à mesure.
C'est donc ton algorithme qui ne convient pas.
Pour diminuer l'erreur ou la retarder tu pourrais déjà utiliser le type
Decimal (avec le type variant et la fonction CDec)
Je n'ai pas fais le calcul excat mais qu'est-ce qui te fais croire que
u(19) = 1,999998093.
j'ai plutôt l'impression (intuitivement et en calculant les premiers
termes) que ta suite va effectivement converger vers 2000.
bcar
Le 08/06/2011 13:04, Tatanka a écrit :Mais, quelle est l'utilité de la boucle?
Un simple exemple de calcul itératif qui
mène à un résultat absurde. J'obtiens aussi 2000 sous Excel 2010
alors que le bon résultat est 1,999998093.
Grosse erreur, n'est-il pas ?
Serge
"Jacquouille" a écrit dans le message de news: 4def53d4$0$14257$Bonjour:
Il me donne également 2000 avec 2003.
Mais, quelle est l'utilité de la boucle?
Jacquouille
" Le vin est au repas ce que le parfum est à la femme."
"Tatanka" a écrit dans le message de groupe de discussion : isniei$el6$
Bonjour Messieurs Dames,
Sous Excel 2010, cette macro me donne 2000 pour u(19) :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
Obtenez-vous le même résultat avec d'autres versions d'Excel ?
Merci de me le faire savoir,
Serge
Formule plus élégante qui donne le même résultat que le mien et le bon.
Mais la question qu'on m'a posé(e?) était d'effectuer le calcul suivant :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
qui mène à une absurdité. Comment savoir à l'avance qu'il ne faut pas
se fier à certaines boucles ? Si je n'avais pas su que la réponse était fausse,
je n'aurais pas tenté de la chercher manuellement pour trouver un algorithme compétent !
A+
Serge
"bcar" a écrit dans le message de news: isnsoc$kjj$Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
algorithme.
Et pourtant tu l'as
si tu veux calculer le terme u(n), il te faut faire
u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et moins
sujet aux erreurs)
C'est un bon exemple pour te montrer que les erreurs d'approximation (du
à la numérisation de tes fractions) peux entrainer des erreurs
conséquentes très rapidement.
Il faut donc trouver des algorithmes qui résistent à ce genre de problème
Tu découvrira peut être bientôt qu'en stockant tes résultats
intermédiaires tu peux obtenir des résultats différents (pendant les
calculs, les types utilisés par la machine peuvent différer des types
définis dans les calculs. Enfin le calcul numérique est plein de
joyeusetés de ce type.
bcar
Le 08/06/2011 14:38, Tatanka a écrit :Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
Formule plus élégante qui donne le même résultat que le mien et le bon.
Mais la question qu'on m'a posé(e?) était d'effectuer le calcul suivant :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
qui mène à une absurdité. Comment savoir à l'avance qu'il ne faut pas
se fier à certaines boucles ? Si je n'avais pas su que la réponse était fausse,
je n'aurais pas tenté de la chercher manuellement pour trouver un algorithme compétent !
A+
Serge
"bcar" <bcar44@laposte.net> a écrit dans le message de news: isnsoc$kjj$1@writer.imaginet.fr...
Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
algorithme.
Et pourtant tu l'as
si tu veux calculer le terme u(n), il te faut faire
u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et moins
sujet aux erreurs)
C'est un bon exemple pour te montrer que les erreurs d'approximation (du
à la numérisation de tes fractions) peux entrainer des erreurs
conséquentes très rapidement.
Il faut donc trouver des algorithmes qui résistent à ce genre de problème
Tu découvrira peut être bientôt qu'en stockant tes résultats
intermédiaires tu peux obtenir des résultats différents (pendant les
calculs, les types utilisés par la machine peuvent différer des types
définis dans les calculs. Enfin le calcul numérique est plein de
joyeusetés de ce type.
bcar
Le 08/06/2011 14:38, Tatanka a écrit :
Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
Formule plus élégante qui donne le même résultat que le mien et le bon.
Mais la question qu'on m'a posé(e?) était d'effectuer le calcul suivant :
Sub Petit_Calcul()
Dim u(20) As Double
u(0) = 3 / 2
u(1) = 5 / 3
For n = 2 To 20
u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u(n - 2))
Next n
MsgBox u(19)
End Sub
qui mène à une absurdité. Comment savoir à l'avance qu'il ne faut pas
se fier à certaines boucles ? Si je n'avais pas su que la réponse était fausse,
je n'aurais pas tenté de la chercher manuellement pour trouver un algorithme compétent !
A+
Serge
"bcar" a écrit dans le message de news: isnsoc$kjj$Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
algorithme.
Et pourtant tu l'as
si tu veux calculer le terme u(n), il te faut faire
u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et moins
sujet aux erreurs)
C'est un bon exemple pour te montrer que les erreurs d'approximation (du
à la numérisation de tes fractions) peux entrainer des erreurs
conséquentes très rapidement.
Il faut donc trouver des algorithmes qui résistent à ce genre de problème
Tu découvrira peut être bientôt qu'en stockant tes résultats
intermédiaires tu peux obtenir des résultats différents (pendant les
calculs, les types utilisés par la machine peuvent différer des types
définis dans les calculs. Enfin le calcul numérique est plein de
joyeusetés de ce type.
bcar
Le 08/06/2011 14:38, Tatanka a écrit :Calcul exact :
u(0) = 3/2 = n(0)/d(0)
u(1) = 5/3 = n(1)/d(1)
u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/d(2)
u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3)/d(3)
u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n(4) /d(4)
....
J'en déduis que :
le numérateur n(i) = n(i-1) + 2^i
le dénominateur d(i) = n(i-1).
Ce qui me conduit à cette macro :
Sub Pas_Erreurs()
Dim n(20) As Double, d(20) As Double
Dim r As Double
n(1) = 5
d(1) = 3
For i = 2 To 19
n(i) = n(i - 1) + 2 ^ i
d(i) = n(i - 1)
Next i
r = n(19) / d(19)
MsgBox r
End Sub
Cette suite de nombre converge vers 2.
Serge
Je n'ai pas de réponse générale. il faut toujours se méfier quand on
manipule des nombres en informatique.
Peut être plus particulièrement quand :
- on s'approche des limites (très grand nombres positifs/négatifs)
- on enchaine les calculs approximés (cas de ta suite)
- on manipule des nombres avec beaucoup de décimales par rapport à la
précision du type utilisé.
Je t'encourage à regarder le premier lien que je t'ai donné pour
comprendre comment est formé un nombre "réel" en informatique
Cela te montrera que les types standards n'ont pas une précision
infinie, qu'il sont limités (max et min) et que toutes les valeurs entr e
ces bornes ne sont pas exprimables
bcar
Le 08/06/2011 16:17, Tatanka a écrit :
> Formule plus élégante qui donne le même résultat que le mien et le bon.
> Mais la question qu'on m'a posé(e?) était d'effectuer le calcul sui vant :
> Sub Petit_Calcul()
> Dim u(20) As Double
> u(0) = 3 / 2
> u(1) = 5 / 3
> For n = 2 To 20
> u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u( n - 2))
> Next n
> MsgBox u(19)
> End Sub
> qui mène à une absurdité. Comment savoir à l'avance qu'il ne fa ut pas
> se fier à certaines boucles ? Si je n'avais pas su que la réponse était fausse,
> je n'aurais pas tenté de la chercher manuellement pour trouver un alg orithme compétent !
> A+
> Serge
> "bcar" a écrit dans le message de news: isnsoc$k
>> Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
>> algorithme.
>> Et pourtant tu l'as
>> si tu veux calculer le terme u(n), il te faut faire
>> u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et mo ins
>> sujet aux erreurs)
>> C'est un bon exemple pour te montrer que les erreurs d'approximation ( du
>> à la numérisation de tes fractions) peux entrainer des erreurs
>> conséquentes très rapidement.
>> Il faut donc trouver des algorithmes qui résistent à ce genre de p roblème
>> Tu découvrira peut être bientôt qu'en stockant tes résultats
>> intermédiaires tu peux obtenir des résultats différents (pendant les
>> calculs, les types utilisés par la machine peuvent différer des ty pes
>> définis dans les calculs. Enfin le calcul numérique est plein de
>> joyeusetés de ce type.
>> bcar
>> Le 08/06/2011 14:38, Tatanka a écrit :
>>> Calcul exact :
>>> u(0) = 3/2 = n(0)/d(0)
>>> u(1) = 5/3 = n(1)/d(1)
>>> u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/ d(2)
>>> u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3) /d(3)
>>> u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n (4) /d(4)
>>> ....
>>> J'en déduis que :
>>> le numérateur n(i) = n(i-1) + 2^i
>>> le dénominateur d(i) = n(i-1).
>>> Ce qui me conduit à cette macro :
>>> Sub Pas_Erreurs()
>>> Dim n(20) As Double, d(20) As Double
>>> Dim r As Double
>>> n(1) = 5
>>> d(1) = 3
>>> For i = 2 To 19
>>> n(i) = n(i - 1) + 2 ^ i
>>> d(i) = n(i - 1)
>>> Next i
>>> r = n(19) / d(19)
>>> MsgBox r
>>> End Sub
>>> Cette suite de nombre converge vers 2.
>>> Serge- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Je n'ai pas de réponse générale. il faut toujours se méfier quand on
manipule des nombres en informatique.
Peut être plus particulièrement quand :
- on s'approche des limites (très grand nombres positifs/négatifs)
- on enchaine les calculs approximés (cas de ta suite)
- on manipule des nombres avec beaucoup de décimales par rapport à la
précision du type utilisé.
Je t'encourage à regarder le premier lien que je t'ai donné pour
comprendre comment est formé un nombre "réel" en informatique
Cela te montrera que les types standards n'ont pas une précision
infinie, qu'il sont limités (max et min) et que toutes les valeurs entr e
ces bornes ne sont pas exprimables
bcar
Le 08/06/2011 16:17, Tatanka a écrit :
> Formule plus élégante qui donne le même résultat que le mien et le bon.
> Mais la question qu'on m'a posé(e?) était d'effectuer le calcul sui vant :
> Sub Petit_Calcul()
> Dim u(20) As Double
> u(0) = 3 / 2
> u(1) = 5 / 3
> For n = 2 To 20
> u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u( n - 2))
> Next n
> MsgBox u(19)
> End Sub
> qui mène à une absurdité. Comment savoir à l'avance qu'il ne fa ut pas
> se fier à certaines boucles ? Si je n'avais pas su que la réponse était fausse,
> je n'aurais pas tenté de la chercher manuellement pour trouver un alg orithme compétent !
> A+
> Serge
> "bcar" <bca...@laposte.net> a écrit dans le message de news: isnsoc$k j...@writer.imaginet.fr...
>> Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
>> algorithme.
>> Et pourtant tu l'as
>> si tu veux calculer le terme u(n), il te faut faire
>> u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et mo ins
>> sujet aux erreurs)
>> C'est un bon exemple pour te montrer que les erreurs d'approximation ( du
>> à la numérisation de tes fractions) peux entrainer des erreurs
>> conséquentes très rapidement.
>> Il faut donc trouver des algorithmes qui résistent à ce genre de p roblème
>> Tu découvrira peut être bientôt qu'en stockant tes résultats
>> intermédiaires tu peux obtenir des résultats différents (pendant les
>> calculs, les types utilisés par la machine peuvent différer des ty pes
>> définis dans les calculs. Enfin le calcul numérique est plein de
>> joyeusetés de ce type.
>> bcar
>> Le 08/06/2011 14:38, Tatanka a écrit :
>>> Calcul exact :
>>> u(0) = 3/2 = n(0)/d(0)
>>> u(1) = 5/3 = n(1)/d(1)
>>> u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/ d(2)
>>> u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3) /d(3)
>>> u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n (4) /d(4)
>>> ....
>>> J'en déduis que :
>>> le numérateur n(i) = n(i-1) + 2^i
>>> le dénominateur d(i) = n(i-1).
>>> Ce qui me conduit à cette macro :
>>> Sub Pas_Erreurs()
>>> Dim n(20) As Double, d(20) As Double
>>> Dim r As Double
>>> n(1) = 5
>>> d(1) = 3
>>> For i = 2 To 19
>>> n(i) = n(i - 1) + 2 ^ i
>>> d(i) = n(i - 1)
>>> Next i
>>> r = n(19) / d(19)
>>> MsgBox r
>>> End Sub
>>> Cette suite de nombre converge vers 2.
>>> Serge- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Je n'ai pas de réponse générale. il faut toujours se méfier quand on
manipule des nombres en informatique.
Peut être plus particulièrement quand :
- on s'approche des limites (très grand nombres positifs/négatifs)
- on enchaine les calculs approximés (cas de ta suite)
- on manipule des nombres avec beaucoup de décimales par rapport à la
précision du type utilisé.
Je t'encourage à regarder le premier lien que je t'ai donné pour
comprendre comment est formé un nombre "réel" en informatique
Cela te montrera que les types standards n'ont pas une précision
infinie, qu'il sont limités (max et min) et que toutes les valeurs entr e
ces bornes ne sont pas exprimables
bcar
Le 08/06/2011 16:17, Tatanka a écrit :
> Formule plus élégante qui donne le même résultat que le mien et le bon.
> Mais la question qu'on m'a posé(e?) était d'effectuer le calcul sui vant :
> Sub Petit_Calcul()
> Dim u(20) As Double
> u(0) = 3 / 2
> u(1) = 5 / 3
> For n = 2 To 20
> u(n) = 2003 - 6002 / u(n - 1) + 4000 / (u(n - 1) * u( n - 2))
> Next n
> MsgBox u(19)
> End Sub
> qui mène à une absurdité. Comment savoir à l'avance qu'il ne fa ut pas
> se fier à certaines boucles ? Si je n'avais pas su que la réponse était fausse,
> je n'aurais pas tenté de la chercher manuellement pour trouver un alg orithme compétent !
> A+
> Serge
> "bcar" a écrit dans le message de news: isnsoc$k
>> Voilà, c'est exactement ce que je disais ;) tu n'utilise pas le bon
>> algorithme.
>> Et pourtant tu l'as
>> si tu veux calculer le terme u(n), il te faut faire
>> u(n) = ( 1 + 2^(n+1) ) / ( 1 + 2^n ) (plus simple, plus rapide et mo ins
>> sujet aux erreurs)
>> C'est un bon exemple pour te montrer que les erreurs d'approximation ( du
>> à la numérisation de tes fractions) peux entrainer des erreurs
>> conséquentes très rapidement.
>> Il faut donc trouver des algorithmes qui résistent à ce genre de p roblème
>> Tu découvrira peut être bientôt qu'en stockant tes résultats
>> intermédiaires tu peux obtenir des résultats différents (pendant les
>> calculs, les types utilisés par la machine peuvent différer des ty pes
>> définis dans les calculs. Enfin le calcul numérique est plein de
>> joyeusetés de ce type.
>> bcar
>> Le 08/06/2011 14:38, Tatanka a écrit :
>>> Calcul exact :
>>> u(0) = 3/2 = n(0)/d(0)
>>> u(1) = 5/3 = n(1)/d(1)
>>> u(2) = 2003 - 6002/(5/3) + 4000/(( 5/3)*(3/2)) = 9/5 = n(2)/ d(2)
>>> u(3) = 2003 - 6002/(9/5) + 4000/(( 9/5)*(5/3)) = 17/9 = n(3) /d(3)
>>> u(4) = 2003 - 6002/(17/9) + 4000/(( 17/9)*(9/5)) = 33/17 = n (4) /d(4)
>>> ....
>>> J'en déduis que :
>>> le numérateur n(i) = n(i-1) + 2^i
>>> le dénominateur d(i) = n(i-1).
>>> Ce qui me conduit à cette macro :
>>> Sub Pas_Erreurs()
>>> Dim n(20) As Double, d(20) As Double
>>> Dim r As Double
>>> n(1) = 5
>>> d(1) = 3
>>> For i = 2 To 19
>>> n(i) = n(i - 1) + 2 ^ i
>>> d(i) = n(i - 1)
>>> Next i
>>> r = n(19) / d(19)
>>> MsgBox r
>>> End Sub
>>> Cette suite de nombre converge vers 2.
>>> Serge- Masquer le texte des messages précédents -
- Afficher le texte des messages précédents -
