XL 2021 tirage au sort aléatoire sans doublon

Affiche 3,1µs chez moi.
100 fois plus pour remplir un tableau de long de 40*2 éléments ce n'est pas si déconnant, non ? Après tout s'il n'y a aucun échec les postes de la pile se dépilent aussi vites qu'ils s'étaient empilés. Mais bon, c'est vrai que c'est un peu étonnant …

oui c'est étonnant après ton algo il fait ce qu'il est sensé faire y a pas de soucis
c'est juste tes chronos qui sont incohérents, demain je fait sauter ton userform et je le remplace par un benchmarck avec celle là ou le module classe pour tester toutes les étapes j'aurais la réponse savoir quand le chrono s'arrête
là je suis crevé j'arrête un peu

Bonjour.
Ce classeur de test ne met en évidence aucune erreur d'affichage du temps par l'UFmVisu.

re Bonjour @Dranreb
oui de toute facon on utilise les mêmes api ça peut pas être différent
et là ton exercice montre bien que tes temps ne sont pas comptabilisés au bon moment dans listaleatoire
puisque ici
pour 500 j'ai eu au départ 999 puis 506 puis 504 puis 506
pour 1000 j'ai eu 1003 1001 1003 1003
c'est correcte donc on en revient a ce que je disais hier
touts ton attirail ne peut pas moins consommer que la simple ouverture du userform
surtout que le code continue de s’exécuter pendant le intialyse du userform puisque dans le initialyse il n'est pas encore modal ,donc même la on a pas vraiment une vraie lecture

petite parenthèse
ce matin avec chatGpt j'ai débattu du bien fondé de l'argumentation de l'ago fisher-yates
tous les tests montrent que soit disant le séquençage de sélection unilatéral avec rnd est faux dans la pratique
bon on parle de nano sec mais bon sur 50000 1000000 ca commence a se voir
mieux vaut utiliser rnd sur la totalité du tableau c'est moins couteux
et voir même biaiser en jouant sur un pivot mais ce n'est plus complétement du hasard même si on a le visuel qui dit le contraire

Oui, j'avais aussi constaté à la 1ère exécution des temps exagérés. Probablement dû à des mises en place de ressources par MSForms …
Comment ça pas au bon moment ? Tout pareil que dans ce classeur de test, au démarrage des TirageNvsNOK et autres TiragePostesOK et et avec UFmVisu.Conclure comme dernière instruction.

non pas dans celui là de test mais dans l'autre je ne sais plus comment te le dire
si ce test aujourd'hui est juste
celui de hier ne peut pas l'etre autant que le test de hier avec la pause
si une boucle sur 40 sans rien faire dedans fait 3.1µs chez toi tout ton barda ne peut pas faire que1.47µs
même si on prend en compte uniquement le boucles de l'algorytme
après j'ai cherché a part la 2d boucle M qui se déclenche jamais chez moi je vois pas
avec le benchmark et ma fonction je suis entre 150 et 190 µs ce qui est normal et plausible surtout
après ou ca coince la je sais pas c'est tellement imbriqué qu'il y a que toi pour trouver la couleuvre
après on a un depart et une arrivé c'est ca q'il faut tester un tableau de depart un tableau à l'arrivé
tester q'une partie n'a de sens que pour celui qui developpe l'ago le benchmark fait ça tres bien chaque ligne d'un code peut être testé

M c'est l'indice de la manche ou du tour si tu préfère.
Il n'y a pas de données de départ hormis le nombre de joueurs et de manches désirés passés en paramètres à la Function Tirage1vs1OK
Celle ci ne produit que le tableau résultant Public Tirage() As Long dimensionné dans la Tirage1vs1OK et garni par la Function RencTrouvée.
Les noms sont appliqués complètement en dehors du processus de tirage par la procédure exploitante d'après un tableau Excel des inscrits et selon les indices contenus dans le tableau Tirage.

Salut,
juste une remarque : l'important dans un tirage au sort , ce n'est pas la performance , c'est le caractère aléatoire du tirage. En général on ne fait qu'un tirage et sur peu d'éléments en sortie. Donc à quoi bon vouloir augmenter la performance, dans 95 % des cas en VBA, la réponse est limpide : la performance n’a quasiment aucune importance, et c’est bien la qualité du hasard qui compte.
Nullosse

Bonsoir @nullosse,
Le problème c'est que mes algorithmes de tirages récursifs ont de par leur conception une imprévisibilité fondamentale de leur durée d'exécution, avec croissance en forme de fonction Gamma du nombre d'opérations probables qu'ils pourraient être amenés à effectuer. Ça dépend de la proportion de solutions valides c'est à dire permise par les contraintes imposées au sein de l'ensemble des tirages susceptibles de se présenter. Si ces contraintes sont dures, contrairement au cas de la demande de cette discussion, la probabilité qu'il n'ait besoin que de quelques centaines de microsecondes est aussi faible mais pas moindre que celle où ils pourraient avoir besoin de plusieurs semaines si on ne les interrompait pas. Il est donc important qu'ils soient bien optimisés aux cas où ce nombre est par hasard exceptionnellement important tout en demeurant encore relativement raisonnable. Mais c'est sûr que pour 40 joueurs et seulement deux manches avec pour seule contrainte de ne pas se rencontrer deux fois, il ne doit probablement bloquer qu'assez rarement au dernier niveau récursif, demandant à l'avant dernier de fixer une autre paire lui permettant de finir avec les deux derniers autres restants qui, eux, ne se seront pas encore rencontrés lors de la 1ère manche.

(supprimé)