Le B ça suxx - Page 6

non mais ce qu'il veut c'est interdire l'overflow, ça n'a pas de rapport avec le fait que ce soit signé ou non (en caml les entiers sont signés et l'overflow est bien défini)

D'accord.

Mais bon je me pose la même question qu'en ./107 ^^

Hippopotame (./150) :

Pollux (./149) :
Ah non, je parle des entiers signés

Ouais ouais, je sais, tu te réfugies dans les entiers signés...

Mais bon tes entiers signés c'est pas grand chose d'autre que des couples (signe,entier) avec des lois un peu tordues mais pas trop, ya pas de quoi en faire une jaunisse.

même pas, tant que tu ne fais pas de comparaisons c'est rigoureusement équivalent aux entiers non signés, mais ce qui change c'est l'overflow, qui fait que du coup + n'est pas définie partout ; et comme dit sally ça n'a pas a priori de rapport avec le fait que ça soit signé, c'est juste que je me place depuis le début dans le cadre des entiers signés de C ^^

Hippopotame (./152) :
D'accord.

Mais bon je me pose la même question qu'en ./107 ^^

quel est le pb avec ./109 et ./110 ?

L'intérêt de ne pas autoriser l'overflow,c'est que c'est ce que le standard C définit pour les entiers signés.

D'ailleurs, quand on autorise l'overflow (genre -fwrapv avec GCC), l'ensemble des entiers signés est aussi un anneau isomorphe à un Z/2^{2^k}Z comme celui des non signés. (La division est différente, mais ça ne fait pas partie de la définition d'un anneau de toute façon.)

tant que tu ne fais pas de comparaisons c'est rigoureusement équivalent aux entiers non signés

Ouais on se demande même pourquoi ces cons ont mis dans les microprocesseurs des instructions mulu et muls, divu et divs.

c'est rigoureusement équivalent aux entiers non signés

Voui c'est un autre point qui me chatouille :
En fait entiers et entiers signés, c'est le même type. Ce sont les *lois* qui sont différentes. Il y a là une incohérence.

Bon sinon je comprends : tu veux que l'ensemble des positifs soit stable par + et *.


>>> N+N-N avec N entier est souvent optimisée en N (parce que l'overflow est undefined), alors que si il était défini, le compilateur ne pourrait pas faire de telles optimisations.

Voui mais alors ces deux expressions, "N+N-N" et "N", ne sont pas équivalentes au sens défini plus haut...

Kevin Kofler (./155) :
L'intérêt de ne pas autoriser l'overflow,c'est que c'est ce que le standard C définit pour les entiers signés.

C'est le contraire, ou alors c'est plus un standard, c'est une dictature.

Hippopotame (./156) :

tant que tu ne fais pas de comparaisons c'est rigoureusement équivalent aux entiers non signés

Ouais on se demande même pourquoi ces cons ont mis dans les microprocesseurs des instructions mulu et muls, divu et divs.

Parce que "ces cons" ont fait des instructions 16x16->32 bits, il suffirait bien entendu d'une seule multiplication s'ils s'étaient restreints à du 16x16->16 bits ^^ (pour la division c'est différent, je ne parlais que du +, - et * comme précisé au début du topic)

c'est rigoureusement équivalent aux entiers non signés

Voui c'est un autre point qui me chatouille :En fait entiers et entiers signés, c'est le même type. Ce sont les *lois* qui sont différentes. Il y a là une incohérence.

Pourquoi donc ?

Bon sinon je comprends : tu veux que l'ensemble des positifs soit stable par + et *.

voilà ^^ (même si le fait que ça soit une undefined behaviour et pas une exception qui serait lancée systématiquement complique un peu les choses en pratique)

