random - Page 1

comment faire une fonction random en asm ??????????
paske en C ya rien a faire mais en asm aie aie aie je sais po je sis tres mauvais !!!!!
merci

regarde dans les sources de util ou de userlib, il y en a une, sinon, je peux en balancer l'idée générale ici.

je veux bien lidee generale si ca te derange pas !!!

MODULO est le mot clé de cette idée

si tu men disais un peu plus long ce serait pas plus mal paske modulo cest tres bo je peux faire plein de trucs avec mais je vois toujours pas !!!!!!

fouillage dans les papiers et solution :

hasard faible : bon mélange, uniformité, longue période, satisfaction des tests statistiques. Pour des algorithmes rapides.
hasard moyen : imprévisibilité pour un observateur ne disposant pas de moyens de calculs réalistes. Peut peut-être être produit par des algorithmes moyennement rapides.
hasard fort : imprévisibilité totale, incompressibilité, contenu maximal en information. Ne peut être produit par algorithme, mais vraissemblablement par des moyens physiques.

tests spectraux : hasard faible, utile pour les simulations.

principe général : x(n+1)=(a*x(n)+b) % M

On a souvent utilisé M=2^31, a=65539, b=0. Si on les graphe, on remarque une structure de réseau assez nette.

registre à décalage : hasard faible

on fixe un paramètre A=a4...a1
On créé une graine B=b4...b1

Puis on introduit B'=(parité de (a1b1+...+a4b4)b4...b2)
Le bit b1 est utilisé comme bit aléatoire.

Le procédé de L.Blum, M. Blum et M. Shub : hasard moyen - on espère -

soit n le produit de deux nombres entiers premiers de la forme 4m+3. On prend comme graine un nombre x sans facteur commun d'avec n et on calcule x(0)=x^2 % n.
Alors x(i)=x(i+1)^2 %n. La parité de x(i) donne la suite pseudo-aléatoire de bits de BBS.
Si leur hypothèse est vrai - trouver des racines carrées modulo n est un problème difficile -, alors la suite est imprévisible.

Utilisation plus poussée
On peut combiner les différentes solutions avec un XOR entre les bits des différentes suites.
On peut aussi uniformiser dans le cas d'un générateur déséquilibré en définissant 01 = 0 et 10 = 1. 00 et 11 sont supprimés.

Voilà. J'espère que ça répond à tes questions.

bsr rand

C'est tout ce qu'il faut pour un short aléatoire avec TIGCC 0.92 SP1.

Pour les autres fonctions:

randomize:
 clr.l randseed
 move.b $600017,randseed+3
 rts

random:
 bsr rand
 move.w 4(a7),d1
 mulu.w d1,d0
 add.l d0,d0
 clr.w d0
 swap d0
 rts

Ces fonctions font exactement ce qui est décrit dans la documentation de TIGCC. (Les deux dernières sont des macros dans TIGCCLIB. Je les ai convertis en fonctions.)

Qu'est ce que rand dans ta routine ?
Un avion des etats unis detourne dans ton cul ?

ouais rand on a pas le droit de lavoir????

rand est une fonction de tigcc.a. Si vous voulez ses sources, c'est dans les sources de TIGCC. Mais vous n'avez pas besoin des sources pour l'utiliser.

random:
move.l d1,-(a7)
move.w rand_seed(pc),d1
mulu.w #31421,d1
add.w #6927,d1
mulu.w d1,d0
move.w d1,rand_seed
clr.w d0
swap d0
move.l (a7)+,d1
RTS


rand_seed:
dc.w 0

je l'ai piqué dans les sources de userlib
je l'ai piqué car je voyais vraiment pas comment faire une routine pour retourner un nombre aleatoire
[edit]Edité par zilah le 24-11-2001 à 00:08:09[/edit]

Ouais, mais le seul problème est que si tu archives ton programme, ta série de nombres "aléatoires" sera tjs la même La meilleure méthode est celle de kevin je pense

sinon, avant d'effacer home, pkoi ne pas aller chercher 8px à un endroit de l'écran, dans l'historique, et les mettre dans rand_seed ?

si le prog est archivé, ça pourrait quand même faire un pseudo-générateur, vu que c rare d'avoir tjrs EXACTEMENT les mêmes calculs affichés

ouais j'y avais pensé

sinon regarder la memoire libre ..
C aussi rare d'avoir la meme qtté ...

>sBibi: sinon, avant d'effacer home, pkoi ne pas aller chercher 8px à un endroit de l'écran, dans l'historique, et les mettre dans rand_seed ?

Parce que quelqu'un qui travaille proprement efface systématiquement l'écran [HOME] quand il a fini quelque chose.

>Gandalf:
>sinon regarder la memoire libre ..
>C aussi rare d'avoir la meme qtté ...

Pas vraiment. Si on ne met pas de variables en RAM et qu'on a déjà installé tous les TSRs dès le début, ça ne change pas.


Et il y a aussi les problèmes de sécurité. Ces 2 variables se manipulent facilement. Dans des jeux, ça rend possible la triche. Dans des applications comme la cryptographie, c'est un vrai risque de sécurité.
[edit]Edité par Kevin Kofler le 24-11-2001 à 21:43:04[/edit]

