begin process at 2013 06 20 05:40:17
  Trouver un code source :
 
dans
 
[ Dernières recherches ]
Accueil > 

Code

 > 

Maths

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

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


 Information sur la source

Note :
10 / 10 - par 3 personnes
10,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Maths Classé sous :maths, grands entiers, calculs arithmétiques Niveau :Initié Date de création :11/12/2011 Date de mise à jour :11/05/2012 16:42:43 Vu / téléchargé :5 180 / 317
Auteur : Rekin85

Ecrire un message privé
Commentaire sur cette source (43)
Ajouter un commentaire et/ou une note

 Description

Cliquez pour voir la capture en taille normale
NewGInt et NewGCent sont deux unités .pas pour effectuer des calculs divers sur des entiers très grands (en principe "illimités"). Toutes deux, elles offrent de nombreuses fonctions et procédures utilisables facilement dans des applications Delphi. Citons pour mémoire les calculs arithmétiques élémentaires : addition, soustraction, multiplication, division, puissance, factorielle... mais aussi les opérations d'arithmétique modulaire et les opérations de logique... et autres bien intéressantes.

Source

  • NewGInt s'applique à des nombres codés en base 256
  • alors que NewGCent manipule des entiers codés en
  • base 100 avec tous les avantages d'une approche décimale.
  • L'une et l'autre peuvent s'utiliser séparément ou
  • conjointement grâce à des passerelles.
  • Elles forment un ensemble assez complexe nécessitant
  • des précautions d'utilisation en raison des énormes
  • volumes d'octets manipulés dans les calculs.
  • Malgré cela elles sont relativement rapides car les
  • noyaux calculatoires de base ont été optimisés en ASM 32bits.
  • Pour faciliter leur utilisation, un fascicule explicatif
  • d'accompagnement est fourni dans le zip de téléchargement.
NewGInt s'applique à des nombres codés en base 256 
alors que NewGCent manipule des entiers codés en 
base 100 avec tous les avantages d'une approche décimale.
L'une et l'autre peuvent s'utiliser séparément ou 
conjointement grâce à des passerelles.
Elles forment un ensemble assez complexe nécessitant 
des précautions d'utilisation en raison des énormes 
volumes d'octets manipulés dans les calculs. 
Malgré cela elles sont relativement rapides car les 
noyaux calculatoires de base ont été optimisés en ASM 32bits.
Pour faciliter leur utilisation, un fascicule explicatif 
d'accompagnement est fourni dans le zip de téléchargement.

 Conclusion

Ces bibliothèques sont le fruit de mes recherches depuis plusieurs années et tous les essais et améliorations ont été portés à systémisation par la grande participation active de Pseudo3. Il s'agit donc déjà d'un ensemble très élaboré et en principe bien abouti qui ne demande qu'à être utilisé par tout un chacun.

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Historique

11 décembre 2011 16:21:52 :
Rendre les commentaires plus lisibles
16 décembre 2011 17:59:08 :
Un petit bug découvert par Pseudo3 dans l'unité NewGCent. Unité corrigée
19 décembre 2011 18:07:46 :
Petit bug en FRacineGInt corrigé
23 décembre 2011 18:20:31 :
Réarrangement des procédés d'utilisation des générateurs de nombres aléatoires
15 février 2012 14:25:20 :
Amélioration sensible de la partie concernant la génération des nombres premiers : FGetGIntPrime remplace FPremier. Ajout de routines ultrarapides pour l'analyse des petites divisibilités.
11 mai 2012 16:42:43 :
Ajouts de diverses fonctions à NewGCent : une powermod, un test de primalité (Miller-Rabbin), des caractères de divisibilités, et un générateur de nombres palindromes.

 Sources de la même categorie

