Lien entre boucle FOR et boucle WHILE

Le 08/10/2017 à 20:12

Bonsoir!

Je voudrais savoir si, avec un énoncé tel que :

Écrire le programme EXO_04 qui affiche dans les cellules A1 à A100 de la feuille 2 les nombres allant de 1 à 100.

Concrètement, la cellule A1 contient le nombre 1, la cellule A2 contient le nombre 2, …, la cellule A100 contient le nombre 100.

Est ce que entre utiliser :

SUB programme()

DIM ligne AS INTEGER

ligne = 1

WHILE ligne <= 100

SHEETS("Feuil2").CELLS(ligne,1) = ligne

ligne = ligne + 1

WEND

END SUB

ou :

SUB programme()

DIM ligne AS INTEGER

FOR ligne = 1 TO 100

SHEETS("Feuil2").CELLS(ligne,1) = ligne

NEXT ligne

END SUB

Est-ce que cela revient au même, autrement dit, les deux sont-ils corrects, on peut faire soit l'un soit l'autre ou c'est un seul des deux qui conviendra ici ?

Merci d'avance.

Le 08/10/2017 à 20:16

Hello,

Totalement idem ...

Le 08/10/2017 à 20:19

Merci

Mon prof nous a dit que dans ce cas c'est WHILE , du coup je voulais confirmer qu'on peut aussi passer par FOR

Bonne soirée!

Le 08/10/2017 à 20:23

De rien ...

Pour tout te dire tu rencontreras plus souvent la boucle For ... (une ligne à écrire dans le code .... )

Ce qui serait marrant ... c'est de chronométrer les deux macros ... et voir laquelle est la plus rapide ....

Le 09/10/2017 à 06:53

Bonjour

Le chrono dit 5.884765625 pour For Next contre 5.478515625 pour While Wend

Donc c'est la boucle Tant Que qui gagne

Par contre je voudrais revenir sur ce "que dit ton prof" !

Je ne suis pas du tout d'accord avec lui... Dans la théorie on utilise une boucle For Next lorsque l'on connait les limites à l'avance et une boucle TantQue (Whle Wend) quand il est impossible de prévoir ces mêmes limites !

L'exemple typique d'utilisation d'une boucle TantQue c'est la lecture d'un fichier -ou même d'un tableau- dont on ne connait quasiment jamais au moins la limite finale !

Le commentaire de James007 est cependant tout à fait correct, l'emploi de For Next est plus fréquent parce qu'il évite toujours le plantage par oubli de la ligne d'incrémentation (et ça arrive plus souvent qu'on le pense) dans ton exemple "ligne = ligne +1"

Je termine sur cette dernière réflexion, pour moi la vraie bonne réponse est : "ton prof à tort !"

Ou alors je suis curieux d'entendre son raisonnement, ou alors il ne programme pas depuis très longtemps

Le 09/10/2017 à 07:30

Bonjour à tous,

une boucle For Next lorsque l'on connait les limites

NCC 1701, je suis d'accord avec presque tout ce que tu as dit, sauf sur la boucle For Next

ou il y a la possibilité d'utiliser la propriété count et donc une limite non connue.

mais il existe aussi des prof qui pose les mauvaise questions...

Le 09/10/2017 à 07:58

Bonjour sabV

C'est vrai...

Mais je me vois mal lire un fichier avec une boucle ForNext

Comment veux-tu écrire cette boucle autrement ?

While Not Eof(1)
...
Wend

Le 09/10/2017 à 08:09

c'était concernant:

Dans la théorie on utilise une boucle For Next lorsque l'on connait les limites à l'avance

Édit -l'énoncer devrait être:

Dans la théorie on utilise une boucle For Next lorsque l'on connait les limites à l'avance ou lorsque l'on peut déterminer les limites à l'avance.

Le 09/10/2017 à 10:46

Coucou Isa ...

lorsque l'on connait les limites à l'avance

La quête de toute une Vie ...

Le 09/10/2017 à 13:09

(re)

James007 a écrit :

Coucou Isa ...lorsque l'on connait les limites à l'avanceLa quête de toute une Vie ...

Donc traduit en VBA cela donne