bah...pourquoi ne pas déclencher un timer dès l'exécution du prog, l'arrêter quand l'utilisateur valide le choix où le rand a besoin d'être utilisé, et se servir de cette valeur pour commencer le random ??
par exemple dans un menu, à chaque boucle, incrémenter le compteur de 1, et quand l'utilisateur valide "atart", ben rand_seed = valeur_du_timer
c difficilement trichable ça

>Et il y a aussi les problèmes de sécurité. Ces 2 variables se manipulent facilement.
bah tant que tu y est, t'utilise un éditeur hexa, un décompilateur tant qu'à faire, et pis vala...

>Dans des jeux, ça rend possible la triche.
ça peut parfois être intéressant d'avoir accès à des cheat codes...
mais bon, ac ma méthode, c difficile de tricher

>Dans des applications comme la cryptographie, c'est un vrai risque de sécurité.
Dans ce cas, ça vaut le coup de faire un code + long, +complexe, + chiadé...
et vu qu'un prog, ça se décompile, à mon avis, c plutôt sur l'algo de cryptage que l'attention doit se porter...

oui, mais si tu fais du code auto-changeant, je te garanti que le gars qui décompile s'amuse !!!, surtout si le code qui se crée est en fonction d'un random, mais qui peut malgré tout bien marcher, je sais c balèze, mais j'aime bien en faire, quand je m'ennuye en cours.

et le fait d'avoir des possibilités de tricher, ça c pas mal, comme ça ça récompense les efforts du gers qui cherche pour justement trouver des astuces. mais en fait ça dépend de quel coté on se met {développeur/utilisateur}

Le problème pour la cryptographie est que si la clé est générée par un mauvais générateur de nombres aléatoires, l'attaqueur peut facilement regénérer ta clé! Mais en général, les programmes de cryptographie utilisent des méthodes de génération du style de celle de sBibi, fondées sur le temps de réaction de l'utilisateur (qui varie fortement), ce qui, si c'est fait correctement (pas avec un seul temps de réponse, mais plusieurs), est plus sûr que même un bon générateur purement pseudo-aléatoire.

RV>oui, le code auto-changeant c'est bien mais tu oublies qu'on parle de prog ARCHIVES, le code auto-changeant est valable si le prog n'est pas archivé. si il est archivé, les changements ne se feront que le temps de l'exécution du prog
bah bien sur dans le cas où un gars veut décompiler ta source, c'est sur qu'il va se faire chier à chercher qu'est-ce qui change à la 1ere exécution, kesque ça fé à la 2nde, etc etc... ça peut être un vrai casse tête, mais si tu te sers du code auto-changeant pour un générateur de nombres aléatoires, et que le prog est archivé, ça revient au même il me semble, que la méthode de userlib...

ra la la c'est tellement plus facile le random sur Hp....

fé by ZE hardware?

entre autres... Grosso modo trois methodes :

*La routine deja integree %RAN . Ca calcul un FLOAT aleatoire selon une formule xn+1 = (a*xn+b) mod c
a, b, c sont bien bien tordus, le germe est conserve par le systeme dans une adresse de la RAM prevue pour ca.. Je crois que meme un plantage total ou un reset n'efface pas le germe...
Mais bon, somme toute c'est de l'aleatoire faible (meme si c'est tres bon) et c'est couteux en temps.

*Lire l'horloge.
c'est toute con : une instruction. bien sur il suffit d'avoir une horloge

*Lire le CRC.
Il y a un circuit hard qui calcule le CRC de toutes les donnees circulant sur le bus, sur 2 octets.
Nickel si on veut qq chose de vraiment tres aleatoire

le dernier est bien, et mixé au second, ça ferait un truc rapide et sympathique

je t'assure que le dernier tout seul suffit largement!
Des que tu fais une lecture ou une ecriture en memoire, le CRC est entierement change selon une formule INCHIABLE!
Et si on reflechit bien, les interruptions, (qui se produisent, disons, de maniere assez "aleatoires" dans le temps, pression d'une touche par exemple), lisent et ecrivent en memoire...
lisent notamment l'HORLOGE...

bah ué, sur hp facile

mais là, on est sur ti...
dc marche pô

tien, ba je fé remonter ce vieu topic
je vien de penser à un truc, alors ke j'allais me coucher...
dc je l'écris ici, sinon je l'oublierai...
voici donc une autre alternative, à utiliser en mix avec certaines évoquées au dessus:

au début du prog: on cherche l'addr du début de la vat... on récup le deuxième word, tous les handles, qu'on déréférence un à un, puis on mixe tout ça, et on obtient un truc relativement aléatoire d'une calc à l'autre et surtt difficilement trafiquable.
et combiné à par exemple une récup du numéro de série de la calc, et un mélange avec le temps de réaction de l'utilisateur, ça pe faire un truc sympa

dans ce cas, si tu veux un truc infaillible, tu additionnes aussi ça :
lecture de tous les words en ram que tu additionnes entre eux. ça prend 2 secondes, et pendant ce temps tu laisses une jolie image affichée.
comme ça sur une vraie TI, t super emmerdé