Le B ça suxx - Page 5

Pollux (./118) :
Je vois très bien ce que tu as écrit, et je crois que ton problème vient de ce que tu considères chaque fonction comme une machine avec un comportement bien déterminé. C'est une vision erronée : peut-être que ça peut être implémenté comme ça, mais la spécification autorise bcp plus de comportements que ça (y compris des comportements non-déterministes).

naplu de genou.

"l'expression float_of_int(N+N-N) n'est pas toujours équivalente à float_of_int(N)+float_of_int(N)-float_of_int(N)" ?

Bha voui.
Oh la la il faut tout te mâcher !

D'ailleurs je ne vois pas pkoi tu me parles de la base 2, les entiers signés de C pourraient tout aussi bien être représentés en base 3 ou 5 sans aucun impact sur la performance Donc dire qu'ils représentent des entiers 2-adiques et pas 3-adiques ou 5-adiques, c'est complètement preposterous

Mais non mon bon Pollux, la base 2 est importante.
Tu devrais lire monsieur Zlu plus souvent. Il faut que tu sois en communion avec l'ordinateur.

(bon par contre ok si tu parles des entiers non-signés, mais on ne parle que des entiers signés depuis le début )

Bon c'est vrai que les entiers signés ça a l'air d'avoir été inventé pour permettre aux Pollux de se faire des noeuds dans la tête.

Sally (./119) :
./117 > tu n'aurais pas oublié quel jour on est ? bon courage mais...

Saperlipopette ! Cornegidouille ! Jarnicoton !C'est parti pour un week end aux pâtes et au riz.

dualmoo (./120) :

LLB (./90) :
Mais je te mets au défi de convaincre une entreprise d'utiliser Caml.

http://janestcapital.com/

Je sais très bien qu'il y en a. Il y a d'ailleurs une liste plus complète ici : http://wiki.cocan.org/companies

Je voulais juste dire que migrer vers Caml n'est vraiment pas aisé et c'est risqué. Pour un logiciel indépendant, ça peut être envisagé dans certains cas, mais je ne le conseillerais pas à une entreprise. Rien que l'interopérabilité avec les bibliothèques existantes peut être compliquée.

Et tu crois sincèrement qu'avec un projet de recherche comme F# c'est plus facile ? Combien d'entreprises utilisent F# ?

Hippopotame (./121) :

Pollux (./118) :
Je vois très bien ce que tu as écrit, et je crois que ton problème vient de ce que tu considères chaque fonction comme une machine avec un comportement bien déterminé. C'est une vision erronée : peut-être que ça peut être implémenté comme ça, mais la spécification autorise bcp plus de comportements que ça (y compris des comportements non-déterministes).

naplu de genou.

"l'expression float_of_int(N+N-N) n'est pas toujours équivalente à float_of_int(N)+float_of_int(N)-float_of_int(N)" ?

Bha voui.Oh la la il faut tout te mâcher !

Ben alors c'est exaactement ce que je dis dans le paragraphe qui t'a fait perdre les genoux : un bout de programme n'est pas une boîte noire, et on peut dire "l'expression N+N-N n'est pas toujours équivalente à l'expression N+N-N" (un même compilo peut décider une fois sur deux de faire un programme qui renvoie N ou de faire un programme qui formatte le disque dur, ce qui n'est pas complètement équivalent ).

Donc cette notion d'équivalence ne sert vraiment à rien dans un langage qui permet des undefined behaviour ; ce qu'on utilise en C c'est plutôt "ces deux programmes font exactement la même chose lorsque le premier ne déclenche pas d'undefined behaviour" (oui, c'est pas une relation d'équivalence c'est plutôt la relation "peut être remplacé par"). Dans ce sens-là "N+N-N" est "N+N-N" deviennent effectivement équivalents, puisque le premier fait toujours une undefined behaviour. Et alors "float_of_int(N+N-N)" peut bien être remplacé par "float_of_int(N)+float_of_int(N)-float_of_int(N)"

D'ailleurs je ne vois pas pkoi tu me parles de la base 2, les entiers signés de C pourraient tout aussi bien être représentés en base 3 ou 5 sans aucun impact sur la performance Donc dire qu'ils représentent des entiers 2-adiques et pas 3-adiques ou 5-adiques, c'est complètement preposterous

