fonction rand : comment fonctionne-t-elle vraiment?

Qu'y as-t-il de "marrant" au cycle de de ax+b mod n, c'est juste une table de hachage non? (enfin, je ne suis plus sur du terme)

Ce que je trouve marrant est la propriété de la présence de toutes les possibilités durant un cycle.

J'en ri principalement parce que je fait le rapprochement avec ce que j'ai déjà remarqué comme quoi une table à plusieurs entrées formée à partir de cycles modulos sans coefficient génère toujours toutes les combinaisons sans répétition avec une période globale valant le produit des périodes, à condition que les périodes soient premières entre elles.
(on en a discuté autour du projet minecraft/herssahe (un des deux je ne sais plus) de persalteas sur tout82, mais je ne retrouve pas la discu)

Et puis je crois que les congruences sont simplement ma passion... alors j'en ri sans raison

si quelqu'un trouve cette algorythme, je suis interresser

mais comment on peut obtemir deux resultat different sans changer les variable avec le mem algo ????

Les algorithmes présentés dans l'article proposé par maxence sont des suites récurentes difficiles à prédire.
Donc le "x" change tout le temps.
Et on peut éventuellement utiliser un emplacement mémoire tel que l'horloge pour diversifier les initialisations.

les horloge sont uniquement sur les 83+

quel sont les variables qui change constamment au cous de l'utilisation des programme ou autre ?

La pile des boucles par exemple. Elle sert régulièrement.
Il doit y avoir aussi des pointeurs pour gérer la lecture des programmes.

Nous ne nous sommes pas compris concernant "l'horloge".
D'une part il y a le générateur de fréquence du timer qui cadence la machine, et d'autre part le décompte temporel qui permet de se repérer dans le temps comme l'horloge d'un ordinateur.
Or les timers utilisent souvent un diviseur de fréquence, et on peut alors utiliser les bits contenus dans ce diviseur pour initialiser de manière imprévisible.

L'horloge TI est dans les 84+, pas 83+ ! (est-ce un lapsus ?)

sinon, il y a le registre r de l'assembleur qui est incrémenté à chaque instruction et qui est assez aléatoire (souvant utilisé si dans un programe asm ne requiert qu'un seul aléatoire de 1 octet). Celà aurait donc pu servir à initialiser/influancer les nombres aléatoires (mais c'est pas le cas car suite à une même initialisation, la suite est toujours dentique.

Sandro

oui c'est une erreur je disais dans les 84+ cependant est il possible de reprogrammer la fonctions rand() en axe ou basic (le basic m'etonnerait)

?

asm c'est forcement possible

c'est surement possible (éventuellement remplaçant certaines instructions propres à l'assembleur par d'autres en axe/basic). Par contre pour ça il faut d'abbord l'algorithme, ce qu'on cherche justement.

Par contre en basic, ce serait une routine qui donne les même résultats, mais qui ne peut pas modifier rand mais une variable normale.

Sandro

Ces algorithmes ne sont pas initialisés a chaque fois qu'on execute la fonction correspondante, mais seulement lorsque l'on fait "unNombre->rand", c'est la fameuse graine, mais sinon le cycle se base sur les valeurs précédentes ou quelque chose du genre, sinon on ne retrouverais pas toujours les mêmes suites.

De plus je pense qu'il y a de forte chance qu'une variable spécifique a cette fonction existe...

je viens d'avoir une idee...

en cours de maths j'ai vue des suite "chaotique" qui avait des image complètement aléatoire les une par rapport au autre, aucun rapport entre elle, mais toute entre 0 et 1... l'algo se sert peut être de sa ?

Edit : premier message de la page 4 :D

oui, je crois que c'est directement rand. Sauf qu'on ne peut pas faire X -> rand en basic à la manière d'une variable classique.

Sinon, est-ce que quelcun aurrait une idée comment comparer la ram à 2 moments différents affin de repérer toute les différences, affin de localiser l'emplacement de la variable rand, comme ça on peut la modifier et tester les conséquences (par example avec 0)?

