Fonction rand de TIGCCLIB - Page 1

Les derniers bits d'un générateur à congruence linéaire comme celui de TIGCCLIB sont les moins aléatoires, donc la meilleure méthode est de prendre les premiers bits, c'est-à-dire de faire un shift vers la droite par 13.
Quand tu prends le modulo par 7, tu utilises tous les bits (7 étant impair et même premier), donc c'est mieux que par 8 (ton andi #7), mais le mieux reste d'utiliser cet algorithme (qui se trouve d'ailleurs à l'intérieur de stdlib.h):
#define random(x) ((short)((long)(unsigned short)rand()*(unsigned short)(x)/32768))
ce qui pour une puissance de 2 revient à diviser par (32768/x) (parce que 32768/x est entier), ce qui revient donc à une division par une puissance par 2 et à la fin des comptes à un shift vers la droite.

D'ailleurs, Martial, ta solution utilisant divu a un petit bug Le résultat est compris entre 0 et 6. C'est une division par 8 qu'il faut pour obtenir un résultat compris entre 0 et 7.
Tu te retrouves alors exactement dans la situation de départ avec andi, mais en plus lent.

Oui mais ton andi donne un nombre entre 0 et 7 (soit 8 nombres, alors que tu n'en veux que 7). Ton divu donne un nombre entre 0 et 6 (soit 7 valeurs possibles, voilà pourquoi ça marche mieux).

C'est ça que je disais.

Il reste le fait qu'un:

mulu #7,%d0
swap %d0

donnerait probablement un résultat meilleur. Ça devrait aussi être plus rapide que le divu.

Plop,

Je cherche à obtenir un nombre variant de -8 à +8. J'utilise rand de tigcclib.
J'ai écrit ce code :

	bsr	rand
	mulu.w	#8+1+8,d0
	swap.w	d0
	moveq.l	#-8,d5			; -8 < height < 8
	add.w	d0,d5			; New offset

Manifestement, j'obtiens un nombre très souvent négatif, rarement positif. D'après les posts au-dessus, je pensais pourtant être dans les clous... Qu'est-ce qui ne va pas ?

C'est étrange ce mulu... Autant pour le divu je comprends le fonctionnement, autant là je ne vois pas la logique

En principe, ce mulu devrait marcher, mais rand n'est certainement pas un générateur de nombres aléatoires parfait (loin de là).

Mais comment ça fonctionne ? Pour divu le swap permet de récupèrer le reste de la division, dont la distribution est uniforme ou presque (vu que 2¹⁶ n'est pas divisible par 7 ou 17). Mais pour mulu ?

Zerosquare -> c'est pour récupérer les bits supérieurs (les "plus aléatoires" si j'ai bien compris) dans l'upper word.
Le problème est que à un bit près, ou ça tire trop en positif (vraiment trop), ou trop en négatif (...).

Oh attends, en fait rand() retourne un résultat 8 bits ? Je pensais que c'était sur 16 bits...

Si si, c'est sur 16 bits : http://tigcc.ticalc.org/doc/stdlib.html#rand

15 bits plutôt (plage 0 ~ 32767). Ah OK, j'ai pigé le principe je crois. Mais il faut multiplier par 34 (2 * 17) au lieu de 17, vu que le swap réalise une division entière par 2¹⁶, alors que la valeur maximale de rand est 2¹⁵ - 1.

Ok, on va tenter d'essayer. J'ai jamais été très à l'aise avec ces modulos de congruences de je ne sais quoi d'autre encore