Mais non mon bon Pollux, la base 2 est importante.Tu devrais lire monsieur Zlu plus souvent. Il faut que tu sois en communion avec l'ordinateur.

La base 2 n'a aucune espèce d'importance ^^

1) Mais où veux tu en venir exactement?

2) Vas dire ça à un transistor

1) que ta notion d'équivalence est fondamentalement buggée, et qu'autant ton post pourrait être un semblant de critique contre la notion d'undefined behaviour, autant il ne dit rien sur le bien-fondé de la correspondance int-float
2) ràf des transistors, c'est très facile de faire une couche d'abstraction en base 3

dualmoo (./123) :
Et tu crois sincèrement qu'avec un projet de recherche comme F# c'est plus facile ? Combien d'entreprises utilisent F# ?

C'est encore trop récent, mais oui, je suis bien plus confiant. F# n'a pas les principaux défauts de Caml. J'ai l'impression de me répéter, mais F# s'intègre parfaitement dans .NET, il s'interface sans problème avec C#. On peut donc faire un projet en mélangeant les 2 langages, faire une bibliothèque en F# pour l'utiliser dans un autre langage .NET et inversement. On peut utiliser F# avec ASP.NET, avec Silverlight, avec XNA (et faire un jeu pour XBox), etc. Il n'y a pas plus de limitation en F# qu'en C# ou Java.

Le seul problème actuel, c'est que c'est encore trop jeune et pas assez connu. Mais clairement, il y a tout ce qu'il faut dans F#.

http://intellifactory.com

L'intégration dans .NET, elle ne sert que si on utilise les technologies M$ partout. Il y a plein de serveurs tournant sous GNU/Linux, et de plus en plus de postes de travail aussi.

Pollux (./126) :
1) que ta notion d'équivalence est fondamentalement buggée,

C'est toi qui l'a introduite !

2) ràf des transistors, c'est très facile de faire une couche d'abstraction en base 3

Tu sais bien que non.
Parce que dans ce cas, on oublie tous ces problèmes fins et on utilise des bibliothèques de calcul en précision arbitraire dans tout le programme. #maple#

F# fonctionne très bien sous Linux (Mono). J'ai testé sur un projet de taille moyenne, c'était entièrement compatible sans la moindre modification. Mais beaucoup d'entreprises limitent (malheureusement) leur développement à Windows.

Hippopotame (./129) :

Pollux (./126) :
1) que ta notion d'équivalence est fondamentalement buggée,

C'est toi qui l'a introduite !

Je parle pas de la notion que j'ai introduite (qui makes tout à fait sense), je parle de la tienne...

2) ràf des transistors, c'est très facile de faire une couche d'abstraction en base 3

Tu sais bien que non.
Parce que dans ce cas, on oublie tous ces problèmes fins et on utilise des bibliothèques de calcul en précision arbitraire dans tout le programme. #maple#

Mais non. Tu n'as pas idée de la quantité de problèmes (performance, sécurité, denial of service...) que peut poser la précision arbitraire. Alors que calculer en base 3, c'est jamais que O(1) plus coûteux, i.e. on peut construire un transistor O(1) plus gros et plus lent pour la base 3...

Pollux (./131) :
Je parle pas de la notion que j'ai introduite (qui makes tout à fait sense), je parle de la tienne...

Mais j'ai rien introduit du tout, c'est toi qui compliques comme à ton habitude !

Mais non. Tu n'as pas idée de la quantité de problèmes (performance, sécurité, denial of service...) que peut poser la précision arbitraire. Alors que calculer en base 3, c'est jamais que O(1) plus coûteux, i.e. on peut construire un transistor O(1) plus gros et plus lent pour la base 3...

Mais tu quittes complètement le monde réel !
Le coût de développement et de production d'un microprocesseur performant et au niveau, fonctionnant en base 3, dépasse largement l'achat de 2 ou 3 ordinateurs supplémentaires pour compenser la perte de performance quand on écrit un programme en maple...

Hippopotame (./132) :

Pollux (./131) :
Je parle pas de la notion que j'ai introduite (qui makes tout à fait sense), je parle de la tienne...

Mais j'ai rien introduit du tout, c'est toi qui compliques comme à ton habitude !

