Xint : nouvelle bibliothèque C++ pour très grands entiers. - C++ - Programmation
Marsh Posté le 19-08-2005 à 00:33:12
Je te confirme (sans grande surprise ?) que ça existe déjà : http://www.swox.com/gmp/.
Si tu veux comparer ta bibliothèque à une autre, le critère qui fait foi c'est la rapidité, je pense.
Marsh Posté le 19-08-2005 à 10:13:18
Effectivement, sans grande surprise, mais je ne connaissais pas avant de faire ma propre bibliothèque.
Bon, alors forcément, moi je demande si ma bibliothèque est bien, et je ne donne pas de lien vers elle.
http://xint.ehia.org
Maintenant, c'est fait.
Marsh Posté le 19-08-2005 à 15:05:41
Ton programme ne compile pas :
$ g++ Exemple.cpp |
Sinon à en croire ta doc :
Citation : |
Y'a sûrement un effort à faire au niveau des performances. Mon interpréteur Lisp prend environ 0.2 secondes pour calculer 5000!...
Marsh Posté le 19-08-2005 à 16:37:40
/me vient de zieuter le code ...
Y a des antécédents cardiaques dans ma famille je rappelle.
Petite phrase assassine : c'est du très très mauvais C++, tout au mieux du C with classes, pas extensible, mal implémenté, avec assurément des performances exécrables. On voit que tu ne maîtrises absolument pas C++ et que tu n'as fait _aucune_ recherche dans le domaine.
Commence par écrire une classe Fraction...
La cerise sur le gateau, c'est la fonction factorielle, je trouve plus les mots.
(Et non, je ne fais pas le méchant, je suis juste)
Marsh Posté le 19-08-2005 à 16:39:54
je rajoute, n'essayer même pas de compiler, ça ne marche pas.
Code :
|
en voilà une forward declaration bien singulière ... on y croit très fort mais ça ne marche pas hein
Marsh Posté le 19-08-2005 à 17:16:15
ReplyMarsh Posté le 19-08-2005 à 17:54:53
Code :
|
à chaque recursion il construit un nouveau 'Xint' !?
Marsh Posté le 19-08-2005 à 18:01:06
il en construit bien plus d'un ! et surtout le problème, c'est d'implémenter une factorielle pour grands entiers avec une récursion ... y a beaucoup de réflexion derrière.
Marsh Posté le 19-08-2005 à 19:03:39
Soyons clair : le but n'étais pas de supplanter une bibliothèque déjà existante, mais de voir ce que je pouvais faire en C++.
Evidemment, les performances sont donc exécrables, ce code n'a jamais été optimisé, et il n'a pas été fait dans cet esprit non plus. (lisp fait 5000! en 0.2 secondes sans arrondir ? ... ah bon.) J'ai fait ça juste pour que "ça marche".
Non, je ne maîtrise pas le C++. Je débute. (J'ai commencé le C++ il y a environ un mois)
Par contre, pourquoi la compilation ne marcherait-elle pas ? ça marche pourtant chez moi ... (Dev-C++, Windows Xp et 98)
Je ne vois pas pourquoi la "forward declaration" (je ne connaissait pas ce terme, je suppose que ça montre mon niveau) ne marcherait pas. (Je ne contredit pas, je demande, mais pour moi ça compile)
Et il est vrai que la récursivité de la factorielle, c'est n'importe quoi. Pour ce coup là c'est de la fénéantise.
(Taz, tu es peut-être juste, mais c'est quand même méchant ...)
Pour CLK_TCK, il est possible de supprimer la fonction sleep. Elle n'était définie que pour les tests.
Bon, quoi qu'il en soit, merci d'avoir testé.
Jeam... un peu déçu
Marsh Posté le 19-08-2005 à 19:21:23
Jeam a écrit : Soyons clair : le but n'étais pas de supplanter une bibliothèque déjà existante, mais de voir ce que je pouvais faire en C++. |
Ben c'est bien, t'as vu (enfin on t'a fait voir) que tu pouvais pondre les pires atrocités.
Citation : Evidemment, les performances sont donc exécrables, ce code n'a jamais été optimisé, et il n'a pas été fait dans cet esprit non plus. (lisp fait 5000! en 0.2 secondes sans arrondir ? ... ah bon.) J'ai fait ça juste pour que "ça marche". |
"sans arrondir" ça veut dire quoi ?
Citation : Non, je ne maîtrise pas le C++. Je débute. (J'ai commencé le C++ il y a environ un mois) |
T'es peut-être pas parti sur les bonnes bases...
Marsh Posté le 19-08-2005 à 19:53:41
Citation : "sans arrondir" ça veut dire quoi ? |
"sans arrondir" ... ça veut juste dire que ce n'est pas sous forme 4,2285779266 e16325 ... mais je connais lisp juste de nom et de "genre".
Citation : Ben c'est bien, t'as vu (enfin on t'a fait voir) que tu pouvais pondre les pires atrocités. |
C'est mauvais à ce point, même seulement au bout d'un mois ? (pas à temps plein, s'entend)
Marsh Posté le 19-08-2005 à 20:07:43
Taz a écrit : /me vient de zieuter le code ... |
Justement, faudrait penser à te faire soigner un de ces quatre
Citation : (Et non, je ne fais pas le méchant, je suis juste) |
Qo3.16 J'ai encore vu sous le soleil qu'au siège du jugement, là était la méchanceté, et qu'au siège de la justice, là était la méchanceté.
Marsh Posté le 20-08-2005 à 00:58:07
Moi, je trouve que c'est pas mal du tout, après un mois de C++. Ca manque un peu de const tout de même.
Bon ,évidemment, GMP calcule 5000! en 0ms 50000! en 65ms, mais là n'est pas la question...
(je me souviens du temps où je calculais 100! en Basic sur mon Mac+ )
Marsh Posté le 20-08-2005 à 09:22:46
Merci...
Citation : (je me souviens du temps où je calculais 100! en Basic sur mon Mac+ ) |
par contre, je ne savais pas que le basic (c'est le même que MS Quick Basic ?) pouvais avoir une précision de 158 chiffres ... (il faut que je revois mes classiques)
Citation : Ca manque un peu de const tout de même. |
(les const, tu veux dire avec les références dans les fonctions, où je suis complètement à côté ? ce qui ne m'étonnerait pas d'ailleurs ... )
Si vous avez du temps à perdre :
Je sais maintenant que ma bibliothèque est construite en très mauvais C++. Je suis fixé. Par contre, j'aimerais bien savoir quelles sont les plus grosses erreurs (à part la factorielle) ? Je parle au niveau de la technique et du principe.
Pour que, la prochaine fois, je ne reproduise pas les mêmes erreurs (ne vous inquiétez pas, je ne refais pas de bibliothèque pour grands nombres ...)
Marsh Posté le 20-08-2005 à 12:10:50
Jeam a écrit : Merci...
par contre, je ne savais pas que le basic (c'est le même que MS Quick Basic ?) pouvais avoir une précision de 158 chiffres ... (il faut que je revois mes classiques) |
Non, le Basic ne faisait pas du calcul multiprécision, j'avais juste écrit des routines pour ça.
Bof, ton C++ n'est pas extraordinaire, mais on a vu pire ici (et ailleurs). Au bout d'un mois, ça n'a rien d'étonnant. Je n'ai pas vraiment regardé, vu que c'est assez bateau, mais ce qui m'a immédiatement frappé, c'est l'absence du mot-clé déclaratif const, eet bcp (trop) de friend.
Marsh Posté le 22-08-2005 à 09:46:15
C'est en faisant des erreurs qu'on apprend. Tu as ton code qui est lent. Tu as le code de GMP qui est rapide. Etudie le code de GMP, compare le avec le tiens, corrige, ... et progresse!
Pour Taz ne fait pas attention. Le forum te remercie, grâce à toi il a déchargé tout son fouttre, on est tranquilles quelques jours.
Marsh Posté le 23-08-2005 à 10:27:29
el muchacho a écrit : mais ce qui m'a immédiatement frappé, c'est l'absence du mot-clé déclaratif const |
Petite question au passage : faut en mettre le plus possible des const? Enfin à chaque fois qu'on passe une variable qui n'a pas à être modifiée en paramètre ?
Marsh Posté le 23-08-2005 à 20:28:30
Demande à Taz
Il faut en mettre, disons, "raisonnablement". Ceci dit, là où il n'y a pas de pointeur, références et/ou de membres de classes, il n'y a pas trop besoin de const. Dans le cas contraire, c'est utile et une habitude à prendre.
Marsh Posté le 24-08-2005 à 09:21:08
el muchacho a écrit : Demande à Taz |
J'ai déjà fait sa connaissance sur un autre topic, je vais me renseigner un peu ailleurs avant de lui demander!!
Marsh Posté le 24-08-2005 à 19:23:41
Citation : Etudie le code de GMP, compare le avec le tiens, corrige, ... et progresse! |
Je pense que cela ne servirait à rien d'améliorer mon code. Si je veux faire quelquechose de plus rapide, je dois tout refaire, repenser tout le principe. (Ou optimiser mon code, mais ça ne sert à rien non plus )
Et puis, comparer le code de GMP avec le mien ... euh ... Mais étudier le code de GMP, c'est surement très instructif. Mais je vais d'abord m'attaquer à quelque chose de plus "abordable". (Les tutoriaux de C++ par exemple ... )
Bon, et bien merci tout de même d'avoir testé.
Marsh Posté le 18-08-2005 à 23:46:54
Bonjour !
J'ai fait une bibliothèque, Xint, C++ (en fait un fichier .cpp en include) qui ajoute à votre code source le type "Xint". "X" pour extensible, "int" pour entier. (sans blague)
Donc voilà :
au type Xint peut être assigné n'importe quel entier (signé) de moins de 2 milliards de chiffres. (ça, c'est la théorie, car en fait, il vaut mieux rester sous 50 000 chiffres, raison de processeur oblige ! )
J'ai surchargé la majorité des opérateurs au type Xint, ce qui fait que toutes les opérations sont simples à écrire.
Exemple :
Quand j'ai fait la bibliothèque, je ne connaissait pas de bibliothèque qui puisse faire ceci (peut-être ai-je trop peu cherché... ). Mais j'ai fait en sorte que la manipulation des Xint soit le plus simple possible.
Toujours est-il que je voudrais avoir l'avis d'autres utilisateurs que moi pour cette bibliothèque. Notamment sur son comportement intrinsèque (qui est un tableau d'entiers long, nécessaire au fonctionnement mais pas forcément très performant ).
la bibliothèque est sous licence GNU GPL (et non pas LGPL)