Vraisemblablement, vous avez des raisons de croire que l'algorithme de production de Guids ne produit pas de nombres vraiment aléatoires, mais qu'il tourne en fait avec une période << 2 ^ 128.
Par exemple, la méthode RFC4122 utilisée pour dériver des GUID qui fixe les valeurs de certains bits.
La preuve du cyclisme dépendra de la taille possible de la période.
Pour de petites périodes, la table de hachage de hachage (GUID) -> GUID avec remplacement lors d'une collision si les GUID ne correspondent pas (se terminent s'ils le font) peut être une approche. Pensez également à n'effectuer le remplacement qu'une fraction aléatoire du temps.
En fin de compte, si la période maximale entre les collisions est suffisamment grande (et n'est pas connue à l'avance), n'importe quelle méthode ne donnera qu'une probabilité que la collision soit trouvée si elle existait.
Notez que si la méthode de génération de Guids est basée sur l'horloge (voir la RFC), il peut ne pas être possible de déterminer si des collisions existent, car (a) vous ne pourrez pas attendre assez longtemps pour que l'horloge se termine, ou (b) vous ne pouvez pas demander suffisamment de Guids dans un tick d'horloge pour forcer une collision.
Vous pouvez également être en mesure d'afficher une relation statistique entre les bits du Guid ou une corrélation de bits entre les Guids. Une telle relation pourrait rendre hautement probable que l'algorithme est défectueux sans nécessairement pouvoir trouver une collision réelle.
Bien sûr, si vous voulez simplement prouver que les Guids peuvent entrer en collision, alors une preuve mathématique, pas un programme, est la réponse.