J'ai pas dit que tu l'avais introduite, j'ai juste dit que tu l'avais utilisée :

Hippopotame (./121) :

tu veux dire "l'expression float_of_int(N+N-N) n'est pas toujours équivalente à float_of_int(N)+float_of_int(N)-float_of_int(N)" ?

Bha voui.Oh la la il faut tout te mâcher !

Toute notion d'équivalence telle que la citation soit vraie est fondamentalement buggée, c'est tout ^^

Mais non. Tu n'as pas idée de la quantité de problèmes (performance, sécurité, denial of service...) que peut poser la précision arbitraire. Alors que calculer en base 3, c'est jamais que O(1) plus coûteux, i.e. on peut construire un transistor O(1) plus gros et plus lent pour la base 3...

Mais tu quittes complètement le monde réel !
Le coût de développement et de production d'un microprocesseur performant et au niveau, fonctionnant en base 3, dépasse largement l'achat de 2 ou 3 ordinateurs supplémentaires pour compenser la perte de performance quand on écrit un programme en maple...

Peu importe, c'est pas de ça que je parle, je dis juste que la notion de base 2 n'est pas du tout présente dans la notion d'entier signé... (pas plus que le fait de stocker les nombres par paquets de 32 bits [et pas 64 bits] soit inhérent aux nombres entiers de maple, par exemple)

>>> Toute notion d'équivalence telle que la citation soit vraie est fondamentalement buggée, c'est tout

Pas compris. Quelle citation?

>>> Peu importe, c'est pas de ça que je parle

En fait je ne sais pas de quoi tu parles.

>>> la notion de base 2 n'est pas du tout présente

Ah ben je prétends que si, malgré tout.

Pollux (./133) :

Hippopotame (./121) :

tu veux dire "l'expression float_of_int(N+N-N) n'est pas toujours équivalente à float_of_int(N) float_of_int(N)-float_of_int(N)" ?

Bha voui. Oh la la il faut tout te mâcher !

Toute notion d'équivalence telle que la citation soit vraie est fondamentalement buggée, c'est tout ^^

Ben euh, on peut dire que l'équivalence c'est l'égalité syntaxique (au sens des tokens, donc en ignorant les espaces etc.) (c'est restrictif mais bon c'est bien une relation d'équivalence et je ne vois pas en quoi c'est fondamentalement buggé), et alors la citation est vraie (il est même vrai que ça n'est jamais équivalent, mais on s'en fout)

(pourquoi sauver-vider ça vire les signes plus )

Hippopotame (./134) :
>>> Toute notion d'équivalence telle que la citation soit vraie est fondamentalement buggée, c'est tout
Pas compris. Quelle citation?

la plus imbriquée (enfin ce qu'il y a à l'intérieur des guillemets, pas toute la phrase )

>>> la notion de base 2 n'est pas du tout présente

Ah ben je prétends que si, malgré tout.

relis () la norme


Sally> qui ne dépende que du comportement du programme

Ouais.


Enfin faut développer un peu parce que là ça ne convainct pas.

Heu de quoi on parle, je suis perdu là.

On (ils) parle(nt) de la possibilité d'utiliser des nombres flottants à la place d'entiers sans altérer le résultat lorsqu'il est défini.

Le problème est : les entiers font-ils partie d'un sous-ensemble des flottants ? (Pour des valeurs maximale et minimale des entiers données)

