Soustraction en BASIC

un pet, un vic, un 64...

Modérateur : Politburo

Avatar de l’utilisateur
C.Ret
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1920
Inscription : 31 mai 2008 23:43
Localisation : N 49°22 E 6°10

Re: Soustraction en BASIC

Message par C.Ret » 11 oct. 2016 18:44

Voilà c'est bien ça, il faut utilise les bonnes librairies, les bon type et bons formats...

... ou à défaut un bon PRINTUSING des familles !

Et un nombre décimal, mêm s'il ne conporte que trois ou quatre décimales, peut être un gros souci, surtout s'il n'est pas un nombre rond dans le système binaire de représentation des nombres.

30.55050 dans la notation interne iEEE 756 d'un Commodore 8bits est représenté de la façon suivante :

Code : Tout sélectionner

Bits  Value                     Designation
31    0                          (bit de signe  + )   
30-23 10000011                   (Exposant de 2)  ici  4 : positif complément de 128)     2^(+4)  soit 131 
22- 0 1.11101000110011101101100  (Signifiant  t)  ici 1.9094062
                                 (Notez chers amis qu'il y a ici 23 bits, 
                                  en fait le 1. n'est pas mémorisé car tous les nombres iEEE commencent par ce 1.
                                  on gange donc un bit par cette astuce - Commodore are cheap computers for the more !

Soit en HEX : 41F4676C

En effet 30.55050 ~= +1.9094062 x 2^4, les Commodore pensent en base deux et pas autrement. Donc ce nombre ne peut être qu'approché vu le nombre limité du signifiant :  N= t x 2^e      

Pour être exacte, il aurait fallu que le Commodore sache mémoriser t = 1.90940625 exactement. Or ce n'est pas possible.

d.dddddddd         b.bbbbbbbbbbbbbbbbbbbbbbb
1.90940625  il va #1.                       b  reste .90940625 que je multiplie par 2
1.81881250  il va # .1                      b  reste .8188125
1.63762500  il va #   1                     b  reste .637625
1.27525000  il va #    1                    b  reste .27525            
0.55050000  il va #     0                   b  reste .55050
1.10100000  il va #      1                  b  reste .101
0.20200000  il va #       0                 b  reste .202
0.40400000  il va #        0                b  reste .404
0.80800000  il va #         0               b  reste .808
1.61600000  il va #          1              b  reste .616
1.23200000  il va #           1             b  reste .232
0.46400000  il va #            0            b  reste .464
0.92800000  il va #             0           b  reste .928
1.85600000  il va #              1          b  reste .856
1.71200000  il va #               1         b  reste .712
1.42400000  il va #                1        b  reste .424
0.84800000  il va #                 0       b  reste .848
1.69600000  il va #                  1      b  reste .696
1.39200000  il va #                   1     b  reste .392
0.78400000  il va #                    0    b  reste .784
1.56800000  il va #                     1   b  reste .568
1.13600000  il va #                      1  b  reste .136
0.27200000  il va #                       0 b  reste .272
0.54400000  il va #                        0b  reste .544  (et nous sommes à la précision maximale d'un CBM )
1.08800000  il va #-.-----------------------1                              reste .088
0.17600000  il va #-.----------------------- 0                             reste .176
0.35200000  il va #-.-----------------------  0                            reste .352
0.70400000  il va #-.-----------------------   0                           reste .704
1.40800000  il va #-.-----------------------    1                          reste .408
0.81600000  il va #-.-----------------------     0      

et ainsi de suite

On arrive à T =   #1.1110100011001110110110010001011010000111001010110000   mais il faut 64 bits, ce qui est un format double de ce qui est disponible sur les Cheap Business Machines !


Donc, non, 30.55050 n'est pas qu'un simple nombre décimal à 4 ou 5 décimal, c'est bien plus compliqué que cela le calcul numérique électronique.

Et donc, préciser le format souhaité, par exemple à l'aide d'un simple PRINT USING ou SCANF ou FORMAT, n'est pas tricher c'est juste une question de bon sens.

Sinon c'est participer à l'inflation des bits, et des très très grands n'importe-quoi giga truc d'aujourd'hui où avec seulement 5 Go de RAM on ne peut plus ouvrir plus de trois applications sans faire exploser la batterie de son Samsung !
SHARP PC-1211 + CE-121 + CE-122. | VIC 20 Commodore 128D + Printer P-803. | TI-57 LCD | TI-74 BasiCalc | TI-92 II | HP-15C | HP-28S + HP82240A | HP-41C + (2 memory + stat + IR) modules. | HP Prime Wireless Graphing Calculator . .Sommaire des M.P.O.. . Sommaire du P.C.T.M. .

Avatar de l’utilisateur
Fabrice Montupet
Administrateur
Administrateur
Messages : 11378
Inscription : 17 mai 2002 11:39
Localisation : Nevers - France

Re: Soustraction en BASIC

Message par Fabrice Montupet » 11 oct. 2016 21:00

C.Ret a écrit :Et donc, préciser le format souhaité, par exemple à l'aide d'un simple PRINT USING ou SCANF ou FORMAT, n'est pas tricher c'est juste une question de bon sens.
Ton explication ne me convainc pas. Je reste sur l'idée que le PRINT USING est, dans le cas présent, un subterfuge d'affichage qui masque inexactitude du calcul.

Avatar de l’utilisateur
C.Ret
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1920
Inscription : 31 mai 2008 23:43
Localisation : N 49°22 E 6°10

Re: Soustraction en BASIC

Message par C.Ret » 11 oct. 2016 21:13

Nous sommes d'accord sur un point, ce que j'appelle bon sens, c'est bien un subterfuge pour masquer les limites du calcul électronique :)
Dernière édition par C.Ret le 11 oct. 2016 21:38, édité 1 fois.
SHARP PC-1211 + CE-121 + CE-122. | VIC 20 Commodore 128D + Printer P-803. | TI-57 LCD | TI-74 BasiCalc | TI-92 II | HP-15C | HP-28S + HP82240A | HP-41C + (2 memory + stat + IR) modules. | HP Prime Wireless Graphing Calculator . .Sommaire des M.P.O.. . Sommaire du P.C.T.M. .

Avatar de l’utilisateur
Fabrice Montupet
Administrateur
Administrateur
Messages : 11378
Inscription : 17 mai 2002 11:39
Localisation : Nevers - France

Re: Soustraction en BASIC

Message par Fabrice Montupet » 11 oct. 2016 21:16

^_^

Avatar de l’utilisateur
Pocket
Administrateur
Administrateur
Messages : 6182
Inscription : 24 mai 2002 16:55
Localisation : Toulouse
Contact :

Re: Soustraction en BASIC

Message par Pocket » 11 oct. 2016 21:19

Salut,

Le PRINT USING est une directive d'affichage de nombre avec une précision prédéfinie et rien d'autre.

Par exemple, si A = 3.1415 un PRINT USING ###.## de A affichera 3.14, mais cela ne permet au mieux d'affirmer que : 3.135 <= A < 3.145

A+
Pocket, voit tout, sait tout, lit l'avenir dans les entrailles d'une base phpBB ...
Image

Avatar de l’utilisateur
Ythunder
Fonctionne à 14400 bauds
Fonctionne à 14400 bauds
Messages : 6029
Inscription : 09 août 2008 17:46
Localisation : 03

Re: Soustraction en BASIC

Message par Ythunder » 11 oct. 2016 21:28

J'ai le même avis que Fabrice, le PRINT USING empli juste une fonction d'arrondi pour un affichage de type formaté, donc c'est une sorte de leurre, on va dire juste pour le plaisir des yeux.
Je suis CHARLIE
Tell me boy, do you have a room, in your heart, for the Computer boom...

Avatar de l’utilisateur
phm
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 660
Inscription : 08 avr. 2016 18:36
Localisation : Est Parisien

Re: Soustraction en BASIC

Message par phm » 12 oct. 2016 18:18

exemple en SQL server :

Image

La 3e colonne devrait donner 0 ...
J'ai converti en chaîne de caractère pour bien voir que c'est SQL qui faute.
HEWLETT-PACKARD : The best CANON : X-07 X-730 X-711 XM-101 XP-120F XP-140 XP-110F
AMSTRAD : CPC-464 CPC-6128 ATARI : STF DAI Indata
Mais aussi CASIO SHARP TEXAS INSTRUMENTS

Avatar de l’utilisateur
pir2
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 4683
Inscription : 31 oct. 2006 16:08
Localisation : 67310 Westhoffen
Contact :

Re: Soustraction en BASIC

Message par pir2 » 12 oct. 2016 18:22

Ben justement, c'est dans ces cas-là qu'il ne faut pas déclarer en FLOAT, c'est le principe même du Float qui génère les arrondis.
Image
Image

Avatar de l’utilisateur
phm
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 660
Inscription : 08 avr. 2016 18:36
Localisation : Est Parisien

Re: Soustraction en BASIC

Message par phm » 12 oct. 2016 18:28

pir2 a écrit :Ben justement, c'est dans ces cas-là qu'il ne faut pas déclarer en FLOAT, c'est le principe même du Float qui génère les arrondis.
:?: :?: :?:
As tu déjà développer des programmes ?
Parce-que là je comprends pas du tout la remarque ....

Ou alors c'est sur un ton comique ?
HEWLETT-PACKARD : The best CANON : X-07 X-730 X-711 XM-101 XP-120F XP-140 XP-110F
AMSTRAD : CPC-464 CPC-6128 ATARI : STF DAI Indata
Mais aussi CASIO SHARP TEXAS INSTRUMENTS

Avatar de l’utilisateur
pir2
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 4683
Inscription : 31 oct. 2006 16:08
Localisation : 67310 Westhoffen
Contact :

Re: Soustraction en BASIC

Message par pir2 » 12 oct. 2016 18:59

Ben si, j'ai déjà développé, quand même, c'est (encore un peu) mon métier :)