Sub Quete()
Dim limitesConnues As Boolean
Dim limitesInitiales, limitesFinales, limitesPasApas
Dim compteurLimite

    On Error GoTo erreurDeLimites

    limitesInitiales = "bases"
    limitesFinales = "inconnues"
    limitesConnues = False
    While Not limitesConnues
        limitesConnues = InputBox("Connaissez-vous vos limites?") = vbYes
        If limitesConnues Then

testerLesLimites:

            For compteurLimite = limitesInitiales To limitesFinales Step limitesPasApas
            Next
        Else
            limitesConnues = False
        End If
    Wend

erreurDeLimites:
    GoTo testerLesLimites

End Sub
Le 09/10/2017 à 13:30

Si toutes les macros du monde pouvaient seulement fonctionner ... de cette manière ... !!!

Le 09/10/2017 à 14:42

Bonjour à tous !

Intéressante discussion... J'ai pour ma part été un peu titillé par l'évaluation du temps d'exécution par NCC1701...

J'ai donc monté l'échantillon de proc. suivantes :

Sub TestFor()
    Dim i%, t!
    t = Timer
    With ActiveSheet
        For i = 1 To 100
            .Cells(i, 1) = i
        Next i
    End With
    MsgBox (Timer - t) * 1000
End Sub

Sub TestWhile()
    Dim i%, t!
    t = Timer
    With ActiveSheet
        While i < 100
            i = i + 1
            .Cells(i, 1) = i
        Wend
    End With
    MsgBox (Timer - t) * 1000
End Sub

Sub TestDo()
    Dim i%, t!
    t = Timer
    With ActiveSheet
        Do
            i = i + 1
            .Cells(i, 1) = i
        Loop While i < 100
    End With
    MsgBox (Timer - t) * 1000
End Sub

J'ai ajouté une boucle Do... Loop, n'utilisant jamais While... Wend (Microsoft l'a d'ailleurs explicitement remplacée par Do... Loop offrant plus de possibilités...)

Le temps est mesuré en millisecondes.

Sur 5 mesures par procédures, la valeur la plus fréquentes est 15,625 pour toutes. Il n'y a donc pas de différences significatives d'exécution (sous réserve de tests sur une boucle suffisamment longue...)

J'obtiens une valeur max. de 31,25 pour toutes les boucles également. J'ai aussi une valeur de 27,34375 pour Do... Loop et une de 11,71875 pour For... Next.

Pour aller un peu plus loin, j'ai testé une proc. utilisant un tableau :

Sub TestTbl()
    Dim tbl(1 To 100, 0) As Integer, i%, t!
    t = Timer
    For i = 1 To 100
        tbl(i, 0) = i
    Next i
    ActiveSheet.Range("A1:A100").Value = tbl
    MsgBox (Timer - t) * 1000
End Sub

Là, la valeur mesurée la plus fréquente est carrément : 0. Et une valeur de 15,625.

Ce qui confirmerait que l'utilisation de tableaux permet une exécution plus rapide.

Cordialement, et bonne journée.

Le 09/10/2017 à 19:20

(re)

Bonjour MFerrand

Le While Wend c'est une survivance... je suis d'accord avec toi... mais ayant débuté ma carrière avec le Pascal et l'algorithmique je n'arrive pas à me faire à l'utilisation de Do...Loop qui d'ailleurs à mon avis est plus proche du Repeat Until

Quant à l'utilisation des tableaux, là c'est indéniable, le travail exclusivement (ou le plus possible) en mémoire c'est la méthode la plus rapide et souvent la plus simple...

Le 10/10/2017 à 00:19

Re,

Mon trajet étant un peu différent, Do... Loop était déjà en service àla mise en place de VBA sur Excel 5, et je n'ai rencontré While... Wend que par la suite... Ce sont les ocnditions de sortie qui font la différence : 4 possibilités de programmer la sortie de boucle, plus une 5e avec Exit Do (celle-là, on en dispose aussi sur les boucles For avec Exit For).

Dans l'autre sens, je n'ai jamais pris l'habitude d'utiliser Byte comme type de données, il était exclu de cette version de VBA...

Bonne soirée.

Le 10/10/2017 à 07:32

Bonjour (..)

@MFerrand

Pour ma part et autant que possible, le Exit ou le Goto sont bannis de mes développements... Toujours une survivance (parfois c'est tenace)... le Exit et Goto étant anti-structurel (ils n'existent pas en algorithmique)...

