fonction rand : comment fonctionne-t-elle vraiment?

@maxence :

D'après ce même site (dont tu as parlé), la fonction randomize() du C est composée de time(), qui utilise le temps en seconde de l'ordinateur.
Il semble donc que la méthode exploitant le bruit de phénomènes physiques ne soit pas utilisée par les ordinateurs, ainsi que tu nous le dit.

Cependant il est bien possible d'utiliser l'horloge, à la seconde près.
Et dans certains systèmes il est tout-à-fait possible d'utiliser des données d'un timer réglé à une fréquence de quelques mégahertz.
Là-dessus je suis sûr puisque j'ai déjà programmé un microcontrôleur et utilisé le timer pour contrôler un moteur par pwm.

J'ai déjà justifié que la calculatrice TI n'utilise ni aléa/bruit physique, ni le timer, mais par simple observation du fonctionnement, non par considération technologique.

Selon les dimensions de ton tableau, il est logique que tu obtiennes les mêmes résultats en C, si tu n'initialises pas de rand, car les résultats sont périodiques.

@kindermoumoute :

Je pense que ne pas "seed" un aléatoire n'est pas toujours un problème lorsque l'usage d'un programme ne tient pas compte des programmes executés précédemments.
Au contraire, je pense qu'une procédure indépendante executée sans connaître le reste est une source d'imprévision.

d'ailleurs, une précision que j'ai oublié : je cherche l'adresse sur ti83+ ou ti84+ ou ti84+SE (je peux pas exécuter l'axe parseur sur ma ti82stats.fr).

Merci d'avance
Sandro

Grâce à Prog2hex, j'ai déssassemblé ce programme Axe :

Code:

.ABC

rand

et j'ai trouvé ça :

Code:

call $9D99
ret
; $9D99 c'est ici
ld hl,axv_SpriteBuff
ld a,r
ld d,a
ld e,(hl)
add hl,de
ld e,a
add hl,de
ld (axv_SpriteBuff),hl
ret

Avec axv_SpriteBuff = $83CF

Je sais pas trop quelle conclusion en tirer ...

