FiftyMSecTick ? - Page 1

Bon je repose ma question ici...
Si j'ai bien compris, le code suivant (© Kevin) est censé marcher sous PedroM :

  unsigned long randnum=255-peekIO(0x600017);
  if (!AMS_1xx || *(unsigned short *)0x32==(('R'<<8)+'O'))
    randnum+=(*((volatile unsigned long*)(_rom_call_addr(4FC))))*((HW_VERSION == 2)?52:78);
  srand(randnum);

(pour initialiser le générateur aléatoire). Mais Nil me dit que PedroM lui dit « unsupported RomCall 0x4FC »

Tu compiles en mode kernel donc:

unsigned long randnum=255-peekIO(0x600017); if (!AMS_1xx || *(unsigned short *)0x32==(('R'<<8)+'O')) randnum+=(*((volatile unsigned long*)(pedrom_rom_call_addr(4FC))))*((HW_VERSION == 2)?52:78); srand(randnum);

Si tu utilises les headers fournis par PedroM

Très intelligent comme conseil ça. Comme ça son programme ne marchera plus que sous PedroM... Cf. l'autre topic pour une vraie solution.

Elle peut toujours recopier la macro proposee et l'adapter.

Cf. l'autre topic pour une vraie solution.

-> oui, utiliser un meilleur générateur aléatoire et ne pas perdre de la place à détecter le HW alors que ça ne sert strictement à rien...

Oh si que ça sert, surtout avec ton "meilleur générateur aléatoire".

rotfl !

Tout le monde se contrefiche de gagner 8 bits de seed avec 2 octets en plus, et tu crois que les 0.2 bits (sic!) que ta méthode fait gagner (avec > 20 octets en plus) vont révolutionner la génération des nombres aléatoires? Toujours aussi rigolotes, tes blagues

Je constate que tu fais vraiment de tout pour discréditer l'équipe de TIGCC. Ça va être beau, le futur, avec un concurrent malhonnête comme toi...

Oh, ça va les trolls, hein

Kevin>

Il ne s'agit ni de l'équipe TIGCC, ni de te discréditer. Je te fais juste remarquer que tu cherches midi à 14 heures et que tu mets en place des méthodes très coûteuses pour gagner un tout petit peu d'entropie en plus, alors qu'il y a des énormes défauts dans rand() qui font qu'avec une modification mineure on peut avoir un gain d'entropie 40x supérieur au gain d'entropie de ta méthode, pour un coût 10x inférieur. Et surtout, je ne vois pas pkoi tu mets un point d'honneur à vouloir garder à tout prix cette méthode coûteuse. Ce n'est vraiment pas la peine de s'obstiner là-dessus, et je te mets au défi de me montrer une méthode expérimentale vraiment efficace pour distinguer entre le seed avec 3km de détection du hardware et le seed obtenue de la manière triviale [un protocole simple serait de prendre n € [0,10000] inconnu par la fonction, de faire randomize() puis n appels de rand() puis passer en paramètre à l'algo de détection le résultat de 10000 appels de rand()].

Pour ce qui est des histoires de "concurrence", je dirais qu'on est dans le même bateau pour la lib (je n'ai aucune envie de faire une version modifiée de tigcclib), donc ça n'a rien à voir. Et si je voulais vraiment le mal de TIGCC, plutôt que de perdre mon temps à essayer de te convaincre (pardon, de te "discréditer" ), j'aurais plutôt fait la modification de rand() tout seul dans mon coin et comme ça non seulement les progs de GTC auraient été plus petits, mais en plus la génération de nombres aléatoires serait plus efficace. Alors ce que j'ai fait, comme moyen d'être "méchant" avec TIGCC, j'ai vu mieux