Je n'ai rencontré le Exit qu'avec la gestion des erreurs sous VBA (souvent le moyen de sortir d'une procédure ou d'une function proprement)

Sauf dans le cas exceptionnel de ma démonstration quelques post plus haut dans ce fil, il n'y a jamais ni de Exit, ni de Goto dans mes sources... Il y a toujours un moyen de faire un programme lisse, qui se lit d'un seul tenant...

Lorsque je rencontre des sources contenant des Goto ou Exit je cherche d'abord à les supprimer avant de résoudre le problème lui même : en tournant les tests dans l'autre sens, en utilisant des conditions plus logiques... bref le Goto (en particulier lui) est pour moi une solution de facilité pour se débarrasser (sans le traiter) d'un problème...

Et qui dit problème non traité dit problème non géré. Et qui dit problème non géré dit solution non trouvée. Et qui dit solution non trouvée dit solution qui plantera un jour. Et qui dit solution qui plantera un jour dit problème non traité. Et qui dit problème non traité dit problème non géré. Et qui dit...

Non pardon ça c'est de la récursivité !

Par ailleurs, le B de VBA veut bien dire BASIC qui autorisait (et abusait) le Goto mais nous sommes d'accord que VBA est beaucoup plus proche d'un langage structuré que ne l'était le BASIC

Le 10/10/2017 à 23:31

On peut poursuivre ! Un peu hâché de mon côté, je viens de calculer que je changeais d'endroit alternativement tous les 4 jours environ depuis que je suis en métropole ! Pour l'instant il n'y en a que deux, c'est encore gérable...

Je te suis assez volontiers sur le GoTo, je ne sais si c'est pour les mêmes raisons... Cela m'évoque la programmation d'autrefois (que je n'ai pas pratiquée, donc sans nostalgie particulière). Mais en fait avec une programmation modulaire on fait quelque chose d'équivalent mais que je perçois comme plus léger et plus aérien...

Par contre, l'Exit... ! Pouvoir s'escamoter à tout moment me paraît une assez bonne chose si on le fait avec élégance Le problème des boucles, le plus souvent, c'est d'en sortir, au moment opportun autant que possible 8) et un Exit ne permet pas seulement de te sortir d'une situation qui deviendrait éventuellement gênante, tu peux sortir juste au moment où ta variable de boucle atteint une valeur permettant de la réutiliser dans la suite de l'opération en l'érigeant à un statut de meilleur aloi qu'une simple variable compteur... Bon ! Je m'envole !

La récursivité ! On va en trouver partout ! Il y en a peut-être partout ! Le problème que tu poses, c'est quand elle prolonge le problème au lieu d'aider à le résoudre...

Le 11/10/2017 à 11:58

Bonjour le fil

@MFerrand

Tout à fait d'accord avec ta dernière réflexion...

MFerrand a écrit :

Le problème que tu poses, c'est quand elle prolonge le problème au lieu d'aider à le résoudre...

effectivement dans ce cas là...

La récursivité contrairement à une idée reçue (sans doute parce que souvent mal expliquée, mal comprise) est beaucoup plus proche du raisonnement humain qu'on le pense.

La programmation structurée est plus une manière "facile" de discuter avec l'ordinateur en décrivant des actions dans un ordre logique et compréhensible par l'œil humain...

Cette question m'a été posée un jour :

"Ecrivez un programme qui permet de collecter en pièces de 1 Francs, la somme de 100 Francs"

Le raisonnement humain ne dit jamais Tant Que je n'ai pas 100 pièces de 1 Franc continuer à collecter" il dit plutôt "Collecter 1 Franc sauf si j'ai déjà 100 Francs" c'est une manière récursive de traiter le problème, pas de boucle d'une quelconque forme, juste un test de fin (un arrêt) toujours nécessaire pour savoir si la condition est réalisée

Ceci mis à part j'aimerais bien connaître l'explication du prof (du début du fil) sur son choix !

Le 15/10/2017 à 05:50

pas de boucle d'une quelconque forme, juste un test de fin (un arrêt) toujours nécessaire pour savoir si la condition est réalisée

heureusement il y a les événements....

Le 15/10/2017 à 11:49

Bonjour à tous,

Slimy4 doit être comblé ... puisque la boucle est bouclée ...

Rechercher des sujets similaires à "lien entre boucle while"