moi non plus, mais en tout cas ce n'est pas la routine de l'OS : elle ne fait pas intervenir r (sinon on n'aurait pas toujours la même suite).
Sinon, serait-il possible que sur le topic consacré, tu poste le code source de Prog2Hex, affin que je puisse m'en servir directement pour récupérer la rom (en remplaçant le programme par une simple adresse)?

Meric d'avance
Sandro

Je tiens pas à divulguer le code source, mais bon je te l'envoie par MP s'tu veux.

Quand je disais que les PC n'utilisaient pas de fréquances ou autres dans les aleatoires, c'etait pour demontrer le post de je ne sais plus qui qui avait dit qu'il les utilisai pour GENERER, mais en effet je ne contredis pas le fait qu'on puisse les utiliser pour initialiser les graines servant a ces algotithmes...

@ maxence

Je suis en meilleur accord avec toi, sachant cela.
Gardons cependant à l'esprit que toutes les observations mènent à penser que la TI n'utilise pas du tout d'aléa physique.

@ matrefeytontias

Je suis très intéressé par ta manipulation.
Je pense qu'on devrait demander à l'auteur d'Axe Parser si ce code provient entièrement de la calculatrice, ou de son compilateur, ou des deux.
En effet le compilateur ne génère pas forcément le même algorithme que celui utilisé par la calculatrice.
Sans compter que l'algo créé pourrait faire appel à un des composants de l'algo de la ti.

Le code de rand est quand même relativement petit, et il fait aucun appel à l'OS, donc y'a peu de chances qu'il soit officiel.

Pis c'est quoi le registre r ?

J'ai trouvé quelque chose de très intéressant dans l'include ti83.inc écrit par Brandon Wilson :
_Random equ 50B6h
_Storand equ 50BAh
_RandInit equ 50BEh
Ces trois adresses de romcalls permettent probablement de savoir exactement quelle partie de la rom est executée dans une ti82stat(fr)/83 lors des aléatoires.

D'autre part j'ai compris par hasard ce que voulais dire sandro avec son charabia décompilé de la rom.
[Vous devez être inscrit et connecté pour voir ce lien]
J'ai refait la mise en page.

Spoiler:

:O je ne comprend pas de suite mdr mais je vais bien lire

Je remonte ce topic que j'ai trouvé intéressant du temps de son activité auquel je peux apporter des éléments de réponse aujourd'hui. En effet je me suis renseigné à ce sujet et la TI utilise les congruences pour générer ses nombres aléatoires.

En effet on peut utiliser la formule [Vous devez être inscrit et connecté pour voir cette image]
Sachant que les constantes ont été définies par Texas Instruments. (a, c et m avec c optionnel et m très grand)

Sur le principe on prend la valeur précédente à laquelle on multiplie la constante a puis on ajoute c le tout modulo m, de cette manière on peut générer une suite qui semble aléatoire.

C'est pourquoi quand on initialise X₀ à x avec x nombre quelconque on obtiendra toujours les mêmes résultats, de plus cela n'a rien à voir avec la fréquence du processeur car si ça serait le cas on obtiendrait pas toujours les mêmes valeurs avec la même initialisation.

Par ailleurs méfiez-vous quant à l'utilisation de vos programmes en TI-BASIC, notamment de vos jeux utilisant l'aléa car il est possible d'initialiser cette suite avec des nombres de façon à prévoir ce qui est prévu dans le jeu.

Par exemple à l'aide d'un petit programme j'ai trouvé qu'en stockant 336 dans la variable rand on obtient 10 résultats supérieurs à 1/2 d’affilé:

Code:

336→rand
rand
.508419535
.5825808724
...(7 nombres > 1/2)
.9228237059
.3907501617

Soit dans un pile ou face (aléatoire entre 1 et 2 par exemple) on obtient 10 2 ou 10 1 d'affilé ! (Idéal pour épater vos potes sur vos talent de devin)

Bizarrement avec 663 on obtient 10 nombres inférieurs à 1/2 d'affilé, il y a sûrement un lien entre 336 et 663 et le fait d'obtenir 10 nombres inférieurs ou supérieurs à 1/2 mais je n'ai pas poussé plus loin... (336+663=999, la constante m serait donc dans les alentours de 1000 ???)

Enfin voilà, il faudrait donc trouver un algo permettant de contrer cette prévision potentiel des joueurs, ça vous dit d'essayer d'en trouver un ?
(Par exemple dans mon jeu HASARD de TI-BASIC+ il est très facile de cette manière d'obtenir que des + d'affilé et je pense que c'est le cas pour de nombreux programmes)

Il faudrait aussi trouver les constantes définies par TI pour pourquoi pas récréer l'algorithme utilisé ?

Plus d'infos sur la formule utilisée: [Vous devez être inscrit et connecté pour voir ce lien]

Cela est cohérent avec toutes nos observations.
Un des articles liés explique déjà le modulo linéaire en tant que méthode de pseudo-aléatoire, mais un résumé ne fait pas de mal.

Cependant personne n'avais mis en évidence que l'opération de la TI est bien un tel modulo. (qu'est-ce-qui t'en rend si sûr ?)
L'assembleur est suffisamment bas niveau pour qu'une opération de produit ne saute absoluement pas aux yeux.

Il est probable qu'un modulo 256 soit présent si le codage est naturel, car celui-ci se produit lors d'opérations sur les registres 8bits. (autrement dit on n'a pas de modulo à coder dans ce cas)

Cependant la graine du pseudo-aléatoire est difficile à déterminer, d'après la courbe que j'ai déjà modélisé.
C'est-à-dire que la graine probablement générée en binaire est déterminée de façon étrange à partir du nombre saisi en TI-Basic.

On ne sait à l'heure actuelle pas si la TI effectue ses calculs en binaire naturel ou en utilisant ses registres RAM (codage scientifique) et les romcalls qui vont avec.

Pas mal, pas mal

En ASM j'avais fait une anim' de feu utilisant l'aléatoire, et j'avais utilisé la routine rand de l'Axe, sans danger puisque non initialisable, mais renvoyant un nombre entier entre 0 et 65535. Au pire vous divisez le résultat par 65536 pour avoir un nombre entre 0 et 1 exclus. Ça vous intéresse ?

Cela peut servir, oui. La motivation était quand même de comprendre les routines de la TI.

Cependant diviser ton nombre par 65536 donnera 0 la plupart du temps si on reste dans les entiers.
Il faudra le faire en calcul scientifique. (cela m'égare)

ps: regarde mon message précédent, il a un peu changé

Nan ce que je voulais dire c'est que ma routine renvoie un entier, mais en basic vous pouvez le diviser en un nombre à virgule.