>>> N+N-N avec N entier est souvent optimisée en N (parce que l'overflow est undefined), alors que si il était défini, le compilateur ne pourrait pas faire de telles optimisations.
Voui mais alors ces deux expressions, "N+N-N" et "N", ne sont pas équivalentes au sens défini plus haut...

En effet, parce que "équivalentes au sens défini plus haut" ça veut dire qu'on peut remplacer l'un par l'autre et inversement ; là pphd parle d'un remplacement dans un seul sens, comme défini dans ./124 ^^ On remplace une expression "dangereuse" par une expression "inoffensive" qui garde le même sens sur son domaine de définition, donc ce n'est jamais un problème.

Pourquoi donc ?

ben parce que ce n'est pas le type qui est différent mais les fonctions.

En effet, parce que "équivalentes au sens défini plus haut" ça veut dire qu'on peut remplacer l'un par l'autre et inversement ; là pphd parle d'un remplacement dans un seul sens, comme défini dans ./124 ^^ On remplace une expression "dangereuse" par une expression "inoffensive" qui garde le même sens sur son domaine de définition, donc ce n'est jamais un problème.

Ouais, on remplace une expression undefined par une expression qui a un sens.

Moi j'exige, quand j'écris 0/0, que le compilateur me fasse le café.

(enfin bon je vois bien la logique de la chose, mais ça parait fait tellement bizarrement)

Hippopotame (./158) :

Pourquoi donc ?

ben parce que ce n'est pas le type qui est différent mais les fonctions.

et est-ce que le type d'un entier 32 bit et d'un float 32 bit est différent ? après tout il n'y a que les fonctions qui changent...

En effet, parce que "équivalentes au sens défini plus haut" ça veut dire qu'on peut remplacer l'un par l'autre et inversement ; là pphd parle d'un remplacement dans un seul sens, comme défini dans ./124 ^^ On remplace une expression "dangereuse" par une expression "inoffensive" qui garde le même sens sur son domaine de définition, donc ce n'est jamais un problème.

Ouais, on remplace une expression undefined par une expression qui a un sens.

Moi j'exige, quand j'écris 0/0, que le compilateur me fasse le café.

(enfin bon je vois bien la logique de la chose, mais ça parait fait tellement bizarrement)

ben justement, le contrat qu'est la norme C te dit qu'à partir du moment où tu écris 0/0 (enfin plus précisément à partir du moment où tu l'exécutes) tu n'as plus le droit de te plaindre... bref ton optimiseur de code source n'est jamais qu'un compilateur qui suit la norme C, et qui a donc le droit de faire absolument ce qu'il veut lorsqu'il tombe sur une undefined behaviour, y compris le transformer en une expression valide -- ça reste dans son contrat


sinon pour voir pourquoi la norme est conçue comme ça tu peux voir un programme comme une fonction partielle, définie sur les entrées où il n'y a pas d'undefined behaviour ; exiger qu'une transformation du programme donne exactement la même fonction partielle, c'est trop contraignant -- on peut très bien transformer en une fonction partielle identique mais avec un domaine de définition potentiellement plus grand... (de toute façon on n'a jamais accès au domaine de définition d'une fonction sauf avec un interpréteur fait pour, donc que le domaine de définition soit plus grand n'a aucune incidence en pratique)

cela dit ce n'est pas indispensable non plus pour permettre les optimisations : après tout en ajoutant la contrainte de garder le même domaine de définition je pourrais très bien optimiser "n+n-n" en "let _ = n+n in n" [*], mais le let est clairement superflu parce qu'on se tape du comportement du programme modifié là où l'original faisait n'importe quoi...


[*] : et ça serait pas forcément une optimisation idiote, dans la mesure où ça se parallélise mieux : le résultat final est disponible immédiatement, et le n+n peut être exécuté en parallèle ; alors qu'avec la version originale il faut tout calculer avant d'avoir accès au résultat final

Pollux (./159) :
et est-ce que le type d'un entier 32 bit et d'un float 32 bit est différent ?

Moralement, oui.

Par exemple ton float peut être codé en BCD, à ce moment là on aura du mal à faire rentrer un entier dedans même si c'est le même nombre de bits.


Pour le reste, oky dokky, mais bon je persiste à trouver ça byzarre de s'autoriser des expression incorrectes comme ça.

Hippopotame (./160) :

Pollux (./159) :
et est-ce que le type d'un entier 32 bit et d'un float 32 bit est différent ?

Moralement, oui.
Par exemple ton float peut être codé en BCD, à ce moment là on aura du mal à faire rentrer un entier dedans même si c'est le même nombre de bits.

Donc en gros tu appelles "type" le nb d'éléments distincts ? ^^

Pour le reste, oky dokky, mais bon je persiste à trouver ça byzarre de s'autoriser des expression incorrectes comme ça.

Tu veux dire le fait de ne pas déclencher une exception en présence d'erreurs ? Oui, c'est très byzarre, et c'est d'ailleurs une source de problèmes ^^
Cela dit sur le plan théorique ça ne pose pas de pb, puisque de toute façon on raisonne sur des programmes qui ne font pas n'importe quoi, donc entre ça ou un langage qui lancerait une jolie exception il n'y a pas trop de différence ; ce qui pose pb c'est quand on teste un programme buggé, si c'est du C on ne peut pas savoir si y a un pb ou pas...

Et puis le fait que ça soit une undefined behaviour ou une exception n'a pas d'incidence sur ce qu'on a dit dans le reste du topic, je crois, donc ça reste valable pour tous les types entiers qui lancent une exception en cas d'overflow -- sous réserve évidemment que l'exception ne soit pas rattrapée par le reste du programme, parce qu'à ce moment-là ne pas lancer d'exception change radicalement le sens du programme.

>>> Donc en gros tu appelles "type" le nb d'éléments distincts ? ^^

L'ensemble mathématique.

>>> Tu veux dire le fait de ne pas déclencher une exception en présence d'erreurs ?

Pas seulement.

Hippopotame (./162) :
>>> Donc en gros tu appelles "type" le nb d'éléments distincts ? ^^
L'ensemble mathématique.

Ben il est en bijection s'il y a le même nb d'éléments...

>>> Tu veux dire le fait de ne pas déclencher une exception en présence d'erreurs ?

Pas seulement.

mais encore ?

>>> Ben il est en bijection s'il y a le même nb d'éléments...

mais non voyons.
les bits n'ont pas la même saveur et tu le sais bien.


>>> mais encore ?

toute une façon de faire.

Hippopotame (./164) :
>>> Ben il est en bijection s'il y a le même nb d'éléments...

mais non voyons.les bits n'ont pas la même saveur et tu le sais bien.

surtout les bits de poids fort

>>> mais encore ?

toute une façon de faire.

je vois pas trop ce que tu veux dire ^^

oui je vois bien que tu ne vois pas trop, en plus je ne suis pas sûr de voir moi même, à part que c'est fumeux.

Il doit manquer à l'informatique des concepts de "canonique", "naturel", si prisés en maths, notamment dans la théorie des catégories. Ca éviterait d'injecter bêtement des int dans des floats.

Hippopotame (./166) :
oui je vois bien que tu ne vois pas trop, en plus je ne suis pas sûr de voir moi même, à part que c'est fumeux.

Je crois que tout le monde est d'accord sur ce sujet.

Hippopotame (./125) :
2) Vas dire ça à un transistor

flemme de lire tout en détail (trop de sommeil en retard, et pas assez de prévu cette nuit), mais on réfléchit de plus en plus à supprimer la base 2 et à la remplacer par la base 10 pour les spécifications des flottants

Oué mais ca sera surtout implanter en logiciel....

La spécification pour les flottants décimaux en C ne vise pas à remplacer les floats existants, il y a un type à part etc.
Bien sûr, dans TIGCC, les floats sont déjà décimaux.

Pour moi, cette norme servira surtout pour les noeunoeu qui ne comprennent pas ce que c'est qu'un flottant.

ou pour les neuneus qui ont besoin de faire des calculs exacts en finance... (et qui ont besoin de plus de 64 bits de précision)

Ils n'ont pas "besoin" de plus de 64 bits de précision ^^

Mais en quoi le calcul serait plus "exact" en base 10 qu'en base 2 ?

Pas de conversion binaire<->décimal.
L'entrée-sortie n'est pas faite en binaire normalement.

Sally (./173) :
Ils n'ont pas "besoin" de plus de 64 bits de précision ^^

C'est possible Enfin par contre 64 bits (exposant compris) en BCD ça ferait vraiment léger...

Hippopotame (./174) :
Mais en quoi le calcul serait plus "exact" en base 10 qu'en base 2 ?

Parce qu'en finance les quantitées qu'on manipule sont exactes en base 10 et pas en base 2 ? Un truc comme "3.5 %" n'est pas exact en base 2...

Mauvais example, c'est 0b11,1%.
Avec 3,4%, en revanche, ça marche.

non, c'est 0b0.0000100011110101110000101000111101011100001010001111010111000010... ^^ 3.5% = 0.035, c'est plus logique de représenter le pourcentage en termes de fraction qu'en termes de points
(et puis quoi qu'il en soit ça prouve bien que la transformation points->fraction pose problème, puisque le pourcentage peut-être exact [ou même entier] mais la fraction inexacte)

S'ils veulent des nombres exacts il faut qu'ils utilisent des rationnels, pas des float de toute façon (les quantités qu'on manipule sont toujours exactes en base 10 seulement si tu autorises un nombre de chiffres après la virgule illimité, or en pratique il est borné... 3,5% lui-même est peut-être exact, mais quand tu le multiplies par une valeur tu fais un arrondi, donc on s'en fout)

Personne n'a besoin de faire des calculs exacts en finance, on veut juste que l'erreur soit raisonnable (par exemple que ce soit "exact" au centime près, mais après sur des très grosses sommes tu n'es même pas à 10 euros près... en fait en-dessous de mettons 1 pour mille d'erreur presque tout le monde s'en fout (il y a peut-être quelques tarés pour qui ça pose problème) et en-dessous de 0,01 pour mille strictement personne n'en a rien à péter ^^

ok demain j'invente une calculatrice qui sur les grosses sommes tranféré, me mets 10€ sur un compte et j'attends (et devient riche bien sur!)