Plus la tâche est simple à première vue, moins le développeur réfléchit à la façon de l'implémenter correctement, et l'erreur commise, au mieux, est découverte tardivement, au pire - elle n'est pas du tout remarquée. Il s'agira d'une de ces tâches, à savoir la division fractionnaire et la mise à l'échelle dans les contrôleurs qui prennent en charge l'arithmétique exclusivement entière.
Pourquoi les programmeurs d'applications ne prêtent pas attention aux subtilités du calcul dans des conditions d'une telle arithmétique, une question. Je me risquerai seulement à suggérer que, selon toute vraisemblance, l’habitude de faire des calculs sur la calculatrice affecte… En tout cas, avec une régularité enviable, «j’ai le bonheur» de voir comment les collègues de l’atelier marchent sur le même râteau. Ce matériau vise à neutraliser le même "râteau".
En arithmétique entière, le résultat de la division d'un entier par un autre est composé de deux nombres - le quotient et le reste. Si nous éliminons le reste de la division, nous obtenons le résultat, en valeur absolue, arrondi à un entier plus petit.
Réalisant des calculs avec des fractions, ce moment est souvent négligé et, ayant manqué, ils subissent des pertes dans la précision des calculs. De plus, la précision des calculs diminue avec l'augmentation de la valeur du diviseur. Par exemple, ce 53/13, ce 64/13 donnera 4, bien que, en fait, le quotient de la division de la deuxième fraction soit beaucoup plus proche de 5.
En fait, l'arrondi du résultat à l'entier le plus proche est simple à organiser. Pour ce faire, il suffit de doubler le reste de la division, de la résumer avec elle-même, puis de la diviser à nouveau par le même nombre par lequel elle a été initialement divisée, et d'ajouter le quotient de cette division au quotient obtenu à partir de l'opération de division initiale.
Dans le premier exemple simple, je vais montrer comment un tel arrondi est implémenté dans un logiciel en utilisant l'exemple du calcul du rapport de deux quantités
En tenant compte du fait que de tels calculs dans le programme peuvent être requis à plusieurs reprises, nous implémentons l'algorithme de calcul dans un format adapté pour être intégré dans un sous-programme.
Pour l'exécution correcte des calculs intermédiaires nécessaires à cela, un tableau de cinq registres sera nécessaire, nous le désignerons par le terme TEMP [0..4]. Pourquoi cinq et pas moins, je vais vous expliquer un peu plus bas.
Algorithme d'actions:
1. TEMP[2]= A 2. TEMP[3]= B ----- 3. TEMP[0,1]= TEMP[2]/TEMP[3] 4. TEMP[1,2]= TEMP[1]*2 5. TEMP[4]= 0 6. TEMP[1..4]= TEMP[1,2]/TEMP[3,4] 7. TEMP[0]= TEMP[0]+TEMP[1] ----- 8. Y= TEMP[0]
Les étapes 3 à 7 peuvent être déplacées vers un sous-programme.
Si vous le souhaitez, le résultat peut être enregistré directement en additionnant TEMP [0] avec TEMP [1] en dehors du sous-programme de calcul. C'est sans principes. La seule chose à garder à l'esprit est qu'avec beaucoup du même type de calculs, la suppression de l'opération d'ajout au corps principal du programme peut entraîner une augmentation de la quantité de mémoire de programme utilisée par celui-ci.
Alors pourquoi a-t-il fallu jusqu'à 5 registres pour le calcul intermédiaire? Et l'opération de sommation du reste de la division par elle-même, comme mentionné précédemment, est remplacée par la multiplication du reste par deux? Très simple - pour fonctionner avec un ensemble illimité d'entiers.
Je m'explique: si nous divisons, par exemple, le nombre 32767 par -32768 dans le reste, nous obtenons 32767, et le résultat de son ajout dépassera sans aucun doute la plage des nombres entiers.
C'est-à-dire que le reste doublé d'une division entière d'une fraction dans l'intérêt d'arrondir le résultat d'une telle division doit toujours être présenté en format double entier.
À suivre ...