Si j'ai besoin d'une précision monétaire, avec des soustractions exactes, je type mes données en conséquence.

Pour l'exemple du SQL, du Number (20,10) ou plus, et pas du Float.

Si seuls les ordres de grandeurs m'importent, alors le Float peut m'aller, mais les différences évoquée ici ne me gêneront pas.

Un autre exemple, en java, pour traiter des nombres représentant des dates (nombre de millisecondes depuis le 1/1/1970), je n'utilise pas de Int, ni des Long mais des BigInteger.
C'est donc bien en fonction de ce que l'on développe qu'on choisi le bon type.

En Basic (puisque tout est partit de la soustraction Basic), je ne connais pas les dernières évolutions et typages de données, mais ce n'est certainement pas du Float que j'aurais utilisé pour des programmes comptables ;)
Image
Image

Avatar de l’utilisateur
phm
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 660
Inscription : 08 avr. 2016 18:36
Localisation : Est Parisien

Re: Soustraction en BASIC

Message par phm » 12 oct. 2016 21:39

pir2 a écrit : Pour l'exemple du SQL, du Number (20,10) ou plus, et pas du Float.
Mon exemple reprends la définition des champs des tables SQL d'une GPAO prédéfini que je ne contrôle pas et les valeurs numériques sont soit en INT soit en FLOAT.
Ta solution serai trop simple !
Après 7 années d'utilisation de ce langage, j'ai effectivement constaté la nécessaire de jouer du CONVERT / CAST pour arriver à ses fin.
HEWLETT-PACKARD : The best CANON : X-07 X-730 X-711 XM-101 XP-120F XP-140 XP-110F
AMSTRAD : CPC-464 CPC-6128 ATARI : STF DAI Indata
Mais aussi CASIO SHARP TEXAS INSTRUMENTS

