PureBasic

Alors là, faut qu'on m'explique !!!!
PB4 (et avant????) sait débugguer le nombre : 8 trillions 900 billiards 800 billions 700 milliards 600 millions 500 milles 432 !!!!!!!!!!!!!
POURQUOI ?????????

Deuxieme question : pourquoi nous n'atteignons pas ce nombre en faisant : Et pourtant, MESSIEUX et MESDAMES(LNA je crois), PB sait calculer de tres grands nombres.
La preuve : Je suis donc partagé entre la joie et l'etonnement...........

QUI PEUX EXPLIQUER ???

SPH a écrit : QUI PEUX EXPLIQUER ???

C'est simple : euh .... ^^

c'est à cause du fait qu'un entier est codé sur un nombre insuffisant de bit.

Un entier en coder sur 4octets soit 32bits ce qui nous donne en enlevant le bit de signe :
111 1111 1111 1111 1111 1111 1111 1111 en base binaire soit 2 147 483 647 en décimal. C'est bien en dessous de ton nombre ^^

Donc la valeur max de ton entier est nettement inférieur à ton nombre (8 trillards ...).

Par contre pour la commande debug, ne sachant pas sur quoi elle se base ...

Dorian a écrit :c'est à cause du fait qu'un entier est codé sur un nombre insuffisant de bit.

Un seul bit sert pour indiquer le signe. Cela est relativement insignifiant et n'explique pas cette gigantesque difference !!!

En effet, 32 bits donne un chiffre entre 0 et 4294967295
Et en utilisant le 32eme bit pour le signe, on va de -2147483648 à 2147483647

djes a écrit :

Code : Tout sélectionner

i.q= 8900800700600500432
Debug i

CA ALORS !!!!!!!
Depuis quand on a des ".q" ???????????

Pourquoi tant d'étonnement ?

En tout cas je rassure tout le monde - tout va bien - pas de bug ici
Ici le nombre est interprété par le compilateur comme étant un Quad.
Si le nombre avait été beaucoup plus petit, le nombre aurait été interprété comme un Long (.l)
Les Quads (.q) et Doubles (.d) étant sur 64bits on peut donc atteindre des nombres colossaux d'où leur intéret mais au détriment (très relative) lenteur.

Ici on force le compilateur a dire met dans 'i' (Long par défaut si on ne met pas le type .l) le nombre 8900800700600500432. Or 8900800700600500432 est beaucoup trop grand pour un Long. Donc le compilateur se plaint et il aurait tort de se priver.
Ici, pas de variable, que des nombres. Le compilateur purebasic est suffisamment 'intelligent' pour faire en sorte que le type du résultat s'adapte au calcul effectué. Même composé de Long, le résultat pour être correct nécessite d'être un converti en Quad. On observe le meme comportement avec Long/Float/Double etc...
Il faut toujours se méfier du type de données qu'on manipule et qu'on génère dans un programme.

oups - un peu lent.

SPH a écrit :

Dorian a écrit :c'est à cause du fait qu'un entier est codé sur un nombre insuffisant de bit.

Un seul bit sert pour indiquer le signe. Cela est relativement insignifiant et n'explique pas cette gigantesque difference !!!

Si pour chaque bit ajouté, tu double la capacité de ton nombre :

1bit -> 1 max
2bits -> 2 max
4bits -> 4 max

Alors comme là fait remarqué djes, le quad (.q) fait 8octets soit 4 de plus que l'entier. Soit au total 64bits :
111 1111 1111 1111 1111 1111 1111 111 1111 1111 1111 1111 1111 1111 1111 1111 max en binaire, soit 9 223 372 036 854 775 807 enn décimal (signé) voilà ou est ta grosse différence ^^

SPH a écrit :Ma question demeure : Depuis quand on a des ".q" ????????

Je crois que sa date de la V4 pour Pure et depuis je sais pas combien de temps pour les autres (en C# c'est le Int64)

="Dorian
Si pour chaque bit ajouté, tu double la capacité de ton nombre :

Ouai, DOUBLER, ok... MAIS LA, on double pas, on fait carrement une puissance de 2 !

On ne passe donc pas de 32 a 33 bits mais de 32 a 64

En tout cas, C'est GENIAL car je me sert de tels nombres !!!!!!!!!!!

SPH a écrit :

Dorian a écrit : Si pour chaque bit ajouté, tu double la capacité de ton nombre :

Ouai, DOUBLER, ok... MAIS LA, on double pas, on fait carrement une puissance de 2 !

On ne passe donc pas de 32 a 33 bits mais de 32 a 64

Bah oui c'est le format au dessus ^^.

C'était juste pour dire que lorsque tu ajoute un bit, le nombre max décimal (et donc binaire) est doublé. Donc à force d'en rajouter tu obtient de très grand nombre

Un seul bit sert pour indiquer le signe. Cela est relativement insignifiant et n'explique pas cette gigantesque difference !!!

En effet, 32 bits donne un chiffre entre 0 et 4294967295
Et en utilisant le 32eme bit pour le signe, on va de -2147483648 à 2147483647

qu'est ce que tu ne comprends pas ?

Un seul bit modifié suffit largement a modifié énormément le sens d'une valeur quelqu'elle soit.

ensuite ce qu'il faut comprendre c'est qu'en purebasic tout les types sont 'signées' (signed) en opposition à non-signées (unsigned).

le fait qu'on puisse dire qu'un nombre est négatif nécessite de le 'signer' et donc de consacrer/sacrifier un bit pour çà. Ce simple bit utilisé divise par deux la capacité de n'importe quel type (byte, word, long, etc...)

si on veut utiliser pleinement la capacité d'un type parcequ'on sait d'avance qu'on ne manipulera pas de nombre négatif il faudrait disposer des types 'unsigned' comme en C/C++. mais pour l'instant en purebasic ces types types ne sont pas inclus nativement : x.ub, x.uw, x.ul, x.uq, etc...

SPH a écrit :Ma question demeure : Depuis quand on a des ".q" ????????

depuis la v4 pardi