Source avec Zip FRACTIONS, ADDITION, SOUSTRACTION, MULTIPLICATION, DIVISION ... par f0xi
Source avec Zip Source avec une capture MANIPULATION TRÉS RAPIDE DE TRÉS GRANDES NOMBRES ENTIERS + F... par kamel78
Source avec Zip CONVERSION OF (HEX BIN OCT) TO EACH OTHER par MSBMW
Source avec Zip Source avec une capture RESOLUTION EQUATIONS DEGRE "N" + CALCULETTE SCIENTIFIQUE par pseudo3
Source avec Zip Source avec une capture MOTEUR PHYSIQUE 2D CHIPMUNK.. EN DELPHI! par Bacterius
Toutes les sources de la catégorie Maths

 Sources en rapport avec celle ci

Source avec Zip ALPHA DE CRONBACH (INDICE UTILISÉ EN PSYCHO) par fredelem
Source avec Zip Source avec une capture CONJECTURE DU CARRÉ DES FACTEURS par Bacterius
Source avec Zip CALCULATRICE POUR POËTES par fredelem
Source avec Zip Source avec une capture LES TOURS DE HANOÏ (( MODE GRAPHIQUE UTILISATEUR / RÉSOLUTIO... par offlake
Source avec Zip Source avec une capture APPROX'PI, OU COMMENT APPROXIMER PI AVEC LA MÉTHODE DE MONTE... par Bacterius

Commentaires et avis

Commentaire de Caribensila le 11/12/2011 23:33:07

Bonjour,

Ca tombe bien, je viens de commencer mon apprentissage en assembleur. Mais, encore trop newbie dans le domaine pour apprécier maintenant. Dommage.
C'est pour cela que je n'ai lu que le .pdf pour l'instant, en attendant de faire quelques tests.

Bon ! Certains vont te reprocher d'avoir négligé les Réels. Ou plutôt, de laisser le boulot à l'utilisateur.
Je trouve aussi que tu aurais pu, après toute cette masse de travail, ajouter ce petit traitement qui ne t'aurait pas pris un temps énorme par rapport au reste. En virgule fixe, il t'était facile de dispatcher les calculs vers les routines déjà codées pour les entiers et de "présenter" le résultat. C'est vraiment dommage car, pour beaucoup, ça donnera un goût d'inachevé.
D'autant qu'en bistromatique c'est souvent dans les décimales que tout se joue.
Voir cette discussion :
http://www.delphifr.com/codes/REELS-REALITE_44550.aspx

Enfin, pour m'être déjà frotté à la bistromatique et connaissant la masse de travail pour optimiser le truc, je serais très tenté de mettre un 9/10. Mais je vais attendre ta réponse et peut-être une màj pour les Réels pour mettre un 10/10 qui serait bien mérité.

En attendant, BRAVO et MERCI !

Commentaire de amiga68 le 12/12/2011 06:45:21 10/10

Ben merci !!!
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...

Commentaire de pseudo3 le 12/12/2011 11:05:23

Bonjiour,

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+.

Commentaire de Rekin85 le 12/12/2011 12:18:11

Merci beaucoup pour vos premiers commentaires et avis.

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.

Commentaire de yvessimon le 13/12/2011 09:27:16

Bonjour,

9+1 -->  10 bon

99+1 ->    :0  ?
999+1 ->  9:0  ?
....

Y-a-t-il une configuration spéciale ?

Merci
Salutations

Commentaire de Rekin85 le 13/12/2011 11:29:52

A YVESSIMON : bonjour et merci. Sans l'extrait du code qui a conduit au dysfonctionnement, il est impossible de pouvoir corriger un bug éventuel.

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.

Commentaire de Rekin85 le 13/12/2011 11:53:07

A Amiga68

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.

Commentaire de pseudo3 le 13/12/2011 13:24:26

Bonjour,

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+.

  


Commentaire de Caribensila le 13/12/2011 19:24:55 10/10

@Pseudo3
« 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

Commentaire de Caribensila le 13/12/2011 19:52:49

...[esprit d'escalier]

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...

Commentaire de amiga68 le 13/12/2011 20:29:50

merci pour la fonction ?
je serai prudent à seules fins d'affichage ?

Commentaire de pseudo3 le 14/12/2011 11:55:59

Bonjour,

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+.

Commentaire de Rekin85 le 14/12/2011 12:43:35

A Caribensila : Wâââ ! Si c'est pas de la critique constructive ça ? Ah! J'aime bien.

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+

Commentaire de pseudo3 le 14/12/2011 14:11:59

Re-Bonjour,

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+.

Commentaire de Caribensila le 15/12/2011 00:27:29

@Pseudo3
« 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<>N
Si 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.

@+

Commentaire de pseudo3 le 15/12/2011 11:01:58

Bonjour,

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+.

Commentaire de Caribensila le 15/12/2011 14:07:44

[ puissance Aleph-zéro ]

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

Commentaire de pseudo3 le 15/12/2011 14:20:28

Re-salut,

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+.

Commentaire de Caribensila le 15/12/2011 15:04:26

« Pour ma part j'ai un faible pour les maths appliquées »

- 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...

Commentaire de pseudo3 le 15/12/2011 15:37:59

Re-salut,

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+.

Commentaire de pseudo3 le 16/12/2011 11:06:42

Bonjour,

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+.

Commentaire de cirec le 16/12/2011 15:43:09 administrateur CS

@Pseudo3:

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.

Commentaire de pseudo3 le 16/12/2011 16:14:03

Re-bonjour Cirec,

Mille fois merci, je vais essayer, ça me permettra de garder mon indentation "crade" pour moi et publier du "standard" pour les autres.

A+.

Commentaire de Caribensila le 16/12/2011 17:06:00

@Pseudo3
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

Commentaire de pseudo3 le 16/12/2011 17:50:34

Re-bonjour,

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+.

Commentaire de Rekin85 le 16/12/2011 18:08:19

Hou! là là ! J'ai déclenché une tempête avec mon infini qui n'existerait pas... En attendant je signale que Pseudo3 qui adapte sa calculette à NewGcent a retrouvé un tout petit bug vicieux mais peu fréquent dans cette unité. Il est corrigé et la version téléchargeable ici a été mise à jour.

Commentaire de Caribensila le 16/12/2011 19:17:08

« donc diviser x par rien ça revient à ne pas diviser x. »
...
« 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

Commentaire de Rekin85 le 16/12/2011 21:59:23

Non un cas de calcul mal terminé dans une boucle. Mais avec Pseudo3, nous avons redressé le "truc" incompréhensible. Je pense qu'il s'agissait d'une faille introduite a posteriori des essais par une petite erreur de manip ou de frappe; en reprenant l'algo d'origine, tout est rentré dans l'ordre.

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.

Commentaire de Rekin85 le 16/12/2011 22:09:16

Maintenant, si tu le désires, tu peux slasher les randomize; les unités sont offertes en libres utilisation et adaptation.

Commentaire de barbichette le 19/12/2011 08:51:02

Juste pour mettre mon grain de sel sur l'infini, et en ressortant mes cours de fac, les infinis peuvent se comparer, car il en existe plusieurs...
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

Commentaire de pseudo3 le 19/12/2011 12:42:13

Bonjour,

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+.

Commentaire de lljjrrmm le 19/12/2011 16:37:50 10/10

Très bonnes unités. Un grand travail.
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

Commentaire de Rekin85 le 19/12/2011 18:16:56

A LLJJRRMM : Oui très bien vu ! C'est toujours au plus simple qu'on se fait piéger. Personne ne l'avait découvert à ce jour. Grand merci pour ces essais très positifs.

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.

Commentaire de Caribensila le 20/12/2011 04:07:42

@Rekin85
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...

Commentaire de Rekin85 le 20/12/2011 17:10:44

A Caribensila : Oui je te concède ton raisonnement. Donc il ne faut pas toucher au randomize de Delphi ? Alors je te propose de supprimer l'unique appel à randomize dans l'une ou l'autre des deux unités, mais cela engendrera que ma variable RandGInt ne sera pas initialisée... Que proposes-tu ? Laisse-t-on RandGInt:=RandSeed ? ou laisse-t-on le libre choix de l'initialiser aux utilisateurs ? A toi de choisir...

Commentaire de Rekin85 le 22/12/2011 12:26:27

A Caribensila
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.

Commentaire de Caribensila le 22/12/2011 16:31:27

Si tu veux; mais ce n'est pourtant pas difficile d'obtenir un comportement normal avec tes unités.

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é.

Commentaire de Rekin85 le 23/12/2011 17:46:13

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.

Commentaire de Caribensila le 23/12/2011 18:08:07

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.

Commentaire de Rekin85 le 23/12/2011 18:27:31

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.

Commentaire de barbichette le 23/12/2011 19:26:41

Pour les motivés, il ne reste plus qu'a intégrer ces unités dans mes deux sources :
http://www.delphifr.com/codes/INTERPRETEUR-LANGAGE-PERSONNALISABLE-BIS_53427.aspx
et
http://www.delphifr.com/codes/INTERPRETEUR-LANGAGE-PERSONNALISABLE_53363.aspx
Comme ça, on aura un langage interprété gérant des nombres énormes...

bon courage pour la suite à tous

Commentaire de Caribensila le 23/12/2011 20:19:29

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...

Commentaire de pseudo3 le 24/12/2011 12:37:32

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 à +.

 Ajouter un commentaire


Discussions en rapport avec ce code source dans le forum

les maths [ par sheorogath ] alors voila ma question:j'ai un Form2.Edit1 je veut en faire un integer pour y effectuer des operation mathematique comment je dois faire pour arriver Maths [ par jlmcom ] J'ai besoin de réaliser un programme de vérification qui me génère toutes les combinaisons (arrangement sans répétition) de p valeurs d'un tableau de Unité Maths dans delphi? [ par jlmcom ] Il me semble qu'il existait à une époque une unité pascal de fonctions mathématiques.Je viens de faire un tour dans des sources qu'il me restait de de Question en Maths [ par blanc76 ] Salut les amis. Soit N, X, Y des entiers donn&#233;es. je vais d&#233;compos&#233; N en produit des facteurs premiers. puis je cherche toutes les prob Formule Maths en Delphi [ par blanc76 ] Salut mes amis...je suis entrein de cr&#233;er une application en delphi6, cette application contienne des calculs mathematique (log, ln, puissance de Question pour un champion de maths [ par cantador ] Bonjour à tous,J'ai une liste de données de cette manière :ex : 7 enregistrements :           S1     S21        10      3482        45      2303       Programme de maths Aider moi SVP..... [ par Nina0770 ] Salut,Donc je suis nouvelle programmeuse et je veut réaliser le programme suivant:soit un tableau de 8 cases de type entier, je veut afficher toutes l Quick Report [ par bigjohn02tw ] Salut, J'ai un problème avec l'affichage avec Quick Report. Au fait je ne sais pas faire ce que je veux. Alors aider-moi SVP J'ai des matières classé Maths et "régression linéaire" "moindre carrés" je ne sais ! [ par YB91380 ] BONJOUR, Mon niveau math est assez faible mais je me lance dans un calcul sur les incertitudes de mesure soit :U = a + b.IU1 = 20 pour I = 0U2 = 40


Nos sponsors


Sondage...

CalendriCode

Juin 2013
LMMJVSD
     12
3456789
10111213141516
17181920212223
24252627282930

Consulter la suite du CalendriCode

Photothèque

Photo Tropical Fishes near Colorful Coral ReefPhoto Colorful under water marine life
Photo Underwater sea-life 

Visiter la photothèque

A découvrir
 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 3,354 sec (3)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales
Outils Convertisseur VB/C# Snippets et scripts Outils en ligne La ToolBox
Communauté Programmation Photographie Technologie Newsgroups Emploi Forum Blogs
Guide d'achat Téléphonie mobile Image et son Informatique Bureautique Jeux vidéo
Logiciels Internet & Réseau Développement Market Android Jeux & Loisirs Graphisme Multimédia Sécurité Pilotes
Loisirs Cartes virtuelles Vidéos droles Jeux en ligne Géoguide AndroLib [FR] AndroLib [US] FormidApps [FR] FormidApps [US]