Nikass
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 724
Inscription : 12 nov. 2015 23:00
Localisation : 34 et trouducul du 31

Re: Soustraction en BASIC

Message par Nikass » 12 oct. 2016 22:37

C.Ret a écrit :Les fonctions EXP, LOG, SIN, COS et ACS sont particulièrement mauvaises, en plus des soucis liés à la représentation interne des nombres, il y a aussi franchement une limite à leur justesse dès les 3-ième ou 4-ième décimale.
Salut !

J'dis ça, je dis rien, j'suis pas allé décompiler l'interpréteur, mais pour en avoir fait des pires... ça serait pas tout simplement des tables précalculées associées à des équivalents polynômiaux au point de calcul, dans ces machins là ?

a+

Avatar de l’utilisateur
C.Ret
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1920
Inscription : 31 mai 2008 23:43
Localisation : N 49°22 E 6°10

Re: Soustraction en BASIC

Message par C.Ret » 13 oct. 2016 12:07

Oh! Oui à tous les coups, car le calcul des fonctions trigo ne prend que quelques dizaines d'octets (73 octets) pour SIN (et COS qui est basé sur celui de SIN décalé de PI/2.

Par ailleurs, la sous-routine pour calculer le SIN utilise FAC#1 ($61 to $66) comme argument puis pour fournir le résultat.
A priori, il s'agirait d'une décomposition polynomiale du SIN.
SHARP PC-1211 + CE-121 + CE-122. | VIC 20 Commodore 128D + Printer P-803. | TI-57 LCD | TI-74 BasiCalc | TI-92 II | HP-15C | HP-28S + HP82240A | HP-41C + (2 memory + stat + IR) modules. | HP Prime Wireless Graphing Calculator . .Sommaire des M.P.O.. . Sommaire du P.C.T.M. .

Avatar de l’utilisateur
Metalion
Fonctionne à 300 bauds
Fonctionne à 300 bauds
Messages : 156
Inscription : 18 févr. 2008 14:46
Localisation : Belgique & Nord

Re: Soustraction en BASIC

Message par Metalion » 14 oct. 2016 11:30

Nikass a écrit :
C.Ret a écrit :Les fonctions EXP, LOG, SIN, COS et ACS sont particulièrement mauvaises, en plus des soucis liés à la représentation interne des nombres, il y a aussi franchement une limite à leur justesse dès les 3-ième ou 4-ième décimale.
J'dis ça, je dis rien, j'suis pas allé décompiler l'interpréteur, mais pour en avoir fait des pires... ça serait pas tout simplement des tables précalculées associées à des équivalents polynômiaux au point de calcul, dans ces machins là ?
C'est effectivement la solution la plus simple.

Pour un développement en assembleur, j'avais créé une table de 90 valeurs (une par degré) de sinus, en codant le résultat sur 2 octets représentant la valeur décimale du sinus multipliée par 65536 (donc par exemple SIN(11°) = 0,190890 était codé $30D9). La table faisait donc 180 octets, et les valeurs intermédiaires était calculées par simple linéarité. La précision du résultat était assez correcte (4e décimale), sauf pour les valeurs inférieures à 1 degré.
Daewoo DPC-200 (MSX1)
Sony HB-F9P (MSX2)
Panasonic FS-A1WX (MSX2+)

Répondre

Revenir vers « Commodore 8bits »

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 2 invités