Soustraction en BASIC

un pet, un vic, un 64...

Modérateur : Politburo

Avatar du membre
C.Ret
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 3404
Enregistré le : 31 mai 2008 23:43
Localisation : N 49°22 E 6°10

Re: Soustraction en BASIC

Message par C.Ret »

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 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
Avatar du membre
Fabrice Montupet
Administrateur
Administrateur
Messages : 11083
Enregistré le : 17 mai 2002 11:39
Localisation : Nevers - France

Re: Soustraction en BASIC

Message par Fabrice Montupet »

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 du membre
C.Ret
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 3404
Enregistré le : 31 mai 2008 23:43
Localisation : N 49°22 E 6°10

Re: Soustraction en BASIC

Message par C.Ret »

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 :)
Modifié en dernier par C.Ret le 11 oct. 2016 21:38, modifié 1 fois.
SHARP PC-1211 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
Avatar du membre
Fabrice Montupet
Administrateur
Administrateur
Messages : 11083
Enregistré le : 17 mai 2002 11:39
Localisation : Nevers - France

Re: Soustraction en BASIC

Message par Fabrice Montupet »

^_^
Avatar du membre
Pocket
Administrateur
Administrateur
Messages : 5940
Enregistré le : 24 mai 2002 16:55
Localisation : Toulouse
Contact :

Re: Soustraction en BASIC

Message par Pocket »

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 du membre
Ythunder
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 4549
Enregistré le : 09 août 2008 17:46
Localisation : 03

Re: Soustraction en BASIC

Message par Ythunder »

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.
Quand je lis ça "oui des passionnées qui modifie des machines pour en faire des moutons a 5 pattes qui n'ont plus rien a voir avec la machine d'origine afin de faire la video choc sur youtube..."

Ca me fait rire. Perso, je n'ai ni chaine youtube sur les machines et je n'ai aucun mouton à 5 pattes qui n'a pàlus rien a voir avec des machines d'origine. Mais à qui s'adressait on ?
Avatar du membre
phm
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1361
Enregistré le : 08 avr. 2016 18:36
Localisation : Est Parisien

Re: Soustraction en BASIC

Message par phm »

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 XR-100 XM-101 XP-110F XP-120F XP-130F XP-140

AMSTRAD CPC-464 CPC-6128 ATARI STF DAI Indata
Avatar du membre
pir2
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 4642
Enregistré le : 31 oct. 2006 15:08
Localisation : 67310 Westhoffen
Contact :

Re: Soustraction en BASIC

Message par pir2 »

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 du membre
phm
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1361
Enregistré le : 08 avr. 2016 18:36
Localisation : Est Parisien

Re: Soustraction en BASIC

Message par phm »

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 XR-100 XM-101 XP-110F XP-120F XP-130F XP-140

AMSTRAD CPC-464 CPC-6128 ATARI STF DAI Indata
Avatar du membre
pir2
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 4642
Enregistré le : 31 oct. 2006 15:08
Localisation : 67310 Westhoffen
Contact :

Re: Soustraction en BASIC

Message par pir2 »

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 du membre
phm
Fonctionne à 2400 bauds
Fonctionne à 2400 bauds
Messages : 1361
Enregistré le : 08 avr. 2016 18:36
Localisation : Est Parisien

Re: Soustraction en BASIC

Message par phm »

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 XR-100 XM-101 XP-110F XP-120F XP-130F XP-140

AMSTRAD CPC-464 CPC-6128 ATARI STF DAI Indata
Nikass
Fonctionne à 1200 bauds
Fonctionne à 1200 bauds
Messages : 941
Enregistré le : 12 nov. 2015 22:00
Localisation : trouducul du 31 et 34 aux lunes bleues

Re: Soustraction en BASIC

Message par Nikass »

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 du membre
C.Ret
Fonctionne à 9600 bauds
Fonctionne à 9600 bauds
Messages : 3404
Enregistré le : 31 mai 2008 23:43
Localisation : N 49°22 E 6°10

Re: Soustraction en BASIC

Message par C.Ret »

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 PC-1360 EL-5150 PC-E500 | Commodore C=128D | Texas Instruments Ti-57LCD Ti-74BASICalc Ti-92II Ti-58c Ti-95PROCalc Ti-30XPROMathPrint | Hewlett-Packard HP-28S HP-41C HP-15C HP-Prime HP-71B | CASIO fx-602p | NUMWORKS | Graphoplex Rietz Neperlog | PockEmul | Sommaire des M.P.O. | Ma...dov'il sapone.
Avatar du membre
Metalion
Fonctionne à 75 bauds
Fonctionne à 75 bauds
Messages : 63
Enregistré le : 18 févr. 2008 13:46
Localisation : Belgique & Nord

Re: Soustraction en BASIC

Message par Metalion »

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

Retourner vers « Commodore 8bits »