[EDIT : aussi, si tu pouvais m'expliquer le coup de la "malhonnêteté", ce serait sympa ]

Tu es malhonnête parce que tu t'obstines à donner des nombres fraudulents pour faire passer la seule méthode mathématiquement correcte pour une méthode inefficace. Ta méthode:
* n'est pas une distribution équiprobable.
* perd au moins 17% des valeurs possibles. Plus en général. Ton chiffre stupide "0,2 bits" ne veut rien dire, c'est le nombre de valeurs qui compte, pas le nombre de bits.
* Je veux bien améliorer rand quand l'amélioration de randomize (nettement plus urgente, parce que le randomize actuel est très mauvais) sera complète. Les 2 améliorations ne s'excluent pas, elles se complètent.
Et j'ai marre de répéter ça à quelqu'un qui par pure mauvaise foi ne veut pas comprendre.

Bien, admettons que ce soit "malhonnête" de donner des chiffres en termes logarithmiques (linéaires en l'entropie) plutôt que linéaires (exponentiels en l'entropie).

Alors oui, je l'avoue, je suis très malhonnête, et en fait la réalité est toute autre : tu as une super méthode qui fait gagner 17% de valeurs de seed en plus, pour plus de 20 octets [je peux aussi passer les tailles en chiffres exponentiels pour être "honnête", ce qui fait 2^20 valeurs si tu préfères ], alors que rand() ne souffre que d'un léger défaut qui fait que la version corrigée a 25500% de valeurs de seed en plus

Et si tu veux, tu peux même faire un seed sur 48 bits ou 64 bits : tu auras un algo 6553500% mieux (resp. 429496729500% mieux), pour un surcoût du même ordre de grandeur (et peut-être même plus faible) que tes fameux 17%. Moi je pense que tu fais une fixation sur cette histoire de "surjectivité" qui est parfaitement ridicule.


Ensuite, pour ce qui est de l'équiprobabilité, ça ne veut rien dire : en supposant qu'on prenne un coefficient assez élevé pour avoir injectivité, il y a équiprobabilité sur l'ensemble des valeurs atteintes... Et il apparaît assez évident que pour n entier, rand^(n) de cet ensemble est plutôt uniforme.


Et je suis parfaitement pour le fait de prendre un randomize() 1392508800% plus efficace que l'actuel, mais les 17% en plus m'ont l'air clairement superflus.

Pollux :
alors que rand() ne souffre que d'un léger défaut qui fait que la version corrigée a 25500% de valeurs de seed en plus

Je sais que le rand actuel est nul (Nils et toi, vous m'avez convaincus de cela avec des arguments mathématiques solides), mais le randomize actuel est bien pire (comme tu l'as très bien vu, toi, cf. la dernière phrase), donc la priorité est:
1. randomize
2. rand (oui, le rand actuel sera remplacé...)
Mais j'ai un peu l'impression de me répéter, à force de parler dans le vide.

Pour le reste de ton message, ce sont encore des chiffres dépourvus de sens qui polluent l'argumentation. "There are lies, damn lies and statistics."

Et mes priorités pour TIGCCLIB sont:
1. correction (correctness)
2. taille (code size)
3. vitesse (execution speed)
Et je sais que des compromis ont été nécessaires sur le point 1. pour tenir le 2. dans des marges raisonnables (non-support des streams notamment), mais les routines de nombres aléatoires ne sont pas dans cette catégorie.

Kevin Kofler
:

Pollux :
alors que rand() ne souffre que d'un léger défaut qui fait que la version corrigée a 25500% de valeurs de seed en plus

Je sais que le rand actuel est nul (Nils et toi, vous m'avez convaincus de cela avec des arguments mathématiques solides), mais le randomize actuel est bien pire (comme tu l'as très bien vu, toi, cf. la dernière phrase), donc la priorité est:
1. randomize
2. rand (oui, le rand actuel sera remplacé...)

Jusque là on est d'accord.

Mais j'ai un peu l'impression de me répéter, à force de parler dans le vide.

J'ai l'impression d'avoir déjà exprimé des doutes concernant l'utilité de la détection du hardware dans randomize

Pour le reste de ton message, ce sont encore des chiffres dépourvus de sens qui polluent l'argumentation. "There are lies, damn lies and statistics."

Et pourtant, ces vilains chiffres montrent les limites de ton raisonnement et de ton estimation des besoins.
Si tu es prêt à sacrifier 20 octets pour 17% de seeds en +, pkoi pas remplacer ce sacrifice par le passage de rand() à 48 bits, qui est de coût grosso modo équivalent (voire inférieur) et qui, lui, apporterait 6553500% de seed en +, et une meilleure périodicité? Pour moi, c'est tout vu, le passage à 48 bits serait largement plus rentable! (je ne dis pas qu'il serait très utile _non plus_, parce que je pense que 32 bits devraient suffire pour une utilisation on-calc; mais si on se dit qu'il vaut mieux sacrifier un peu de place pour plus de précision, alors c'est clairement le choix à faire)