(Si j'ai bien compris )

Je pense que le problème vient d'après (le trip de pollux), pépé était déjà là quand on a commencé cette discussion.

Sinon je crois que j'ai pigé pourquoi il y a des raisons mathématiques profondes qui font qu'un réel est plus difficile à représenter qu'un machin p-adique, et donc que les float seront toujours plus pénibles que les int.

Je crois plutôt que le trip vient d'ici :

Hippopotame (./94) :
Ben non justement puisque dans l'un des types il y a undefined behaviour, pas dans l'autre. Ya pas de morphisme !!

Quand le calcul fait avec des entiers donne un undefined behaviour, on se fout du résultat donné par la version avec des flottants, il peut être bon et ça ne change rien...

On s'en fout, on s'en fout, c'est vite dit ! Moi je ne m'en fous pas !

En tout cas ça montre que les entiers ne se plongent pas dans les floats.

Je crois que personne ne comprend vraiment de quoi ils parlent et surtout pas eux, mais bon c'est pas grave ^^

edit : Pollux > ben si je donne comme relation d'équivalence sur les expressions C : deux expressions sont équivalentes si et seulement si la norme implique qu'elles sont toujours évaluées à la même valeur (donc ça ne dépend bien que du comportement du programme), alors il existe bien un entier N tel que (float) (N+N-N) ne soit pas équivalent à (float) N + (float) N - (float) N, donc la citation est vraie et je vois mal ce que cette relation d'équivalence a de "fondamentalement buggé"...

[ancien post]Pollux > donc si je t'exprime clairement, ça donne : il n'existe pas de relation d'équivalence sur les expressions C telle que : (a) deux expressions qui selon la norme doivent toujours être évaluées à la même valeur sont équivalentes et (b) il existe un entier N tel que (float) (N+N-N) ne soit pas équivalent à (float) N + (float) N - (float) N ?
(le (a) est une tentative de traduction de "ne dépend que du comportement du programme")[/ancien post]
(multicross)

./139: Ca j'avais compris, mais j'ai l'impression qu'ils se sont égarés

./143: je partage ton opinion

Bon par contre en caml je pense qu'il est vrai que float_of_int N + float_of_int N - float_of_int N et float_of_int (N + N - N) donnent toujours le même résultat (puisqu'on a droit à l'overflow et que la mantisse doit être suffisamment grande), mais ça n'est en revanche pas le cas de float_of_int (N + N) - float_of_int N et float_of_int (N + N - N), donc ça marche pas non plus

Sally (./143) :
edit : Pollux > ben si je donne comme relation d'équivalence sur les expressions C : deux expressions sont équivalentes si et seulement si la norme implique qu'elles sont toujours évaluées à la même valeur (donc ça ne dépend bien que du comportement du programme), alors il existe bien un entier N tel que (float) (N+N-N) ne soit pas équivalent à (float) N + (float) N - (float) N, donc la citation est vraie et je vois mal ce que cette relation d'équivalence a de "fondamentalement buggé"...

[ancien post]Pollux > donc si je t'exprime clairement, ça donne : il n'existe pas de relation d'équivalence sur les expressions C telle que : (a) deux expressions qui selon la norme doivent toujours être évaluées à la même valeur sont équivalentes et (b) il existe un entier N tel que (float) (N+N-N) ne soit pas équivalent à (float) N + (float) N - (float) N ?
(le (a) est une tentative de traduction de "ne dépend que du comportement du programme")[/ancien post]
(multicross)

Ben en fait ta définition ça rentre justement dans les trucs fondamentalement buggés : à moins de pouvoir garantir qu'un programme n'a pas d'undefined behaviour, il n'est jamais équivalent à lui-même, ce qui est un peu problématique ^^ (parce que du coup (float)(N+N-N) n'est équivalent à rien du tout, même pas à lui même, donc si tu veux t'en servir pour savoir quelles expressions sont équivalentes / quelles transformations tu peux appliquer à un programme sans lui faire changer de sémantique c'est un peu raté #tricouic#)


Cela dit tu as raison sur le fond, ma remarque ne s'appliquait pas à *toutes* les relations d'équivalence : on pourrait effectivement définir une relation d'équivalence réflexive telle que (float)(N+N-N) n'est pas équivalent à (float)N+(float)N-(float)N, par exemple en s'assurant que si l'une fait une undefined behaviour alors l'autre aussi, et que sinon la valeur obtenue est la même (en fait c'est simplement la plus grande relation d'équivalence contenue dans le pré-ordre "peut être remplacé par" que j'avais défini en ./124).

Bon et du coup je comprends ce qui posait problème à hippo, c'est qu'une opération valide sur des entiers convertis en float n'est pas forcément valide sur les entiers eux-mêmes ; alors que moi je parlais de la structure "image" des ints dans les floats, i.e. où ne sont valides que les opérations dont le résultat reste dans l'image des ints dans les floats, et où là il y a bien plongement... Et puis en fait il n'y avait même pas besoin de floats pour parler de ça : il suffirait de parler de plongement des entiers d'une taille donnée dans des entiers de taille plus grande ou de taille arbitraire, sans que la discussion en soit changée ^^

Ben en fait ta définition ça rentre justement dans les trucs fondamentalement buggés

Dans ce cas tu associes à chaque expression l'ensemble des résultats *possibles* (donc tout, si c'est un behavior qui est pas trop defined), et tu dis que deux expressions sont équivalentes si ces ensembles sont égaux.

