Discussion :

[sone47]

bonjour,
je me demandais si la notation ca2 (assez ingenieuse ) a été touvé en vu de pouvoir faire des operations arithmetiques avec signes et non signes et de pouvoir representer d'une seule maniere le zero ou bien si en tout premier lieu elle a été élaboré pour le probleme du zéro et qu'ensuite on a remarqué qu'elle fonctionnait parfaitement pour le calcul.
Merci
ce n'est peut etre pas le bon forum, mais je pense avoir plus de reponses ici..

[Thierry Chappuis]

Pardonne-moi mon inculture, mais je ne sais pas ce qu'est la notation ca2? et Goggle ne m'en dit pas beaucoup plus... Pourrais-tu expliciter un peu?

Thierry

[stephl]

Pardonne-moi mon inculture, mais je ne sais pas ce qu'est la notation ca2? et Goggle ne m'en dit pas beaucoup plus... Pourrais-tu expliciter un peu?

Thierry

Je penche pour "complément à 2" mais sans aucune certitude...

[Thierry Chappuis]

Je penche pour "complément à 2" mais sans aucune certitude...

S'il s'agit du "complément à 2", je pense que cette manière de représenter les nombres négatifs a été développée afin de faciliter les calculs arthiméthiques de base. En effet, il n'est par exemple pas nécessaire d'avoir une instruction spécifique pour la soustration:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nb1 - nb2

devient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nb1 + (-nb2)

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nb1 + (~nb2) + 1

Maintenant, d'un point de vue historique, je ne sais pas ce qui est à l'origine de cette méthode, mais elle permet de simplifier l'architecture des processeurs.

Thierry

[sone47]

Oui c'est bien du complement a 2 dont je parlais.
mais étant donné que la difference fondamentale avec la precedente notation utilisée (complement a 1) est qu'il n'y a qu'une seule facon de representer le zero (0000 en ca2 contre 1000 ou 0000 en ca1), je me demandais si a l'origine les recherches vers cette notation(CA2) ont été pour ce cas precis et qu'ensuite on a remarqué que cela etait tres util pour les calculs signes non signes ou alors si on a cherche une solution pour le tout des le debut.

[Jean-Marc.Bourguet]

Le complement a la base a ete utilise pour pouvoir faire des soustractions avec les calculatrices mecaniques au XVII ou XVIIIieme siecle. La base utilisee etait a l'epoque 10. Je ne sais pas si la technique etait connue avant.

[sone47]

J'ai une deuxieme interrogation qui porte sur un cours d'assembleur diffusé sur le site. Dedans est decrit un bug en C et je voudrai savoir ce qu'il en était aujourd'hui avoir des avis dessus:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
"
char ch;
while( (ch = fgetc(fp )) != EOF ) {
/* faire qqch avec ch */
"
}

"On peut se demander pourquoi est-ce que la fonction renvoie un int puisqu'elle
lit des caractères? La raison est qu'elle renvoie normalement un char
(étendu à une valeur int en utilisant l'extension de zéro). Cependant, il y a
une valeur qu'elle peut retourner qui n'est pas un caractère, EOF. C'est une
macro habituellement dénie comme valant −1. Donc, fgetc() retourne soit
un char étendu à une valeur int (qui ressemble à 000000xx en hexa) soit
EOF (qui ressemble à FFFFFFFF en hexa).
Le problème avec le programme de la Figure 2.2 est que fgetc() renvoie
un int, mais cette valeur est stockée dans un char. Le C tronquera alors
les bits de poids fort pour faire tenir la valeur de l'int dans le char. Le
seul problème est que les nombres (en hexa) 000000FF et FFFFFFFF seront
tous deux tronqué pour donner l'octet FF. Donc, la boucle while ne peut pas
distinguer la lecture de l'octet FF dans le fichier et la fin de ce fichier.
Ce que fait exactement le code dans ce cas change selon que le char est
signé ou non. Pourquoi? Parce que ligne 2, ch est comparé avec EOF. Comme
EOF est un int1, ch sera étendu à un int afin que les deux valeurs comparées
soient de la même taille2. Comme la Figure 2.1 le montrait, le fait qu'une
variable soit signée ou non est très important.
Si le char n'est pas signé, FF est étendu et donne 000000FF. Cette valeur
est comparée à EOF (FFFFFFFF) et est différente. Donc la boucle ne finit
jamais!
So le char est signé, FF est étendu et donne FFFFFFFF. Les deux valeurs
sont alors égale et la boucle se termine. Cependant, comme l'octet FF peut
avoir été lu depuis le fichier, la boucle peut se terminer prématurément.
La solution à ce problème est de défnir la variable ch comme un int,
pas un char. Dans ce cas, aucune troncation ou extension n'est effectuée à
la ligne 2. Dans la boucle, il est sans danger de tronquer la valeur puisque
ch doit alors être réellement un octet." (paragraphe issu du cours)