Et si tu acceptes le passage à 48 bits, le même raisonnement se posera pour le passage à 64 bits, et ainsi de suite jusqu'à ce qu'on dépasse la limite des 64kb Quelles sont exactement tes priorités?

Kevin Kofler :
Et mes priorités pour TIGCCLIB sont:
1. correction (correctness)
2. taille (code size)
3. vitesse (execution speed) Et je sais que des compromis ont été nécessaires sur le point 1. pour tenir le 2. dans des marges raisonnables (non-support des streams notamment), mais les routines de nombres aléatoires ne sont pas dans cette catégorie.

Mouarf
Si tu voulais être parfaitement cohérent avec tes objectifs, le MD5 de la RAM s'imposerait (à la limite, seuls les 32 ou 64 premiers ko sont nécessaires). Puis un rand() sur 32 ou 48 bits (voire, si tu veux vraiment faire ton extrémiste et ralentir significativement tous les progs, calcul du MD5 du seed de la dernière itération, mais c'est plus discutable).

Tu me saoules avec ton MD5 de la RAM. Ce n'est pas équiprobable, la valeur est toujours la même après un reset total, c'est ouvert à la triche dans les jeux etc.

Kevin Kofler
: Ce n'est pas équiprobable

Euh, ça reste à voir ça.

la valeur est toujours la même après un reset total

Pas plus qu'avec FiftyMSecTick.

c'est ouvert à la triche dans les jeux etc.

Et sinon tu n'as pas répondu à mon passage te demandant pkoi tu préférais gagner 17% plutôt que de passer en 48 bits.

Je suis tout à fait d'accord avec Kevin sur le dernier point : ce n'est pas parce qu'un générateur a l'air compliqué et lourd qu'il est forcément bon. En l'occurence, avec un Md5 d'un bout de ram, il doit y avoir des tas de façons pour un utilisateur de biaiser le générateur aléatoire. Et tu n'as aucune garantie sur la fiabilité de cet algo.

Je suis tout à fait d'accord avec Kevin sur le dernier point : ce n'est pas parce qu'un générateur a l'air compliqué et lourd qu'il est forcément bon.

Oui. Mais un coup d'oeil à l'algo du MD5 me laisse de bonnes raisons de croire qu'il fait _aussi_ un bon générateur aléatoire; mais bien sûr, je ne suis pas assez spécialiste. En tout cas, il fait à coup sûr une très bonne source de seed (à défaut d'avoir des itérés successifs plutôt aléatoires).

En l'occurence, avec un Md5 d'un bout de ram, il doit y avoir des tas de façons pour un utilisateur de biaiser le générateur aléatoire.

Si tu considères que l'utilisateur n'a pas le droit de toucher à l'horloge, alors non, ce n'est pas possible pour lui de le biaiser.
Si tu considères qu'il a le droit, alors c'est encore pire sans MD5.

Et tu n'as aucune garantie sur la fiabilité de cet algo.

?

Faites des vrais demonstrations. Ca me fera des vacances.
Avec la liste de TOUTES les hypotheses necessaires.