Version imprimable
Si dans ce cas on a un programme dans lequel l'infini à un sens, on ne devrait donc pas être surpris que tel ou tel opération retourne l'infini plutot que de lever une exception ... ce qui me pousse à dire que normallement un programme n'est pas cencé contenir un nombre infini ou un nombre n'en étant pas un ( ... NaN ) d'où le besoin de vérifier. Sinon, on peut très bien se passer de se genre de vérifications.Citation:
Envoyé par Uther
Dans IR (l'ensemble des réels), en effet. Mais dans "IR barre" (l'ensemble des réels avec les deux infinis), si.Citation:
Envoyé par Uther
smyley> Je crois que tu m'as mal compris. Je suis entièrement d'accord. On vérifie juste si on estime qu'on en à besoin.
Je comprend juste que ca puisse choquer quelqu'un habitué à travailler avec les entiers.
Guulh> Heureux de l'apprendre, j'ai du arreter les math trop tôt ou alors je n'ai pas du être assez attentif.:roll:
ça s'appelle "l'adhérence de R" :aie:Citation:
Envoyé par Guulh
infini ou NaN comme valeur de double c'est bien plus pratique que tester un exception.Citation:
Si dans ce cas on a un programme dans lequel l'infini à un sens, on ne devrait donc pas être surpris que tel ou tel opération retourne l'infini plutot que de lever une exception ... ce qui me pousse à dire que normallement un programme n'est pas cencé contenir un nombre infini ou un nombre n'en étant pas un ( ... NaN ) d'où le besoin de vérifier. Sinon, on peut très bien se passer de se genre de vérifications.
Ainsi tu peux séparer plus facilement une méthode faisant du calcul, et une de l'affichage.
Par exemple gestion de l'affichage d'une courbe lorsque les valeur devienne infini. Pour une application qui affiche des courbes géométrique.
Dans la partie affichage tu testes inifni.
Si tu devais gérer cela par les exceptions tu serais embétés. Quelle valeur mettre dans ta variable pour qu'ensuite dans la méthode affichage on comprenne que c'est infini ?
Gérer cela par un tableau à deux dimension pour tes valeurs ? Une dimensions la valeur, et une autre un booleen pour dire si c'est infini ou pas.
Et puis en même temps lorsque tu fait une division par 9^-34. Tu as peut être envie d'arrondir à zéro car pour la reste du prog tu ne peux avoir une précision que de 10 chiffre après la virgule.
Avec les double et infini c'est plus pratique du coup !!!!
Ok, pas grand monde qui à répondu à ma question de départ, le sujet à un peu dérivé...
Perso, je trouve pas terrible le retour de + ou - l'Infinie. Pourquoi limité le type int (sans ajouter les bornes + et - l'infini), et pourquoi on ajoute à l'ensemble R des réels les bornes + et - l'infini ? Pourquoi ne pas avoir la même chose dans les deux cas ?
Il me semble qu'il y a un truc que pas logique, ou alors un truc que j'ai pas saisi...
Pour moi c'est normal aussi avec des doubles, en effet depuis le début de l'informatique le calcul sur flottant ça n'a jamais été ça.
Rien qu'à voir le fait qu'on ne puisse pas correctement comparer 2 flottants entre eux.
Le bon sens voudrait un 0 tout simplement. Ben non.Code:Console.WriteLine(0.1 * 0.1 - 0.01);
Pour la division le framework doit comparer le diviseur à 0 (selon Epsilon) et si il est +/- égal à 0 il retourne Infinity.
Ceci n'est qu'une supposition bien entendu.
Si quasiment tous les langages fonctionnent comme cela c'est tout simplement que quasiment tous les processeurs courrants fonctionnent comme cela. Il serait bête de ne pas respecter les systèmes de fonctionnement reconnus par tous.Citation:
Envoyé par oyigit
Cela pourrait également avoir un prix en terme de performances vu qu'il faudrait systématiquement adapter le comportement du compilateur au processeur.
Si les processeurs ont un comportement assez différents pour les entiers et les flottants c'est pour de des raison historiques, techniques et d'usage:
- Le codage des entiers est un codage qui date de la préhistoire de l'informatique. Il est très simple et intuitif : il s'agit juste d'écrire le nombre sous forme binaire.
La seule petite subtilité est le complément à deux(les négatifs codé en sens inverse des positifs) pour les nombres signés, qui permet de simplifer les opérations d'addition et de soustraction.
Les opérations de dépassement de capacité ou de division par 0, retournent un résultat mais levent un flag dans un registre du processeur que C# pourra utiliser pour lever une exception.- Le codage standard des vigules flottante est plus récent. Il est davatage orienté vers les mathématiques et il est bien plus complexe car il peut se poser de nombreux problèmes (taille mantise/exposant, gestion des cas indéterminés, dépassement de capacité,...) avec encore plus de façons différentes de les résoudre. Il à donc été créé plusieur normes différentes qui définissent le codage et le comportement des opération sur ces nombres.
La norme qui c'est imposé sur la majorité des compilateurs et processeurs standards modernes est la norme IEEE 754.
Cette norme defini des valeur qui représenten des non nombres: +/-oo et Nan et impose aux opérations de division par 0 ou de dépassement de retourner ces valeurs.
Parce qu'on étudie le résultat de x/0 et non pas les limites en 0.Citation:
Envoyé par smyley
Les limites ont été créées (je crois) pour connaître le comportement de certaines fonctions lors de cas indéterminés mathématiquement (la division par zéro n'étant pas "définie", les matheux ont décidé de dire quel est le comportement de cette fonction 1/x si on se rapproche le plus possible de 0, sans pour autant l'atteindre).
En Mathématiques, on m'a toujours appris que diviser un nombre par zéro était impossible, mais on m'a appris que plus le chiffre se rapprochait de zéro, plus le résultat était grand (positif ou négatif, selon 0- ou 0+ blabla). Tu vois la différence ?
ps : Elle sert à quoi l'exception DivideByZero si elle n'est jamais récupérée ? à faire joli ? oO (je suis tombé sur le même problème, l'exception n'est jamais "lancée")
C'est marqué au dessus, faut lire (:roll:) : cette exception est balancée lors de la division par un ENTIER, parce qu'il n'existe pas de représentation dans le type "int" de l'infini. Le type "double" ayant des valeurs +Infinity et -Infinity, autant s'en servir.Citation:
Envoyé par casiii
Mince je voulais écrire la même chose mais au moment de faire post reply, la fenêtre à planter, et lorsque je suis revenue tu m'as grillé. :DCitation:
Envoyé par Guulh
Bon pour vous mettre tous d'accord sur division par zéro interdit ou non :
De façon générale aller voir cette page :Citation:
Division by zero
Division by zero is an operation for which you cannot find an answer, so it is disallowed. You can understand why if you think about how division and multiplication are related.
12 divided by 6 is 2 because
6 times 2 is 12
12 divided by 0 is x would mean that
0 times x = 12
But no value would work for x because 0 times any number is 0. So division by zero doesn't work.
http://mathforum.org/dr.math/faq/faq.divideby0.html
Et puis si vous voulez blamer quelqu'un à cause des divisions par zéro :
Blamer les moines qui ont introduits au moyen age le chiffre 0 pour faciliter leurs opérations de comptabilité.
(voilà j'ai réussi à le placer :mrgreen: )
Enfin que la division par 0 soit mathématiquement acceptable ou pas, 1/0=+oo pour un float ou un double ne me gène pas vu que les float et double sont des valeurs approximées et absolument pas formelles.
Au fait je me disais en koi on n'a pas répondu à ta question.Citation:
Envoyé par oyigit
Tu voulais savoir si la valeur infinity retourné c'est normal -> Oui et dit plus haut.
Tu voulait connaître sont utilités. Je crois que l'on a apporté aussi une réponse à cela avec beaucoup d'avis.
S'en servir pour dire que 1.0/0.0 => +Infinity ? Si 1/0 et 1.0/0.0 ne donnent pas le même résultat, cela peut vouloir dire que 0 != 0.0Citation:
Envoyé par Guulh
(un entier est un réel spécial, c'est de l'héritage :mouarf: )
Je suis désolé de te contedire deux fois d'affilée, mais au sens C#, un int n'est pas un double. Il existe une conversion implicite, mais la relation d'héritage (plus précisément d'inclusion) mathématique n'est pas vraie en POO :)Citation:
Envoyé par casiii
Code:
2
Oui tout comme 2 + 2 peuvent donner 5.. C'est ça l'informatique!Citation:
Envoyé par casiii
Bon... Il faut surtout voir les choses autrement...
short/int c'est pour "compter"
float/double c'est pour "calculer"
pour moi ca résume tout.
En fait je vois pas pourquoi certains se prennent la tête... On a une valeur de retour, qui mathématiquement à un sens, je vois pas d'où vous vous plaignez...
Et puis s'attendre à recevoir "logiquement" une Exception, c'est la preuve d'une erreur dans la conception... Comme dis plus haut, autant tester soi même la valeur à 0, c'est plus propre...
C'est comme si je mettais des catch NullReferenceException partout car je sais que quelque chose va etre "null"...
Gnnnn ????Citation:
Envoyé par ced600
Brahmagupta au Ve siécle. Ok, c'est limite du (très) haut MA/antiquité, mais aucun moine n'a à voir la dedans.
Ok, c'est la wiki mais bon..
http://fr.wikipedia.org/wiki/Zéro
Je prend les devants pour tuer dans l'oeuf un nouveau débat (match) entre Bluedeep et Ced :mrgreen:
Justement mais même si on a pas le droit de dire ça en math, c'est cohérent : plus on divise par quelque chose de petit, plus le resultat est grand donc quand on arrive à 0 on trouve l'infini :aie:Citation:
Envoyé par casiii