Il n'y a pas de bug fondamental à définir l'équivalence de deux expressions.

Cela dit tu as raison sur le fond, ma remarque ne s'appliquait pas à *toutes* les relations d'équivalence : on pourrait effectivement définir une relation d'équivalence réflexive telle que (float)(N+N-N) n'est pas équivalent à (float)N+(float)N-(float)N, par exemple en s'assurant que si l'une fait une undefined behaviour alors l'autre aussi, et que sinon la valeur obtenue est la même (en fait c'est simplement la plus grande relation d'équivalence contenue dans le pré-ordre "peut être remplacé par" que j'avais défini en ./124).

Bon ok.

Mais à propos d'une question vraiment anodine on atteint quand même le stade de la 2^n-capillotomie.

il y a bien plongement

Il n'y a pas plongement algébrique, les lois n'ayant pas les mêmes ensembles de définition.
Une application injective uniquement ensembliste, c'est tout miteux.

Et puis en fait il n'y avait même pas besoin de floats pour parler de ça : il suffirait de parler de plongement des entiers d'une taille donnée dans des entiers de taille plus grande ou de taille arbitraire, sans que la discussion en soit changée ^^

Ah non, si t'as bien suivi ça n'a rien à voir.

Moralement les types entiers plus ou moins grands sont tous des troncatures à un ordre plus ou moins grand des entiers 2-adiques. C'est un univers homogène, qui n'a rien à voir avec l'univers des floats.

Hippopotame (./148) :

Ben en fait ta définition ça rentre justement dans les trucs fondamentalement buggés

Dans ce cas tu associes à chaque expression l'ensemble des résultats *possibles* (donc tout, si c'est un behavior qui est pas trop defined), et tu dis que deux expressions sont équivalentes si ces ensembles sont égaux.

Oui, c'est équivalent à la définition que j'avais donnée ^^

Cela dit tu as raison sur le fond, ma remarque ne s'appliquait pas à *toutes* les relations d'équivalence : on pourrait effectivement définir une relation d'équivalence réflexive telle que (float)(N+N-N) n'est pas équivalent à (float)N+(float)N-(float)N, par exemple en s'assurant que si l'une fait une undefined behaviour alors l'autre aussi, et que sinon la valeur obtenue est la même (en fait c'est simplement la plus grande relation d'équivalence contenue dans le pré-ordre "peut être remplacé par" que j'avais défini en ./124).

Bon ok.

Mais à propos d'une question vraiment anodine on atteint quand même le stade de la 2^n-capillotomie.[/cite]
Tiens t'as remarqué ?

il y a bien plongement

Il n'y a pas plongement algébrique, les lois n'ayant pas les mêmes ensembles de définition.Une application injective uniquement ensembliste, c'est tout miteux.

Ben les lois coïncident sur leur ensemble de définition commun, c'est mieux qu'un truc purement ensembliste ^^ (cela dit les entiers signés ne forment déjà pas un monoïde, donc il faut pas s'attendre à des miracles côté structure non plus)

Et puis en fait il n'y avait même pas besoin de floats pour parler de ça : il suffirait de parler de plongement des entiers d'une taille donnée dans des entiers de taille plus grande ou de taille arbitraire, sans que la discussion en soit changée ^^

Ah non, si t'as bien suivi ça n'a rien à voir.

Moralement les types entiers plus ou moins grands sont tous des troncatures à un ordre plus ou moins grand des entiers 2-adiques. C'est un univers homogène, qui n'a rien à voir avec l'univers des floats.

Ah non, je parle des entiers signés (i.e. les entiers avec sémantique overflow = undefined behaviour), et il y a pb à plonger les int32 dans les float64 ssi il y a pb à plonger les int32 dans les int64 ^^ (autrement dit ça dépend de ta définition de "plonger")

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.