limite de capacité des variables

[Backup]

c'est quoi cette mauvaise blague !!

dans la doc il est ecrit que les ".d" sont illimité

j'ai voulu mettre en application le Test Hebdogiciel

que meme mon Zx81 et mon Ti99/4A , et mes Atari etaient capable de faire sans erreur


suivez la valeur de r , et voyez qu'au vbout de la 10 em boucle le PureBasic est completement Largué !!

il affiche "r = 1.#INF"

Code : Tout sélectionner

r.d=2
CallDebugger
For a=1 To 20
  r=r*r
Next a

Debug  r

For a=1 To 20
  r=r/r
Next a

Debug  r

[Octavius]

C'est bien normal. La puissance est stockée sur un octet, c'est-à-dire 8 bits, la limite est donc à 2^8, soit 256. Or si tu calcules rapidement à la main, à la dixième occurrence tu devrais arriver à un nombre environ égal à 10^331... La limite est dépassée, ce n'est pas possible de stocker un nombre plus grand que ça sur un double (8 octets, dont 1 pour la puissance et 7 pour la précision décimale).

Si tu veux une précision infinie sur des nombres très grands tu peux t'amuser avec les structures et les pointeurs mémoires pour créer tes propres types et gérer leur évaluation avec tout une série de procédures... Mais bon tout ça c'est une autre histoire!

Sinon voilà comment obtenir le codage binaire de ton nombre à virgule flottante :

Code : Tout sélectionner

*Mem=AllocateMemory(4)

PokeF(*Mem,9)

Debug Bin(PeekL(*Mem))

Bon ici c'est un exemple pour le type Float mais c'est pareil avec Double, si tu regardes le debug avec le nombre 9 en mémoire tu verras ça : 10000010001000000000000000000000.

Ce qui peut se lire en 4 octets comme ceci : 10000010,00100000,00000000,00000000.

En effet 9 = 1001 (représentation binaire) = 1,001 * 10^N (avec N=3)
Les trois derniers octets codent la partie après la virgule (en gras, on reconnaît le 001) et le premier octet code la puissance. Le premier 1 signifie qu'il y a décalage à gauche et les 7 autres bits codent pour le nombre N-1 (soit 2, donc 10).

[Backup]

c'est quoi cette mauvaise blague !!

dans la doc il est ecrit que les ".d" sont illimité

j'ai voulu mettre en application le Test Hebdogiciel

que meme mon Zx81 et mon Ti99/4A , et mes Atari etaient capable de faire sans erreur

c'est pas la peine de chercher a expliquer une faiblesse de PureBasic !!
je m'en fou de savoir qu'une variable est stocker de façon x ou y , ce que je constate , c'est qu'un MO 5,un Atari ,un Zx81 , bref la quasi totalité des ordinateur 8 bits , etaient capable de gerer ce genre de test !!

le pureBasic, ne sait pas !!! point barre

je vous invite a relire ceci :

http://www.purebasic.fr/french/viewtopi ... ebdogiciel

ps "Guest" c'est moi !!

[gnozal]

dans la doc il est ecrit que les ".d" sont illimité

