DEUX BIBLIOTHÈQUES POUR CALCULER AVEC DES ENTIERS TRÈS GRANDS

Caribensila
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
- 11 déc. 2011 à 23:33
cs_pseudo3
Messages postés
268
Date d'inscription
mardi 24 juillet 2007
Statut
Membre
Dernière intervention
2 février 2021
- 24 déc. 2011 à 12:37
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/53855-deux-bibliotheques-pour-calculer-avec-des-entiers-tres-grands

cs_pseudo3
Messages postés
268
Date d'inscription
mardi 24 juillet 2007
Statut
Membre
Dernière intervention
2 février 2021

24 déc. 2011 à 12:37
Bonjour,

Content que la solution de Rekin85 satisfasse les voeux de Caribensila pour cette histoire de Random's.

A Barbichette : "Pour les motivés, il ne reste plus qu'a intégrer ces unités dans mes deux sources" :
... Bin comme tu viens de manifester ta motivation, et vu en outre que tu es celui qui connaît le mieux tes deux sources il ne te reste plus qu'à intégrer ces unités dans tes sources.

Appel aux volontaires pouvant utiliser une grosse bécane : Comme les tests de vitesse et de bon fonctionnement des unité NewGInt et NewGCent on été effectués sur des petites bécanes, donc avec des calculs portant sur des "grands nombres relativement petits" en comparaison à la capacité limite d'une string-Result de 2 Go cela vaudrait le coup que quelqu'un puisse faire quelques tests sur une grosse bécane avec quelques calculs dont le résultat comporte un nombre de chiffres proche des 2 Go.

Mais faire gaffe à l'affichage du résultat car 2147483647 chiffres en Times New Roman taille 10 (j'avais oublié de citer la taille des caractères dans mon msg du 19/12/2011 12:42:13) cela équivaut à une impression sur environ 297,7 paquets de 500 feuilles A4 imprimées recto-verso ... mais on peut aussi faire des tests avec une séquence de calculs successifs, par exemple une suite de N élévations au carré du style "Result=Result-Au-Carré", interrompue lorsque la string-Result est proche des 2 Go, et suivie dans ce cas par une suite de N extractions de la racine carrée du style "result=RacineCarrée(Result)" pour retrouver la valeur de la graine élevée au carré au départ et dont le nombre de chiffres à afficher est forcément facilement affichable ou imprimable puisqu'il a été possible de le saisir en entrée.

Autre possibilité : Faire "Factorielle(N) divisé par Factorielle(N-1)" tels que les string-Result des factorielles soient proches des 2 Go et n'afficher donc que le résultat N.

Bonnes fêtes, et à +.
Caribensila
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
18
23 déc. 2011 à 20:19
Waou ! Il faut reconnaître que ça aurait de la gueule et qu'on en parlerait dans les chaumières !

Le résultat serait sans doute supérieur à la somme des résultats des parties.

Mais c'est aussi plus qu'une simple intégration, et il y a quand même beaucoup de boulot... et pas pour un amateur...
Rekin85
Messages postés
25
Date d'inscription
dimanche 11 décembre 2011
Statut
Membre
Dernière intervention
17 octobre 2015

23 déc. 2011 à 18:27
Perfection non : tout est toujours perfectible...

Voilà, j'ai mis le zip à jour et j'en ai profité pour y palcer un sous-zip qui contient un petit exécutable nommé Calculator.exe.

C'est une calculette (encore une !). Des amis m'avaient demandé de bien vouloir illustrer l'utilisation de mon unité NewGInt; ce n'est qu'une application parlante. Maintenant si quelqu'un veut le source entier... Bin c'est toujours possible mais j'avoue être mieux armé pour l'ASM que pour appliquer du Delphi.
Caribensila
Messages postés
2527
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
16 octobre 2019
18
23 déc. 2011 à 18:08
Eh bien, mon cher Rekin85, il me semble que ta solution soit la meilleure ! :)

La séparation des initialisations laisse encore plus d'options à l'utilisateur-programmeur. Ce qui est toujours une avancée.
Et ta méthode ne perturbera en rien les habitudes du programmeur. Ce qui est toujours préférable.

Désolé de t'avoir occasionné ce travail supplémentaire.
Mais je trouvais que tes unités méritaient la perfection.
Rekin85
Messages postés
25
Date d'inscription
dimanche 11 décembre 2011
Statut
Membre
Dernière intervention
17 octobre 2015

23 déc. 2011 à 17:46
A Caribensila :

Oui c'est une bonne solution. Moi je t'en propose une plus en rapport avec l'usage du langage Delphi. Mais avant je te rappelle que ce problème est lié aux différences de compilations selon les versions de Delphi. Donc a priori il a fallu "sortir" le générateur congruentiel. Ainsi Les deux unités (qui normalement sont autonomes) possèdent toutes les deux leur générateur : RandDW pour NewGInt et RndDW pour NewGCent. Ainsi les routines de génération de nombres aléatoires écrites en ASM appellent respectivement ces routines en interne : pas d'appel à random de Delphi. Evidemment il faut bien que ces générateurs s'appuient sur leur variable propre : RndGInt pour NewGInt et RndGCent pour NewGCent; celles-ci seront donc initialisées à 0 pour chacune des routines et ensuite chargées ou pas comme l'utilisateur le désire.

La notice indiquera que les fonctions de générations de nombres aléatoires :

FRandomGInt(), FRandomLGInt(), FRandomLGIntImpair() et FPremierXXX() pour NewGInt
FRandomGCent() pour NewGCent

doivent être précédées au moins une fois d'un appel aux routines d'initialisations respectives à savoir PRndGIntMize et/ou PRndGCentMize.
Afin de ne pas faire d'embrouille avec le coulpe Randomize/Randseed de Delphi, tout est séparé. Ainsi Les deux routines d'initialisations font leur propre lecture de l'heure système et RndGInt et RndGCent n'ont plus rien à voir avec RandSeed.

Qu'en penses-tu ? Les nouvelles unités et leur nouvelle notice sont prêtes dans leur noveau zip : un mot de toi et elles viendront remplacer le zip actuel.
Afficher les 41 commentaires