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
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
https://codes-sources.commentcamarche.net/source/53855-deux-bibliotheques-pour-calculer-avec-des-entiers-tres-grands
24 déc. 2011 à 12:37
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 à +.
23 déc. 2011 à 20:19
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...
23 déc. 2011 à 18:27
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.
23 déc. 2011 à 18:08
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.
23 déc. 2011 à 17:46
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.
22 déc. 2011 à 16:31
Une variable locale n'a pas de valeur avant son initialisation par le programeur (ou plutôt, ça peut être n'importe quoi). En revanche, une variable globale est toujours initialisé à zéro au lancement de l'application.
Donc, RandSeed étant une variable globale à l'Application, est initialisée à zéro au lancement (sans Randomize), ou prend une valeur imprévisible (avec Randomize).
Mais RandSeed est TOUJOURS initialisée !
Alors, pour obtenir le comportement familier d'une application avec des Randoms et tes unités, il faut :
- Dans NewGint, supprimer la procedure PRndGIntMize;
- Dans NewGCent, supprimer la procedure PRndGCentMize;
- Et initialiser tes variables dans la Form principale, par exemple :
procedure TForm1.FormCreate(Sender: TObject);
begin
Randomize; // Slasher pour obtenir toujours la même séquence de nombres pseudo-aléatoires.
NewGint.RndGInt := Abs(RandSeed);
NewGCent.RndGCent := Abs(RandSeed);
...
end;
Ainsi, si tu slashes Randomize, tu obtiens toujours la même séquence de nombres à chaque lancement, que ce soit le Random de Delphi ou des GCent/GInt (comportement de mise au point).
Si tu laisses Randomize, les séquences seront toujours toutes différentes (comportement habituel).
Ce qui est bien le comportement orthodoxe du couple Randomize/Random.
J'ai testé.
22 déc. 2011 à 12:26
Je crois qu'on va tourner ainsi en rond longtemps :
1/les unités sont LIBRES d'utilisation et d'adaptation.
2/ si tu ne veux de liaison ni avec randomize, ni avec random de Delphi; tu shuntes l'initialisation et tu seras libre de renseigner RandGInt ou RandGCent des unités avec la graine que tu veux dans tes essais et tes programmes. Point.
3/ pour un utilisateur lambda qui veut de l'aléatoire (pseudo...) pour produire des grands nombres et correctement gérer le test de Rabin-Miller, il peut utiliser les unités telles qu'elles sont conçues.
20 déc. 2011 à 17:10
20 déc. 2011 à 04:07
Commentaire de Rekin85 le 16/12/2011 21:59:23
« Pour le Randomize, je crois que tu fais une petite erreur de raisonnement... »
Mais ne pas utiliser Randomize est une option !
Tes unités confisquent cette option à l'utilisateur-programmeur, et je me vois mal expliquer à mes applications qu'elles ont fait une erreur de raisonnement quand j'utilise tes unités. :)
Si les ingénieurs de Delphi (comme d'ailleurs de tous les langages) ont sorti "Randomize" du "Random", c'est qu'il y a une bonne raison.
En période de conception d'une IA qui joue au Bridge, par exemple, je veux que les "mains" soient toujours les mêmes pour mettre au point mon algo (pour cela, il me suffit de ne pas faire de "Randomize"). Mais si j'utilise tes unités, ce n'est pas possible !
"RandSeed" est une variable globale à l'Application !
Y'a parfois de l'aléatoire qui doit pouvoir se répéter.
@Barbichette
L'infini n'est pas forcément synonyme de grandeur sans limite !
En analyse, quand X -> 0, X devient infiniment petit. Bien que l'ensemble soit borné de ce côté-là !
Et malgré ça... ça dure, ça dure. Ca dure infiniment ! lol
C'est vrai ! C'est fou les maths...
19 déc. 2011 à 18:16
J'ai modifié le zip ce jour... Et comme on est dans les cadeaux de Noël, NewGInt s'est enrichie de deux petites routines qui génèrent des nombres premiers : FPremier4k(Nb) et FPremier6k(Nb) donc respectivement de la forme 4k+-1 et de la forme 6k+-1.
19 déc. 2011 à 16:37
Un bug cependant dans le calcul de la racine carrée par FRacineGint:
racine carrée de 2^(2*n) et 2^(2*n+1) donne le même résultat 2^n
il me semble que l'erreur vient de:
" i:=IsDiv2GInt(Nb,P);
if P then begin Result:=FDeuxPowerN(i shr 1); Exit; end;"
à modifier ainsi:
i:=IsDiv2GInt(Nb,P);
if P and (i mod 2=0) then begin Result:=FDeuxPowerN(i shr 1); Exit; end;
//valable seulement pour les puissances paires de 2
19 déc. 2011 à 12:42
A Barbichette : "...on ne peut pas faire correspondre un nombre de R avec un nombre de N"
... loupé : t'as oublié tous les nombres de R dont la partie fractionnaire est égale zéro.
"mais R à un nombre infini "encore plus grand" d'éléments"
... et l'infini à la puissance infinie ???
"Mais bon, on est d'accord que ça ne fait pas avancer votre Schmilblick"
Bin si tu veux faire avancer le Schmilblick tu peux nous faire un test des possibilités limites de la fonction FFactorielleGInt(Nb: GInt): GInt; de l'unit NewGint de Rekin85 sur une grosse bécane sachant qu'un nombre du type Gint reconvertit en une string-base-10 pour l'affichage du résultat ne doit pas dépasser Length(string-base-10)<=2147483647 chiffres.
Bon, tu me diras que 2147483647 chiffres c'est pas l'infini ... mais à titre de comparaison un fichier de 6,878 Mo équivaut à un "texte de chiffres" imprimé recto-verso sur les 1000 pages d'un paquet de 500 feuilles A4, épais de 5 cm et donc que les 2 Go de chiffres ça fait environ 297 fois plus (lol).
A+.
19 déc. 2011 à 08:51
L'ensemble N des entiers naturels contient un nombre infini de nombres.
L'ensemble Z des entiers relatifs contient un nombre infini de nombres encore plus grand ? (puisqu'il y a les nombres négatifs en plus...)
Et bien non,
si on fait correspondre (0 avec 0), (1 avec 1), (-1 avec 2), (2 avec 3), (-2 avec 4),.... (n avec 2n-1) et (-n avec -2n) on remarque que chaque nombre de N correspond à un nombre de Z.
Donc, il y a "autant" de nombres dans N que Z.
Par contre, l'ensemble R a plus de nombres que N (on ne peut pas faire correspondre un nombre de R avec un nombre de N).
Donc N à un nombre infini d'élément, mais R à un nombre infini "encore plus grand" d'élément.
C'est fou les maths...
Mais bon, on est d'accord que ça ne fait pas avancer votre Schmilblick.
Barbichette
16 déc. 2011 à 22:09
16 déc. 2011 à 21:59
Pour le Randomize, je crois que tu fais une petite erreur de raisonnement, j'ai expliqué plus haut que j'avais dû "sortir" le générateur de pseudo-aléatoires de Delphi pour éviter les problèmes de compilation selon les versions de Delphi. Trois routines internes utilisent ce générateur congruentiel et pour initialiser sa variable de stockage (RandGInt) je le fais au lancement du programme (Inizialisation) par l'entremise d'une copie de Randseet de Delphi d'où UN SEUL APPEL à Randomize pour extraire les données de l'horloge interne. Point barre. Randomize et Random de Delphi ne sont pas du tout utilisés par les routines des deux unités qui utilisent ce générateur interne. C'est clean pour l'utilisateur.
16 déc. 2011 à 19:17
...
« tout petit bug vicieux mais peu fréquent »
J'espère que ce n'était pas une multiplication par zéro considérée comme ne faisant rien... lol
16 déc. 2011 à 18:08
16 déc. 2011 à 17:50
1) A Cirec : Merci pour DelForExp : je viens de l'installer sous Delphi-5 et ça marche. ....
Mais beurkk je comprends pas que vous aimez ces squelettes interminables qui grimpent le long de la marge de gauche comme un lierre !
Mais bon, je l'utiliserai lors d'une future mise à jour.
2) A Caribensila :
2.1) "Je vais prendre une image :
-On considère 4 femmes TRES belles.
...
-Peut-on démontrer que l'ensemble B est plus beau que l'ensemble A ?
-Peut-on démontrer (comme ton prof l'a fait) que la femme A serait plus belle que les 3 autres ?
- Moi, je dis que non."
... Puisque on défini les 4 femmes TRES belles on ne peut effectivement, et par définition pas démonter qu'une serait plus belle que l'autre sinon il faudrait modifier la définition.
2.2) "l'infini est une quantité qui ne cesse d'augmenter - Oui. C'est ce que j'appellais un concept."
... OK, on est d'accord que ce concept est un nombre qui ne cesse d'augmenter.
2.3) "http://fr.wikipedia.org/wiki/Droite_r%C3%A9elle_achev%C3%A9e"
... OK, j'y jetterai un coup d'oeil.
2.4) "Einstein" : Entièrement d'accord avec lui.
2.5) "...le mathématicien a absolument tous les droits dans son domaine. Certains ont même dit qu'il pouvait exister des nombre² négatifs et que x/0 = infini" : Si ça leur chante....
... Mais x/0 ça me fait rigoler, car "0" c'est le néant, c'est "rien", donc diviser x par rien ça revient à ne pas diviser x. (lol)
... Par contre x/Epsilon tend vers l'infini lorsque Epsilon tend vers 0.
... Et pendant qu'on y est : "0/0" c'est kif-kif car ça signifie "diviser rien par rien"
2.6) "Mais ne serions-nous pas légèrement H.S. ? lol"
... Pourquoi seulement "légèrement" ? (lol)
A+.
16 déc. 2011 à 17:06
Désolé d'avoir joué le turlupin. lol
Je me suis peut-être mal exprimé en parlant de "concept".
Ce que je voulais dire, c'est que l'infini n'est pas un nombre. Donc ne peut pas être une quantité et ne peut être comparé.
Je vais prendre une image :
-On considère 4 femmes TRES belles.
-On en fait 2 groupes, A et B.
-Dans le groupe A, il n'y a qu'une seule de ces femmes.
-Dans le groupe B, les 3 autres.
-Peut-on démontrer que l'ensemble B est plus beau que l'ensemble A ?
-Peut-on démontrer (comme ton prof l'a fait) que la femme A serait plus belle que les 3 autres ?
- Moi, je dis que non.
Tu dis : «[l'infini est] une quantité qui ne cesse d'augmenter »
- Oui. C'est ce que j'appellais un concept.
Voici un site sur la "Droite réelle achevée" qui apporte quelques éclaircissements sur ce difficile problème de l'infini :
http://fr.wikipedia.org/wiki/Droite_r%C3%A9elle_achev%C3%A9e
Et pour l'anecdote, je rappellerais cette citation d'Einstein (le pacifiste) :
« Il n'y a qu'une chose qui donne une idée de l'infini, c'est la bêtise humaine. »
En d'autres termes, puisqu'il parlait de la guerre :
" on peut toujours ajouter de la 'bestialité' à l'Homme, ce sera toujours un homme sans qu'il ne devienne jamais un animal".
Maintenant, le mathématicien a absolument tous les droits dans son domaine. Certains ont même dit qu'il pouvait exister des nombre² négatifs et que x/0 = infini.
Le problème pour les non-matheux comme nous étant qu'on utilise les mathématiques comme un instrument pour "mesurer" l'univers qui nous entoure, et qu'on a besoin que cet instrument soit en cohérence avec cet univers.
C'est parfois là que ça gêne aux entournures ! :-)
Mais ne serions-nous pas légèrement H.S. ? lol
16 déc. 2011 à 16:14
Mille fois merci, je vais essayer, ça me permettra de garder mon indentation "crade" pour moi et publier du "standard" pour les autres.
A+.
16 déc. 2011 à 15:43
tiens voici l'adresse de DelForExp l'un des "formateurs" de codes les plus utilisé ... de D2 à D2007
http://www.aew.wur.nl/UK/Delforexp/
il existe une version qui s'intègre à l'IDE et une Standalone.
16 déc. 2011 à 11:06
A Caribensila (msg du 15/12/2011 00:27:29) : Le truc suivant suivant me trotte dans la tête depuis hier : "Pour le mathématicien, le terme "infini" ne désigne pas une quantité, mais un concept".
... Je dirais plutôt que cela ne désigne pas une quantité uniquement lorsque cela arrange le matheux, par contre lorsque il conclut que K/X tend vers 0 lorsque X tend vers l'infini ça l'arrange bien de considérer le "X-infini" comme une quantité!!! Et donc l'infini est une quantité qui ne cesse d'augmenter.
A+.
15 déc. 2011 à 15:37
1) "on s'est déjà croisés sur un certain forum des professionnels de l'informatique"
... Exact.
2) "Non. On ne peut pas vraiment appeler ça "tester". J'ai parcouru le code, c'est tout. Je le testerai à fond le jour où j'en aurai besoin, bien sûr..."
... Ce qui est bien dans les units de Rekin85 c'est que les trucs en Asm sont, entre autres, très bien indentés.
Mais si tu jettes un oeil dans les units de ma calculette tu y trouveras une indentation très personnelle.
Et comme Cirec, dans le topic sur la correction des "yeux rouges", avait écrit "Certains experts comme Formatter, Gexperts, FastCube etc indentent automatiquement le code..." j'ai essayé de télécharger l'un d'eux, mais manque de bol je n'en ai pas trouvé qui fonctionne sous Delphi-5 ... cela m'aurait permis de conserver mon indentation "crade" puis de la passer à la moulinette avant de publier quelque chose ici.
A+.
15 déc. 2011 à 15:04
- Je sais. Le monde de la programmation n'étant pas infini (contrairement à...), on s'est déjà croisés sur un certain forum des professionnels de l'informatique. ;-)
Et d'ailleurs, donner la valeur +infini à un entier divisé par zéro, ça ressemble bien à un physicien, ça !.. lol
« Au fait, as-tu déjà testé pratiquement la NewGCent, la NewGint, ou la calculette ??? »
- Non. On ne peut pas vraiment appeler ça "tester".
J'ai parcouru le code, c'est tout. Je le testerai à fond le jour où j'en aurai besoin, bien sûr...
15 déc. 2011 à 14:20
Donc, laissons les "chercheurs" cantoristes chercher...
Comme disait le Grand Charles "On trouve des chercheurs qui cherchent... mais on cherche des chercheurs qui trouvent !!!" (lol)
Pour ma part j'ai un faible pour les maths appliquées.
Au fait, as-tu déjà testé pratiquement la NewGCent, la NewGint, ou la calculette ???
A+.
15 déc. 2011 à 14:07
Tu as raison, c'est une théorie de Cantor.
Par curiosité et pour l'anecdote (et parce que ça me dépasse de beaucoup et que j'en avais jamais entedu parlé), j'ai regardé ce que ça provoquait comme discussions sur le Net...
Eh ben, c'est pas piqué des hannetons ! lol
On trouve des trucs du genre (je cite) :
« ...en orthodoxie, les "chercheurs" cantoristes disent ne pas encore savoir si 2 puissance aleph zéro = aleph 1
Dans le cas où quelqu'un prouverait cette idiotie à base d'mbéciles aleph cantoriens... »
« ...D'où on pourrait écrire (si les aleph étaient autre chose que des crétineries stupides du mystique Cantor)... »
«... L'autre idiotie en rapport avec les aleph est le fait que leur bijection n'a aucun sens... »
J'avais jamais vu un sujet provoquant autant de haine sur les forums des matheux ! lol
15 déc. 2011 à 11:01
A Caribensila (msg du 15/12/2011 00:27:29)
1) "Pour le mathématicien, le terme "infini" ne désigne pas une quantité, mais un concept. Et on ne peut pas comparer la taille de 2 concepts."... OK, sauf qu'en se contentant du jouer avec des "concepts" on fini par jouer sur les mots, or pour moi le domaine des maths c'est tout d'abord le domaine des nombres donc du quantitatif. Et si on fixe une définition disant que "2" ça correspond à 2 carottes ou 2 doigts et non 3 dès que la définition est fixée on est obligé de la respecter. Donc si on définit l'infini comme représentant la valeur numérique la plus grande possible on est également obligé de respecter la définition et dans ce cas "infini + infini infini" et "Deux à la puissance Aleph-zéro infini"
2) Le prof de Pseudo3 a forcément commis une erreur de raisonnement"
... Pour l'histoire de "Deux à la puissance Aleph-zéro". Je me souviens avoir vu un jour sur Wikipédia un article qui en parle et il me semble que ça vient de Cantor. (à vérifier)
3) "En effet Dieu, qui est omnipotent, aurait créé toute chose en une journée. Donc les Entiers aussi."
... Ouille, reste à savoir si le concept de Dieu n'est pas tout simplement l'invention de politicards des temps anciens qui, pour mieux dominer la populace, l'ont inventé "tout puissant" histoire de parler en son nom : Même de nos jour encore il y a des "petits chefs" qui disent à leurs subordonnés "exécutez c'est le grand chef qui l'exige" pour faire passer leur propre caprice.
4) "Mais redescendons sur Terre avec les erreurs NaN....Mais ..., en revanche une opération comme "0/0" n'est pas interdite. Le résultat est juste indéterminé et cela justifierait un message du style "NaN""
... bin comme 0/0 est aussi une division rien ne t'empêche de remplacer le message "Opération impossible" par "NaN".
5) "J'avoue que j'ai souvent le même problème dans mes applications : où situer le traitement des exceptions ? Dans la routine finale ou en amont ?"
... en fait on est toujours obligé du fait que quand on programme on manipule un héritage : Exemple avec les fonctions standard de Delphi on hérite de ArcTan2(Y/X) qui plante quand X=0 alors qu'elle devrait renvoyer -Pi ou Pi selon que Y est positif ou négatif, donc on est obligé de traiter le problème dans la routine utilisatrice.
6) A propos de « en conséquence de quoi si tu utilises ma calculette pour diviser un nombre par zéro ça t'affiche comme résultat "+infini". »
Tu dis "Et ben c'est une erreur ... ALORS M=N. Ce qui est contraire à l'hypothèse !"
... bon, si ça te fait plaisir je remplacerai le message "+infini" par "NaN"
7) "Mathématiquement parlant, la division par zéro n'a pas de sens"
... absolument d'accord, impossible de diviser le néant, ni par zéro, ni par autre chose.
A+.
15 déc. 2011 à 00:27
« Pour les intellos-matheux il existe un infini plus grand que l'infini... »
- Non ! Pas pour les matheux (dont je ne fais pas partie, d'ailleurs) !
Le bon sens commun peut considérer que l'ensemble des Réels est plus grand que l'ensemble des Entiers car l'un est contenu dans l'autre et qu'il y a une infinité de Réels entre deux Entiers consécutifs. Mais c'est mathématiquement faux.
Pour le mathématicien, le terme "infini" ne désigne pas une quantité, mais un concept. Et on ne peut pas comparer la taille de 2 concepts. Ainsi, de 2 sphères de tailles différentes, il est impossible de déterminer laquelle est plus ronde que l'autre, bien que leur rotondité soit différente.
Le prof de Pseudo3 a forcément commis une erreur de raisonnement. Sinon il aurait pu, de la même façon, démontrer que Dieu n'existe pas !
En effet Dieu, qui est omnipotent, aurait créé toute chose en une journée. Donc les Entiers aussi. Or, dans une journée, il y a un commencement et une fin et, à la dernière seconde de la journée, il restera toujours un Entier n+1 qui restera non créé (et même au 7ème jour !). Le mathématicien amateur et mécréant pourrait donc conclure que Dieu n'a pas pu tout créer.
Le mathématicien rigoureux, lui, est d'accord avec le théologien et dit que Dieu a créé les Entiers en même temps que le concept d'infini, mais que l'infini n'est pas une quantité. Conséquence : on ne peut donc pas comparer 2 infinis différents.
Mais comme chez Aristote l'infini ne s'applique qu'aux grandeurs et aux quantités, le matheux-philosophe dira que l'infini est une quantité de perfection. Circulez ! Y'a plus rien à voir ! Tout est dans tout. lol
Mais redescendons sur Terre avec les erreurs NaN.
Si l'utilisateur fait calculer une division par zéro par votre programme, tant pis pour lui, on est d'accord. Mais je pensais plutôt que cela pouvait arriver dans des calculs intermédiaires où l'utilisateur n'aurais aucune responsabilité. Rekin85 a prévu le truc avec "Opération impossible". C'est OK.
Mais je me permets de signaler que s'il y a des opérations interdites (comme la division par zéro) justifiant le message "Opération impossible", en revanche une opération comme "0/0" n'est pas interdite. Le résultat est juste indéterminé et cela justifierait un message du style "NaN". Mais bon ! J'avoue que je pinaille...
Maintenant le commentaire "En principe à ne pas utiliser sans précaution de l'extérieur" pourra semblé à certains discutable. En effet, en bonne programmation, c'est à l'application de traiter les exceptions et de "blinder" le code. Responsabilité que vous laissez à l'utilisateur-programmeur.
J'avoue que j'ai souvent le même problème dans mes applications : où situer le traitement des exceptions ? Dans la routine finale ou en amont ?
-Dans la routine finale ça plombe les performances; en amont, il y a risque d'oubli ou de récurrence. Mais je les traite toujours quelque part, moi ! lol
« en conséquence de quoi si tu utilises ma calculette pour diviser un nombre par zéro ça t'affiche comme résultat "+infini". »
Et ben c'est une erreur.
M<>NSi M/0 +infini ET N/0 +infini, ALORS M=N. Ce qui est contraire à l'hypothèse !
Mathématiquement parlant, la division par zéro n'a pas de sens.
@Rekin85
Pour le problème String vs Array, je me laisse convaincre par le programmeur ASM :)
Pour Randomize, en revanche, je ne suis pas d'accord.
« variable d'appui RndGInt qu'il faut bien initialiser au moins une fois au départ ! »
Ben non. D'ailleurs elle fait doublon avec RandSeed.
« Randomize reste libre pour l'utilisateur dans son code perso »
Ben non, justement. Tu peux vérifier facilement.
Il y a confusion, je crois...
Quelques explications :
ATTENTION: Pour la suite, j'ai slashé tes deux "Randomize" dans tes unités.
1) Sans Randomize :
Càd que j'ai supprimé TOUS les Randomize de l'application.
Au départ, RandSeed est un Integer initialisée à zéro (en Delphi).
Et tu fais: RndGInt:=RandSeed;
Ce qui a pour concéquence d'initialiser RndGInt à zéro.
Cela n'a aucune importance car la graine du générateur sera zéro plutôt que n'importe quelle autre valeur dans l'étendue Integer. Mais le générateur s'en fout pas mal et calculera sa suite de nombres pseudo-aléatoires à partir de zéro, voilà tout !
En revanche, cela garantit qu'au prochain lancement la suite pseudo-aléatoire sera la même (tant que le programmeur ne fera pas Randomize) puisque la graine sera toujours zéro. Ce qui est bien le résultat attendu. Et cela pour un Random Delphi ou n'importe lequel de ceux que tu as programmé dans tes unités.
2) Avec UN SEUL Randomize pour toute l'application, décidé par le programmeur et généralement placé dans le FormCreate :
Là, Delphi initialise RandSeed avec, je crois, une partie de l'heure système (un Double).
Et tu as donc toujours dans ton code: RndGInt:=RandSeed;
Donc ta variable RndGInt sera initialisée avec la valeur imprévisible de RandSeed (imprévisible et non pas aléatoire! 3412 n'est pas plus aléatoire que 1111 ou 1234. Seule une séquence de nombres peut être aléatoire).
Ensuite, le générateur calculera sa suite avec cette graine.
Par contre, au prochain lancement, l'heure système aura changée et le générateur fournira donc une autre suite à partir d'une autre graine ! Ce qui est bien le résultat attendu.
Dans le code que tu as posté, il est impossible d'obtenir toujours la même suite à chaque lancement à cause de tes 2 Randomize !
Alors que cela peut s'avérer très utile pour les applications de simulation ou de calculs statistiques.
« A la limite, je pourrais m'affranchir totalement de Delphi en me faisant ma propre routine d'initialisation basée sur l'horloge interne »
Comme expliqué plus haut, l'initialisation n'est pas le problème. En revanche, un algo produisant une suite de nombres quasi-aléatoires moins cyclique que l'algo du générateur Delphi serait souhaitable si tu veux garder ton triple A ! lol
D'ailleurs, il serait avantageux que cela fasse l'objet d'un autre projet pour pouvoir le poster à part. Cela devrait intéresser beaucoup de personnes qui n'ont pas forcément besoin des Grands Entiers.
@+
14 déc. 2011 à 14:11
A Rekin85 : "Pour les nombres entiers, l'infini n'existe pas : il y aura toujours un nombre supérieur à un autre N=(N-1)+1..."
... J'aime bien, et ça me rappelle qu'un jour un prof, en amphi, nous a tourné le dos pendant 2 heures pour nous démontrer que "Deux à la puissance Aleph-Zéro" c'est supérieur à l'infini !!! (lol). Autrement dit, pour les intellos-matheux il existe un infini plus grand que l'infini...
Mais revenons en aux GCent et aux GInt : "Ce dont il faut faire attention ce sont les dépassements de capacité mémoire si on fait le fanfaron dans les exponentielles et les factorielles..." :
... je dirais même plus : si on fait le fanfaron, avec nos petites bécanes poussives, même sans dépassement de capacité de mémoire, il faut aussi dans ce cas avoir une sacrée patience pour attendre l'affichage du résultat ... mais on s'en rend vite compte.
A+.
14 déc. 2011 à 12:43
Pourquoi le type AnsiString ? Parce que c'est un type qui met les octets toujours à la queue leu leu. Pas de problème de littel Indian sauf de temps en temps quand les calculs se font en registres 32 entiers... Donc la facilité pour le programmeur ASM. D'autre part, on peut compter sur les appels de gestion de mémoire des strings de Delphi pour remettre de l'ordre dans les recopies et les retours de fonctions... Nickel-chrome sans fuite ! Il aurait été aussi simple d'utiliser le type Array of byte ? Soit, mais fi de tout ce qu'offre Delphi pour les strings... Il y a toujours une raison impérieuse à un choix... Le problème originel était la vitesse des conversions nombres binaires<=>Ascii; j'ai essayé d'éviter les calculs mathématiques trop lourds au profit de simples décalages de registres 16 bits. C'est pourquoi ces routines si importantes sont si performantes, j'ai au mieux essayer d'éviter l'écueil d'autres bibliothèques du même genre.
Randomize : L'appel en ASM du générateur des aléatoires de Delphi est différent selon les versions (D5, D7, D9...) bien que la routine interne soit identique. Donc, pour éviter les déboires des utilisateurs potentiels à la compilation, j'ai été obligé de sortir ce générateur dans l'unité (RandDW). Ce générateur est appelé par toutes les routines FRandomXX des unités qui n'appellent jamais Randomize ! Cette petite routine RandDW utilise une variable d'appui RndGInt qu'il faut bien initialiser au moins une fois au départ ! C'est pour cela qu'il y a un appel à Randomize de Delphi une fois et seulement une fois à l'initialisation des unités pour charger RandGInt avec La RandSeed de Delphi. C'est tout. Randomize reste libre pour l'utilisateur dans son code perso... A la limite, je pourrais m'affranchir totalement de Delphi en me faisant ma propre routine d'initialisation basée sur l'horloge interne. Mais c'est un peu du temps perdu. Bof !
Pour les nombres entiers, l'infini n'existe pas : il y aura toujours un nombre supérieur à un autre N=(N-1)+1... (Complexe de la flêche qui n'atteint jamais son but !) Je plaisante L'infini n'est pas traité dans les unités sauf lors de calculs impossibles qui y conduisent comme la division par 0... Il y a normalement un message d'erreur "Opération impossible". Ce dont il faut faire attention ce sont les dépassements de capacité mémoire si on fait le fanfaron dans les exponentielles et les factorielles...
Merci beaucoup pour les liens : je vais étudier et tenter d'améliorer s'il le faut.
Bien cordialement
A+
14 déc. 2011 à 11:55
A Caribensila (msg du 13/12/2011 19:24:55 10/10)
1) Tu dis "- ce serait une bonne idée, je pense... Avec un lien vers ce topic."
... Entre-temps, j'ai réfléchi un peu : si je le publie ici avec un lien vers ce topic l'utilisateur sera agacé par le fait que mon appli utilise une vieille version des GCent alors que le lien vers ce topic fournit une version différente.
... Donc, comme j'ai commencé à actualiser mon appli en utilisant les NewGCent qu'on trouve ici, et que cela prendra un certain temps, je vais plutôt opter pour la parade temporaire suivante :
- Ceux qui sont intéressés par la version actuelle de l'appli "Résolution d'équations + Calculette" qui utilise l'ancienne version des GCent pourront s'en télécharger le code ici : http://www.phidels.com/php/index.php3?page=../commun/voirexemples.inc.php3&ColorId=622&ChoixMenu=divers&PHPSESSID=6d4a615adafb833c283fbbce956b37f5#id622
- Et quand j'aurai terminé la mise à jour de cette appli je la publierai ici avec un lien vers ce topic.
2) Tu dis "En général, on choisit les tableaux plutôt que le type string pour manipuler ces nombres" :
... Il existe une Unit FGInt d'un autre auteur qui utilise un Array Of int64 pour les grands nombres, que j'avais testée ... et que j'ai vite laissée tomber à cause de l'extrême lenteur des conversions Base10StringToFGInt() et FGIntToBase10StringArray(). Rekin85 t'en dira certainement davantage sur ce qu'il pense à ce sujet.
Interface
3)A propos de Randomize tu dis "Ces appels répétés peuvent perturber le générateur de Delphi..."
... Tiens je pensais que c'est le dernier appel à Randomize qui prime et que le plus grand risque c'est plutôt d'oublier de faire appel à lui.
4) Ton msg du 13/12/2011 19:52:49
Tu dis "si un calcul renvoie une valeur NaN (non numérique), comme +infini, que se passe t-il ? Je n'ai pas l'impression que ce soit traité dans le code, mais je me trompe peut-être..."
... Avant de faire appel à une division par exemple il appartient toujours au programmeur de vérifier si le dénominateur n'est pas nul pour éviter la division par zéro, il en est de même avec les GCent et les Gint.
Je viens de vérifier : dans les NewGCent il y a un commentaire qui dit à propos de 4 routines dont la PDivMod(Nv1,Nv2 : GCent; var Q,R : GCent) "En principe à ne pas utiliser sans précaution de l'extérieur"
... Et compte tenu de ceci, dans l'UnitGR pour calculs avec des Grands Réels (voir son en-tête dans mon msg du 12/12/2011 11:05:23) le type tGR inclut le champ Signe : ShortString qui selon les cas prend les valeurs '+', ou '-' ou 'infini', ... en conséquence de quoi si tu utilises ma calculette pour diviser un nombre par zéro ça t'affiche comme résultat "+infini".
A+.
13 déc. 2011 à 20:29
je serai prudent à seules fins d'affichage ?
13 déc. 2011 à 19:52
Je pense à un truc qui peut causer bien des soucis :
- si un calcul renvoie une valeur NaN (non numérique), comme +infini, que se passe t-il ? Je n'ai pas l'impression que ce soit traité dans le code, mais je me trompe peut-être...
13 déc. 2011 à 19:24
« soit je peux publier carrément l'appli de résolution des équations associée à la calculette dans son état actuel et dans une discussion distincte de la présente »
Ben, je n'ai pas autorité pour donner mon avis. Mais je le donne quand même :)
- ce serait une bonne idée, je pense... Avec un lien vers ce topic.
@Rekin85
« A l'origine, la destination était la cryptologie... »
Ok, je comprends mieux l'absence de la virgule ou du point.
J'ai jeté un oeil sur le code. QUE DE L'ASM ! lol Mais, heureusement c'est commenté.
Deux petites remarques :
1) En général, on choisit les tableaux plutôt que le type string pour manipuler ces nombres.
Mais j'avais aussi fait ce choix à l'époque. Je pensais comme toi que ce serait plus facile, mais à tort, m'a-t'on dit...
Enfin, peut-être qu'en assembleur, String ou Array ne font pas grandes différences ?
2) ATTENTION : Randomize est une commande pour le programmeur !
Ce n'est pas bien de l'utiliser dans son dos car il peut vouloir obtenir toujours la même séquence de nombres pseudo-aléatoires. Ne serait-ce que pour tester une routine.
D'autre part, Randomize est appelé dans les deux unités, sans compter que le programmeur peut lui-même l'appeler dans son propre programme s'il utilise ces unités à l'aveuglette. Ces appels répétés peuvent perturber le générateur de Delphi qui est déjà de bien piètre qualité. D'ailleurs l'Aide Delphi le précise bien :
« pour initialiser le générateur de nombre aléatoire, ajoutez un seul appel Randomize ».
Il faut donc supprimer Randomize dans les procédures PRndGIntMize de l'unité NewGint et PRndGCentMize de l'unité NewGCent. Ce sera au programmeur de l'utiliser, ou pas, selon ses besoins.
Du coup, j'ai testé (avec D7) le générateur de nombres pseudo-aléatoires. Hélas, il semble souffrir des mêmes faiblesses que ceux de Delphi. Sur des unités de cette qualité, destinées quand même à faire des calculs scientifiques, on pourrait s'attendre à mieux, je pense.
VOIR: http://www.alrj.org/docs/algo/random.php
Sinon, c'est assez facile à utiliser.
Allez ! 10/10 !
PS:
Au sujet des générateurs de nombres premiers, JP DELAHAYE a écrit un article très intéressant sur l'état actuel de cette science dans le numéro d'octobre 2011 de "Pour la Science".
Cet article est téléchargeable ci-dessous (2€, mais ça vaut le coup pour un passionné) :
http://www.pourlascience.fr/ewb_pages/f/fiche-article-la-maitrise-des-nombres-premiers-27975.php
13 déc. 2011 à 13:24
A Amiga68 : Autre remarque concernant l'utilisation de la fonction StrParTrois() : Supposons que tu utilises la bibliothèque pour effectuer un calcul dont le résultat qui via FGIntToStr() te serait affiché sur 3 pages A4, du coup en utilisant StrParTrois() tu te retrouveras avec un résultat qui s'étale sur 4 pages.
Et si tu fais un copier-coller de ce résultat (qui est donc de la forme
544 364 365 454 354 546 635 326 ...) pour l'injecter dans un deuxième calcul t'es obligé de virer d'abord tous les espaces de cette string sinon le résultat du deuxième calcul sera complètement faux.
Bien que le résultat du formattage par groupes de 3 chiffres soit plus agréable à l'oeil ne pas oublier non plus que cela va de surcroît ralentir les conversions or il faut savoir que les routines le plus lentes de la collection sont justement les routines de conversion Base-256 <-> Base-10 (Gint) et Base-100 <-> Base-10 (GCent).
A noter cependant que les conversions des GCent sont bien plus rapides que celles des Gint : donc si on a beaucoup de calculs à faire qui se terminent par un seul affichage du résultat on peut préférer utiliser la NewGint, et si on a besoin d'afficher beaucoup de résultats intermédiaires on peut préférer utiliser la NewGCent.
A+.
13 déc. 2011 à 11:53
Bonjour. Bien, je persiste à dire que la fonction demandée est inutile dans la bibliothèque et voire "dangereuse" à utiliser car si on se promène en aller-retour string ASCII<=>nombre GInt on risque fortement d'introduire des dysfonctionnements. Ne pas oublier que ces routines sont "BASIQUES" et laissent la liberté au programmeur de manipuler les données comme il l'entend. Les convertisseurs ASCII<=>GInt ou GCent n'admettent que des ASCII numériques de '0' à '9' et rien d'autre !
Néanmoins, pour présenter les nombres en classes de 3, voici une routine de formatage :
function StrParTrois(StrNb: string): string; register;
var lst: longword;
asm
push edi
push esi
push edx // réserve l'adresse de résult
mov esi,eax // esi pointe StrNb
mov eax,edx // Raz Result
call System.@LStrClr // remise du compteur de références
mov eax,[esi]-$4 // Nombre d'espaces
mov lst,eax
mov ecx,$3
div ecx // = Ln div 3
cmp edx,$0
jne @S1 // si reste=0
dec eax // alors retirer 1 espace
@S1:
mov ecx,lst
add esi,ecx //esi pointe la fin de StrNb + 1
add eax,ecx // longueur nouvelle string
push eax
call System.@NewAnsiString // créer nouvelle chaîne
pop edx // remise longueur
pop edi // remise ptr Result
mov [edi],eax // place le pointeur en Result
mov edi,eax // edi pointe la string
add edi,edx // edi pointe fin string + 1
// boucle de remplissage de Result
mov ecx,lst
@R3:
mov ah,$3 // par paquets de 3 octets
@R33:
dec esi
mov al,byte ptr[esi]
dec edi
mov byte ptr[edi],al
dec ecx
jz @fin
dec ah
jnz @R33
dec edi
mov byte ptr[edi],$20 // placer un espace tous les 3
jmp @R3
@fin:
pop esi
pop edi
end;
On est bien d'accord, elle ne vérifie rien, elle ne fait que grouper les octets par 3 en démarrant de la fin.
13 déc. 2011 à 11:29
Néansmoins, ce genre de calculs est ridicule avec ces librairies, mais il sont possibles ! Plusieurs solutions sont possibles en voici 2 parmi d'autres:
procedure TForm1.Button1Click(Sender: TObject);
var Nb1,Nb2,Nb3 : GInt;
begin
Nb1:=FIntToGInt(99); Nb2:=FIntToGInt(1);
Nb3:=FAddGInt(Nb1,Nb2);
Memo1.Lines.Add(FGIntToStr(Nb3));
//ou
PIncGInt(Nb1);
Memo1.Lines.Add(FGIntToStr(Nb1));
//ou
Nb2:=FStrToGInt('1');
Nb3:=FAddGInt(Nb1,Nb2);
Memo1.Lines.Add(FGIntToStr(Nb3));
//etc...
end;
J'ai bien précisé que le maniement de ces routines demande d'être circonspect à l'implémentation. Nous avons pris soin de les accompagner d'un fascicule explicatif.
13 déc. 2011 à 09:27
9+1 --> 10 bon
99+1 -> :0 ?
999+1 -> 9:0 ?
....
Y-a-t-il une configuration spéciale ?
Merci
Salutations
12 déc. 2011 à 12:18
Alors pour tous, je voudrais apporter quelques précisions de génèse et de destination de ce boulot de quelques années.
Je suis tout nouveau membre ici et je ne connais pas trop bien les usages, mais je vais m'adapter vite. Si ces unités ont été placées là c'est à la demande de mon ami Pseudo3 qui en est le co-auteur, mais elles sont aussi sur un autre site dédié à Delphi où elles ont été téléchargées maintenant presque 2000 fois sans aucune remontée négative depuis plus d'un an.
A l'origine, la destination était la cryptologie... donc domaine des entiers naturels (et moi je cherche toujours à fabriquer des nombres premiers géants rapidement... en vain). Le but étant d'avoir des routines arithmétiques de base pour des nombres plus grands que 32 bits. L'ASM a donné des possibilités énormes pour les vitesses. Et un jour Pseudo3 (Gilbert) qui cherchait des routines rapides pour un de ses programmes (calculette scientifique) m'a contacté et proposé ses services pour les tests et applications. Son aide m'a été très précieuse et a fait faire un énorme bond en avant pour les optimisations. Surtout, il est à l'origine de la création des GCents. Alors voilà c'est un travail collectif à deux extrêmement abouti (nous sommes champions de la racine carrée goutte à goutte et de la multiplication Karatsubée...).
Ces deux unités sont ouvertes : elles sont là pour servir de base à tous besoins numératoires; ainsi pour les réels, Gilbert l'a déjà fait grâce à une unité de son cru et moi j'ai déjà proposé par ailleurs des aménagements dans le domaine des entiers relatifs. Donc ouvertes et libres d'utilisation...
@Caribensila : je comprends ton souci d'inachevé, mais le but n'était pas de refaire une librairie complète comme celles qui sont utlisables en C. L'usage de l'ASM pour les implémentations n'est pas du travail relax et je ne pense pas étendre mon travail personnels au-delà (sauf dans le domaine de la primalité).
@AMIGA68 : Oui, par paquets de trois, c'est humainement plus lisible, mais tu sais quand on dépasse plusieurs milliers de digits... Mais je vais tartiner une petite routine ASM comme tu le souhaites et quand je serai prêt je la placerai ici. Alors patience, il faut être très prudent en ASM car il faut gérer la RAM et surtout ne pas se faire piéger par le gestionnaire de variables de Delphi (une poisse !). Alors à bientôt.
12 déc. 2011 à 11:05
A Caribensila le : "Bon ! Certains vont te reprocher d'avoir négligé les Réels. Ou plutôt, de laisser le boulot à l'utilisateur."
... Eh bin non : Les Réels n'ont pas été négligés, ni même les nombres complexes, car j'ai utilisé les GCent (version n-1 des NewGCent ci-dessus) dans une appli incluant d'une part la résolution des équations polynomiales de degré N, et d'autre part une calculette pour grands ou petits nombres réels ou complexes.
Voici par exemple l'en-tête de l'unit pour les Grands ou petits Réels :
unit UnitGR;
interface //*********************************************************
// Pour calculs avec Grands Réels à nombre de chiffres *
// significatifs supérieur à 20 *
// Code : EXPERIMENTAL *
//*********************************************************
uses Windows, Dialogs, Controls, SysUtils, math, Forms, Graphics,
clipbrd, UnitIntGCent, uFun2, uConstPrecalculees, uFlotte2, buttons;
type tGR = record
Signe : ShortString;
Sv : GCent; // chaîne numérique représentée en base 100 expurgée des puissances de 10
Expo : Int64; // Expo correspond aux puissances de 10 mais renseigne aussi sur la position du DecimalSeparator
// dans la représentation décimale après conversion du nombre :
// - si Expo < 0 alors Expo = Décalage du Séparateur Décimal par rapport à la fin de la chaîne Sv // - si Expo 0 alors Sv valeur entière
// - si Expo > 0 alors Sv = valeur entière et Expo équivaut au nombre de '0' à ajouter en fin de Sv
// dans une représentation intégrale du nombre (représentation au format non scientifique)
end;
Et voici celle de l'unit pour les nombres complexes :
unit UnitGC;
interface //*********************************************************
// Pour calculs avec Grands nombres Complexes *
// avec part réelle et imaginaire du type tGR *
// Code : EXPERIMENTAL *
//*********************************************************
uses Windows, UnitGR, classes, Math, Dialogs, Sysutils, uFun2, clipbrd;
type tGC = record
a : tGR; // part réelle
b : tGR; // part imaginaire
end;
Le seul inconvénient est que j'ai eu la flemme de refaire tout ce boulot pour l'adapter à la version actuelle des NewGCent mais il donne des idées sur les possibilités offertes par l'utilisation des bibliothèques publiées ici par Rekin85.
Donc si ça intéresse quelqu'un :
- soit il me passe son adresse e-mail et je lui envoie le zip contenant le code qui utilise l'ancienne version des GCent,
- soit je peux placer ici dans un commentaire les codes de l'unit UnitGR et de l'unit UnitGC dans leur état actuel,
- soit je peux publier carrément l'appli de résolution des équations associée à la calculette dans son état actuel et dans une discussion distincte de la présente.
... Mais ma principale gêne est que mon appli utilise la version n-1 des NewGCent et que l'on reproche que cela fait un peu désordre sur ce site.
Par contre vu que Caribensila a dit "Négligé ... Ou plutôt, de laisser le boulot à l'utilisateur" j'ajouterais que la publication présenterait l'avantage de réduire l'importance du boulot laissé à l'utilisateur puisqu'il ne lui reste plus qu'à adapter l'unit UnitGR et la UnitGC à la version actuelle des NewGCent OU des NewGint.
Qu'en pensez vous ?
A+.
12 déc. 2011 à 06:45
Je pensais depuis longtemps à faire ce genre de boulot... j'y connais rien en asm... c'est fait ?
Une suggestion : serait-il difficile d'implémenter un FGIntToStrF (formaté en paquets de trois chiffres) ? Cela irait plus vite en asm qu'à partir du programme appelant...