Le sujet est super intéressant !
Premièrement, je tiens à féliciter Grabiller pour son code qui est vraiment lisible et propre. Malheureusement je n'ai pas installé les bêtas et j'attends avec impatience la release, donc je n'ai pas pu tester.
Une chose qui m'a sauté aux yeux : la différence entre un code 5.20 et 5.1x. L'utilisation des modules va changer pas mal de chose.
Ensuite par rapport à ce qu'on exprimé G-Rom et djes, c'est vrai que l'utilisation d'un générateur de nombre pseudo-aléatoire prend plus de temps machine puisque les calculs sont refaits.
Mais il me semble que l'utilisation des "seeds" permet justement d'accélérer le résultat et prend en compte le problème.
Le problème d'utiliser un tableau fixe de nombres aléatoires est que dans une application comme le ray-tracing de Grabiller, ça va finir par générer des aspects systématiques dans l'image.
Pour éviter ce problème il faudrait un tableau d'une dimension énorme, et qui est soigneusement calculée pour ne pas générer des interférences régulières sur les calculs.
en gros les rayons vont finir par toujours aller aux mêmes endroits et on aura des trous réguliers dans l'image.
Pour tester ton code, le principe est que chaque tirage ait autant de chance de tomber sur un nombre que sur n'importe quel autre, du coup tu testes avec un très grand nombre de tirage sur une zone donnée des entiers : par exemple entre 0 et 1000, puis tu comptes combien il y a de tirage qui sont tombés aux mêmes endroits.
Si le résultat est presque plat, c'est que c'est plutôt bien réparti.
Si ça s'accumule à un endroit (avec un grand nombre de tirage) alors il y a un petit soucis et la loi n'est pas uniforme.
Il doit y avoir des tests plus poussés mais ça c'est facile à implémenter et la représentation est rapide à visualiser. (c'est exactement le test de PAPIPP
)
Enfin ce genre de code est toujours intéressant, techniquement et mathématiquement.
)