Dans le manuel officiel (pas la traduction que je n'ai pas installée [à vérifier]) il est écrit :

Double .d 8 bytes unlimited (see below)

Et plus bas on trouve ceci :

Special information about Floats and Doubles

A floating point number is stored in a way that makes the binary point "float" around the number, so that it is possible to store very large numbers or very small numbers. However, you cannot store very large numbers with very high accuracy (big and small numbers at the same time, so to speak).

Another limitation of floating point numbers is that they still work in binary, so they can only store numbers exactly which can be made up of multiples and divisions of 2. This is especially important to realise when you try to print a floating point number in a human readable form (or when performing operations on that float) - storing numbers like 0.5 or 0.125 is easy because they are divisions of 2. Storing numbers such as 0.11 are more difficult and may be stored as a number such as 0.10999999. You can try to display to only a limited range of digits, but do not be surprised if the number displays different from what you would expect!

This applies to floating point numbers in general, not just those in PureBasic.

Like the name says the doubles have double-precision (64 bit) compared to the single-precision of the floats (32 bit). So if you need more accurate results with floating point numbers use doubles instead of floats.

The exact range of values, which can be used with floats and doubles to get correct results from arithmetic operations, looks as follows:
Float: +- 1.175494e-38 till +- 3.402823e+38
Double: +- 2.2250738585072013e-308 till +- 1.7976931348623157e+308
More informations about the 'IEEE 754' standard you can get on Wikipedia.

Ca me parait clair, non ?

[Backup]

la traduction est bien la !!

Informations concernant les nombres flottants

Un nombre flottant est stocké de telle manière que la 'virgule flotte' autour de la partie réelle. De la sorte, il est possible d'avoir des nombres dont la valeur peut être aussi bien grande que petite. Toutefois vous ne pouvez pas stocker de grands nombres avec une précision aussi élevée que des petits nombres.

Une autre limitation concernant les nombres flottants est qu'ils restent concrètement représentés sous une forme binaire. Ainsi, ils ne peuvent être restitués qu'à partir de multiples et de divisions en base 2. Celà est important pour comprendre que la représentation décimale lors de l'affichage ou du calcul n'est pas tout à fait identique à ce que l'on peut attendre dans une représentation humaine. Représenter 0.5 ou 0.125 est simple car ce sont des divisions parfaites de 2, cela est plus complexe pour des nombres comme 0.11 ou 0.10999999. L'affichage approché de la valeur est toujours correct à un nombre limité de décimales, mais ne soyez pas surpris si au-delà le nombre affiché s'écarte de la valeur que vous attendez!

Ces remarques s'appliquent aux nombres flottants traités par ordinateur d'une manière générale et non spécifiquement à Purebasic.

Comme leur nom l'indique, les 'doubles' sont des flottants 'double-precision' (64 bits) comparativement aux flottants 'simple-precision' que sont les floats (32 bits). Donc, pour avoir plus de précision dans la manipulation des nombres à virgule, il est préférable d'utiliser les 'doubles'.

Mais ce que je montre du doigt, c'est pas le fait qu'un nombre a virgule devienne imprecis au bout d'un moment ...

ce que je pose indirectement comme question, c'est Pourquoi PureBasic ne peux pas effectuer le Test "Hebdogiciel" ??
alors qu'un ordinateur 8 bits de la prehistoire s'en sortait plutot pas mal !!!

bien sur il faudrai pour comprendre le sens de ma question, que vous ayez connu l'époque d'Hebdogiciel (mais non je ne me moque pas )

ce test a fait bondir bien des fabricants d'ordinateurs...

mais bon sang de bois , pourquoi un Ordinateur 32 bits comme un PC
n'arrive pas a faire ce qu'un ordinateur 8 bits PEUT faire ..

la je suppose, qu'il ne s'agit pas du Matériel , un Pentium 4 doit surement pouvoir faire ce qu'un Z80 pouvais faire non ? !!

c'est bien le Pure Basic qui est en cause, pas le Matos !!
apres on peut se cacher derriere toute les excuses possible !

le fait est La !!

le Test Hebdogiciel , n'as jamais fait "Planter" un Basic de l'epoque !!

et je ne parle pas du BASIC 1000D de l'Atari , qui était spécialise dans les très grand nombre !!

je suis sur que le test hebdogiciel doit fonctionner sous d'autre langage sur un PC ... alors pourquoi pas sur PureBasic ??

se retrouver avec un signe montrant qu'il est depassé apres avoir seulement fait 10 iteration de boucle , je trouve que c'est plutot tres nul

a l'epoque d'hebdogiciel , ce test aurai mis le purebasic a la poubelle, rien de moins !


Rappel de ce qu'était le Test Hebdogiciel

Les performances du TI-Basic testées par Hebdogiciel :

Un test amusant avait été fait sur l'hebdomadaire Hebdogiciel, n°61 de décembre 1984, dans l'article "20 ordinateurs sur le grill".
Voici le listing du programme de test:

10 A=2
20 FOR N=1 TO 20
30 A=SQR(A)
40 NEXT N
50 FOR N=1 TO 20
60 A=A^2
70 NEXT N
80 PRINT A

Le résultat doit normalement être 2 mais nos chères machines donnaient toutes un résultat faux. Un classement des micros fût fait, du plus approchant au plus éloigné. Le TI-99/4A, et l'EXL-100 arrivèrent en tête avec un résultat de 1.999999924. La raison en est simple, les calculs arithmétiques sont faits avec une précision de 14 chiffres sur le TI-99/4A, contre 8 chiffres pour la plupart des autres micro-ordinateurs de la même époque.

Les résultats du test:
Texas Instruments TI-99/4A 1.999999924
Exelvision EXL-100 1.999999924
Canon X-07 19999997741097
Canon V20 1.99999977
Yashica (MSX) 1.99999977
Amstrad 464/6128 1.999433
Atari 800XL 1.99765243
Sinclair ZX-81 2.000446
Sinclair Spectrum 2.000446
Apple //e 2.00232917
Apple //c 2.0023291
Commodore C64 2.00232917
Oric Atmos 2.00232917
Commodore Vic-20 2.00232917
Thomson MO5 2.00232917
Thomson TO7 2.16828
Thomson TO7/70 2.16828
Tandy TRS80 2.16828
Hector HRX 2.16927

[djes]

Un test amusant avait été fait sur l'hebdomadaire Hebdogiciel, n°61 de décembre 1984, dans l'article "20 ordinateurs sur le grill".
Voici le listing du programme de test:

10 A=2
20 FOR N=1 TO 20
30 A=SQR(A)
40 NEXT N
50 FOR N=1 TO 20
60 A=A^2
70 NEXT N
80 PRINT A

Le résultat doit normalement être 2 mais nos chères machines donnaient toutes un résultat faux. Un classement des micros fût fait, du plus approchant au plus éloigné. Le TI-99/4A, et l'EXL-100 arrivèrent en tête avec un résultat de 1.999999924. La raison en est simple, les calculs arithmétiques sont faits avec une précision de 14 chiffres sur le TI-99/4A, contre 8 chiffres pour la plupart des autres micro-ordinateurs de la même époque.

Les résultats du test:
Texas Instruments TI-99/4A 1.999999924
Exelvision EXL-100 1.999999924
Canon X-07 19999997741097
Canon V20 1.99999977
Yashica (MSX) 1.99999977
Amstrad 464/6128 1.999433
Atari 800XL 1.99765243
Sinclair ZX-81 2.000446
Sinclair Spectrum 2.000446
Apple //e 2.00232917
Apple //c 2.0023291
Commodore C64 2.00232917
Oric Atmos 2.00232917
Commodore Vic-20 2.00232917
Thomson MO5 2.00232917
Thomson TO7 2.16828
Thomson TO7/70 2.16828
Tandy TRS80 2.16828
Hector HRX 2.16927

Es-tu bien sûr d'avoir correctement retranscris le test ?
Je sens que je vais encore recevoir une banane dédicacée moi...

[comtois]

il fonctionne très bien ton test

Code : Tout sélectionner

A.d=2
For N=1 To 20
A=Sqr(A)
Next N
For N=1 To 20
A=Pow(A,2)
Next N
Debug A 

[djes]

comtois!

[Backup]

il fonctionne très bien ton test

Code : Tout sélectionner

A.d=2
For N=1 To 20
A=Sqr(A)
Next N
For N=1 To 20
A=Pow(A,2)
Next N
Debug A 

pfff !

mais pourtant : a=a*a est bien egale a A=Pow(A,2) non ?

et a=a/a est bien egale a A=Sqr(A) non ?

la difference, c'est l' utilisation d'une variable pour le Stockage...

et alors , est-ce normal d'etre bloqué par ça ?

[djes]

Regarde MIEUX! (va-t-il trouver?)

[Backup]

Regarde MIEUX! (va-t-il trouver?)

tu parle du fait de commencer par faire la racine2 avant la puissance2 ??

[Chris]

et a=a/a est bien egale a A=Sqr(A) non ?

T'es sûr de ça?

A = 5, donc A x A est égal à 5 x 5 = 25

donc, A = 25 à partir de mantenant

ensuite, A / A est donc égal à 25 / 25 = ...... 1, et pas 5!!!!!

[djes]

Regarde MIEUX! (va-t-il trouver?)

tu parle du fait de commencer par faire la racine2 avant la puissance2 ??

Gagné
Du coup tu vas peut-être enfin comprendre pourquoi les radians sont mieux que les degrés

[Octavius]

En fait il y a deux grosses erreurs dans ta retranscription de cette épreuve.

tu parle du fait de commencer par faire la racine2 avant la puissance2 ??

Oui c'est même très important! Regarde tout simplement une courbe correspondant à l'équation y=x^2 et une courbe correspondant à l'équation y=RacineCarrée(x) : la pente n'est pas du tout la même! Tu t'es très vite confronté à de grands nombres alors que le test d'origine les évite.

Secundo, comme l'a montré Chris, tu écris r=r/r, or quelque soit r, r/r=1 !! La racine carrée d'un nombre ne se calcule pas avec une division. Si tu avais voulu utiliser ton r d'origine comme diviseur ça n'aurait pas marché non plu :

Code : Tout sélectionner

r.d=2
R.d=r
CallDebugger
For a=1 To 4
  R=R*R
Next a

Debug  R

For a=1 To 4
  R=R/r
Next a

Debug  R

A la fin tu ne retrouves toujours pas ton r d'origine, mais systématiquement 1, quelque soit la valeur initiale de r.

[Backup]

ben je suis un peu fatigué ces derniers temps

bien sur qu'un nombre divisé par lui meme donne 1 . pfffffff ! je suis grave des fois