Merci d'avance
Sandro

Sandro, il est possible de faire X->rand en basic, c'est marqué dans les 1eres pages de ce topic.

Sauf que X->rand initialise d'une façon complètement différente d'une pure affectation.
En effet, 2->rand générera quelque chose entre 0 et 1, donc ce n'est pas une affectation directe.
affectation directe : y->x et x=y
initialisation indirecte : y->x provoque en réalité x=g(y)

Sandro, toi qui manipule régulièrement des débuggers tels que celui de wabbitemu, tu devrais être cappable de copier la mémoire avant puis après une action.

quelqu'un a remarquee mon message ou non ?

il est possible comme le disait matrefeytontias que sa soit fais avec la frequence de la ti

La plupart des machines se servent des aléas physiques de signaux électriques, mais pas les TI Z80 puisque les aléatoires sont générés par une fonction récurrente, et la graîne calculée à partir d'un nombre déterminé par l'utilisateur.

Sinon, avec les débugueurs assembleur, on peut effectivement le retrouver , mais 32 ko de ram à comparer à la main, c'est du travail, d'où la question si on ne peut pas le faire automatiquement.

Peut-être avec un programme en axe qui copie toute la ram système dans un programme, je vais voir si j'y arrive.

toute la ram systeme ? en fait desassembler une rom ?

Je crois que sandro veut parler de la partie de la ram réservée au fonctionnement du système.
Il ne faut pas confondre cela avec le système d'exploitation (os) qui est la partie executable software située dans la rom (au sens hardware du terme).

Il a déjà désassemblé un fragment d'os plus tôt dans ce sujet.

parceque vous croyer que la fonctions rand a un chemin bien specifique a elle dans les composant en electronuque pure ?

Presque.
Par exemple, seuls 28ko de la ram des ti82statfr est utilisable. Le reste est réservé aux variables de fonctionnement du système.
(et même une partie de la ram est physiquement innutilisable car ti a utilisé quelques composants de ti83plus dans la 82statfr !)
Je pense que rand est contenu dans la ram, mais pas à portée de main.
Je suis sceptique quant à la participation hardware dans la manipulation de rand.

Cependant peut-être que sandro veut réellement désassembler toute la mémoire, y compris l'OS.
Mais puisqu'il a déjà acquis un fragment d'os désassemblée, je ne pense pas que ce soit cela qu'il recherche actuellement.

Non, pour l'instant je cherche à trouver où dans la RAM est stoqué la variable rand affin de pouvoir sous émulateur modifier la valeur de rand (pas initialiser, mais biddouiller la valeur) afin de trouveer l'algorithme (par example ce qu'on optient avec 0, ou en augmentant de 10^-14, ça pourrait donner des indices.

Sandro

PS : je crois avoir réussit à récupérer la partie intéréssante en code héxa, mais j'ai pas le temps de regaarder et de faire une seconde capture aujourd'hui, je pense que ça devra attendre lundi

EDIT : j'ai testé les 3364 premiers octets de la ram : aucune modif.
Par contre, quelcun sait-il d'où à où va exactement la RAM système (par rapport à la ram, pas la mémoire complette de la TI)?

Merci d'avance
Sandro

où va exactement la RAM système (par rapport à la ram, pas la mémoire complette de la TI)?

C'est une questuion que je me pose également.

Je me suis toujours demandé quels endroits sur 65535 octets il vaut mieux pas trop bidouiller.

D'après le site sur lequel j'avais mit un lien, les PC n'utilisent ni fréquence, ni signaux électriques, alors une calculatrice encore moins !

PS: Vous vous doutez peut-être que je fait aussi un peu de C++, j'ai déjà réalisé un programme de tri de tableaux aléatoires, et je n'initialisais pas les rand, le résultat obtenue était toujours le même !

Il faut toujours initialiser une fonction aléatoire, on appelle ça le seed.

lien