Réduire des fractions
GW-Basic, utilisé par PC-Basic
Programme avec Texte Seulement
PC-BASIC
Nous nous souvenons tous du processus de l'école élémentaire : pour réduire une fraction, vous devez trouver le plus grand diviseur commun (PGCD) du numérateur et du dénominateur, c'est-à-dire la plus grande valeur entière qui se divise de manière égale entre le numérateur et le dénominateur. Puis divisez-les tous les deux par le PGCD.
Les calculatrices et les ordinateurs, auxquels certains d'entre nous n'avaient pas accès à l'école primaire, accélèreront grandement le processus.
À bien y penser, en utilisant un algorithme similaire à celui que nous venons de décrire, un ordinateur peut rapidement convertir un nombre décimal en une fraction réduite.
Prenez 0,4, par exemple. C'est quatre dixièmes, ou 4/10, ce qui réduit à 2/5. Ou que diriez-vous de 0,68 ? C'est soixante-huit centièmes, ou 68/100, ce qui réduit à 17/25.
Écrivons un programme pour à la fois réduire les fractions et convertir les nombres décimaux en fractions.
Après avoir saisi une décimale ou une fraction, une boucle FOR/NEXT s'occupe de trouver, sinon le PGCD, les facteurs communs à diviser entre le numérateur et le dénominateur jusqu'à ce que la fraction soit complètement réduite (voir les lignes 190 à 310). Notez que si la boucle s'exécute trop de fois, le programme se termine (voir ligne 195).
Nous utiliserons des variables en double précision—notées par le signe dièse (#) apposé à la fin des noms de variables—pour éviter, autant que possible, la notation E (scientifique). Les variables à double précision autorisent des nombres plus grands, bien qu'elles aient un coût : le programme s'exécute plus lentement et les variables utilisent plus de mémoire.
Il y a un autre coût, cependant, qui n'est pas aussi évident. GW-BASIC est parfois bizarre lors du stockage de valeurs numériques dans des variables à double précision. (La nature collante de Java avec les types de données numériques que nous avons mentionnés plus tôt commencera à sembler attrayante ici).
Par exemple, considérons le programme à deux lignes suivant :
10 INPUT A#
20 PRINT A#*10^7
Exécutez le programme et saisissez 123.323. Vous vous attendriez à ce que la sortie soit 1233230000. Mais à la place, vous voyez ce qui suit :
1233229980.46875
Lorsque GW-BASIC effectue des opérations, il affiche par défaut les résultats avec la plus grande précision. Pourtant, même si tous les nombres sont au format double précision, comme ceci :
10 INPUT A#
20 PRINT
A#*10#^7#
vous obtiendrez la même sortie bizarre de l'entrée 123.323.
Vous vous demandez probablement pourquoi cela se produit. Laissons Don Inman et Bob Albrecht, dans leur livre complet et magistral The GW-BASIC Reference (1990), l'expliquer :
Bien qu'épuisé, le manuel de référence d'Inman et Albrecht est un incontournable pour toute personne sérieuse à propos de la programmation GW-BASlC, les nombres sont stockés et les opérations sont effectuées sous forme binaire.
Les nombres entiers dans la plage appropriée peuvent être exprimés sous forme binaire sans perte de précision. Cependant, les nombres à simple et double précision ne peuvent pas toujours être convertis en une valeur équivalente exacte sous forme binaire. À moins que le nombre simple ou double précision puisse être exprimé comme la somme des puissances d'un nombre fini de puissances de 2, il y aura une erreur d'arrondi.
Dans FRACTION.BAS, nous nous assurons que ce type de sortie étrange ne se produit pas en interrogeant l'utilisateur sur le nombre de chiffres après la décimale ainsi qu'en tronquant les nombres à l'aide de la fonction INT - et en demandant à l'utilisateur de vérifier les étapes intermédiaires - où nécessaire.
Vous vous demandez peut-être pourquoi nous n'utilisons pas la fonction CINT pour arrondir, plutôt que la fonction INT pour tronquer. Le problème est que CINT a du mal à gérer les nombres à double précision, ce qui entraîne alors des erreurs de débordement et des exécutions terminées.
Malgré le manque d'automatisation, le programme est étonnamment efficace pour transformer les décimales en fractions réduites. En fait, avec certaines décimales que les calculatrices graphiques TI-84 refusent de convertir, comme 0,12345, qui est 2469/20000, FRACTION. BAS réduit correctement.
Mais beaucoup pourrait être fait pour rendre le programme plus convivial et robuste : moins de requêtes d'utilisateurs, une capacité à manipuler des nombres plus importants et des temps d'exécution plus rapides ne sont que quelques-uns des défis que vous voudrez peut-être relever.
