historique du ca2

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..

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

Citation:

---

Envoyé par mujigka

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...

Citation:

---

Envoyé par stephl

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:

---

nb1 - nb2

---

devient

Code:

---

nb1 + (-nb2)

---

ou

Code:

---

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

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.

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.

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:

---

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)

Citation:

---

Envoyé par 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

---

C'est un peu confu, ca presente comme chose certaine ce qui n'est qu'une implementation courante, mais le probleme decrit existe bien et les autres implementations autorisees ont un probleme symetrique.

Il n'y a peut etre trop rien a ajouter mais cela m'etonne de ne pas avoir été au courant avant dans des cours ou autre, y a t il d'autre subtilités a savoir?

Citation:

---

Envoyé par sone47

Il n'y a peut etre trop rien a ajouter mais cela m'etonne de ne pas avoir été au courant avant dans des cours ou autre, y a t il d'autre subtilités a savoir?

---

:rire: Enormement.

oui c'est vrai question absurde.

Citation:

---

Envoyé par 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:

---

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)

---

Je ne vois pas où est le bug, ni la subtilité. Le prototype de fgetc() est:

Code:

---

int fgetc (FILE *stream);

---

http://man.developpez.com/man3/fgetc.3.php

Cette fonction retourne donc un int. Point. Non?

Thierry

Citation:

---

Envoyé par mujigka

Je ne vois pas où est le bug, ni la subtilité. Le prototype de fgetc() est:

Code:

---

int fgetc (FILE *stream);

---

http://man.developpez.com/man3/fgetc.3.php

Cette fonction retourne donc un int. Point. Non?

Thierry

---

Le bug est d'assigner cet int dans un char car ca fusionne EOF avec 0xFF. Si char est non signe, on a une boucle infinie. Si char est signe, le caractere de code 0xFF (generalement ÿ dans les encodages utilises par les francophones) quitte la boucle.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Le bug est d'assigner cet int dans un char car ca fusionne EOF avec 0xFF. Si char est non signe, on a une boucle infinie. Si char est signe, le caractere de code 0xFF (generalement ÿ dans les encodages utilises par les francophones) quitte la boucle.

---

Certes, mais si le prototype de fgetc() spécifie que cette fonction retourne un entier de type int, la valeur retournée doit être affectée à une variable de type int. Je ne vois aucune raison d'affecter la valeur de retour de cette fonction à un char.

Thierry

Citation:

---

Envoyé par mujigka

Certes, mais si le prototype de fgetc() spécifie que cette fonction retourne un entier de type int, la valeur retournée doit être affectée à une variable de type int. Je ne vois aucune raison d'affecter la valeur de retour de cette fonction à un char.

---

Parce que ce qu'on lit c'est des caracteres...

Un autre aspect du meme probleme est que

Code:

---

1 2 3

int check(char c) { return getc() == c; }

---

ne va jamais retourner vrai si on a des char signes et que l'argument a une valeur negative (le jeu de caracteres de base est garanti d'avoir des valeurs positives, donc quelque chose comme getc() == 'a' va toujours fonctionner. Mais si tu sorts du jeu de base, getc() == 'é' peut toujours retourner 0).

Citation:

---

Envoyé par Jean-Marc.Bourguet

Parce que ce qu'on lit c'est des caracteres...

---

Justement, pas uniquement, à cause de EOF qui est une constante de type int. SUpposer qu'elle est représentable par un char, c'est faire une supposition sur la valeur de EOF.

Thierry

Citation:

---

Envoyé par mujigka

Justement, pas uniquement, à cause de EOF qui est une constante de type int.

---

:koi: J'aimerais bien savoir où tu veux en venir... Tu commences par ne pas voir le bug, je t'explique qu'il est d'assigner le résultat de getc à un char.

Tu dis alors ne pas voir pourquoi assigner le résultat de getc à un char, j'explique que ca peut parraître naturel -- même si c'est incorrect, j'ai déjà écrit juste avant que c'est un bug -- vu que c'est ce qu'on manipule et que stocker le résultat de getc dans un char peut sembler résoudre des bugs plus probable à déclencher si on a un char signé -- ce qui est le cas de la plupart des plateformes -- que le bug consistant à confondre 0xFF et EOF.

Et maintenant tu m'expliques que c'est un bug.

Citation:

---

SUpposer qu'elle est représentable par un char, c'est faire une supposition sur la valeur de EOF.

---

La valeur de EOF, c'est -1. Elle est représentable dans un char dans la plupart des implémentations. Le problème est qu'on veut que getc soit capable de retourner tous les char de manière distincte de EOF. Donc si un char c est disponible getc retourne (int)(unsigned char), sinon, il retourne EOF.

Citation:

---

Envoyé par Jean-Marc.Bourguet

:koi: J'aimerais bien savoir où tu veux en venir... Tu commences par ne pas voir le bug, je t'explique qu'il est d'assigner le résultat de getc à un char.

Tu dis alors ne pas voir pourquoi assigner le résultat de getc à un char, j'explique que ca peut parraître naturel -- même si c'est incorrect, j'ai déjà écrit juste avant que c'est un bug -- vu que c'est ce qu'on manipule et que stocker le résultat de getc dans un char peut sembler résoudre des bugs plus probable à déclencher si on a un char signé -- ce qui est le cas de la plupart des plateformes -- que le bug consistant à confondre 0xFF et EOF.

Et maintenant tu m'expliques que c'est un bug.



La valeur de EOF, c'est -1. Elle est représentable dans un char dans la plupart des implémentations. Le problème est qu'on veut que getc soit capable de retourner tous les char de manière distincte de EOF. Donc si un char c est disponible getc retourne (int)(unsigned char), sinon, il retourne EOF.

---

:oops: OK, je crois qu'on ne s'est pas compris dès le départ, ou plutôt que j'ai mal exprimé ma pensée. Je n'ai jamais voulu mettre en cause le bug présenté, ni même le commenter. Je voulais simplement préciser que ce bug n'aurait pas eu lieu si on avait respecté le prototype de fgetc() en affectant sa valeur de retour à un int. C'est tout!

Thierry

Citation:

---

Envoyé par mujigka

e crois qu'on ne s'est pas compris dès le départ

---

Je préfère ça... je commençais réellement à me demander si je manquais pas quelque chose.