Overflows numériques, pourquoi Java ne les gère pas ?

[natha]

On peut discuter des calculs avec virgules alors aussi...
0.1 + 0.2 par exemple qui a une chance sur 3 de te donner autre chose que 0.3 ! Et je trouve super-pénible de devoir passer par des BigDecimal initialisés avec des objets de type String pour avoir un calcul correct.

[OButterlin]

C'est clair que sur les calculs en float, y a de quoi dire...
Dans tous les cas, personnellement, je trouve dommage que l'overflow ne provoque pas d'erreur. Comme dit dans l'un des post, pour retrouver l'erreur, bonjour le travail !
Et je ne pense pas qu'on puisse prévoir à l'avance tout ce qu'un utilisateur pourra saisir... Pire, il se trompe, mais ça passe quand même (en faussant les données au passage)

A+

[openWorld]

Tu prends déja le nombre de pixels d'un écran en 2560*1600 et tu arrives à plus de deux fois ce résultat.

ET LES MATHS là, 2560*1600 = environ 4 millions.
Un int peut contenir 2 puissance 32 soit environ 4300 millions.
Un long peut contenir 2 puissance 64 soit environ 18 millions de millions de millions.
Desoler mais ce n'est pas un ecran qui fera sortir des limites, à moins que celui ci ne recouvre Saturne, et encore.
Bien sur il ne faut pas prendre un byte ou un short pour faire les calculs
Et toc

[Baptiste Wicht]

Envoyé par openWorld

ET LES MATHS là, 2560*1600 = environ 4 millions.
Un int peut contenir 2 puissance 32 soit environ 4300 millions.
Un long peut contenir 2 puissance 64 soit environ 18 millions de millions de millions.
Desoler mais ce n'est pas un ecran qui fera sortir des limites, à moins que celui ci ne recouvre Saturne, et encore.
Bien sur il ne faut pas prendre un byte ou un short pour faire les calculs
Et toc

Faux.

La valeur max de int, c'est 2 puissance 31 moins 1, soit 2'147'483'647.

La preuve avec la javadoc :

MAX_VALUE
A constant holding the maximum value an int can have, 2pow31-1

[mavina]

Envoyé par Baptiste Wicht

Faux.

La valeur max de int, c'est 2 puissance 31 moins 1, soit 2'147'483'647.

La preuve avec la javadoc :

On est quand meme loin d'arriver à un overflow avec ton exemple

[OButterlin]

Envoyé par Baptiste Wicht

Faux.

La valeur max de int, c'est 2 puissance 31 moins 1, soit 2'147'483'647.

La preuve avec la javadoc :

Et oui, il faudrait avoir un unsigned int pour arriver aux 4 millions et plus...

[millie]

Pour les histoires de performances, ce serait au moins sympathiques qu'il existe une option de la JVM pour lancer des exceptions d'overflow en cas d'overflow...

Si le bug est reproductible, il serait alors possible d'activer cette option pour repérer plus rapidement l'erreur (quitte à avoir une application 10 fois plus lente en environnement de test pour débugger ce type de problème).

[OButterlin]

Envoyé par millie

Pour les histoires de performances, ce serait au moins sympathiques qu'il existe une option de la JVM pour lancer des exceptions d'overflow en cas d'overflow...

Je trouve qu'il serait plus intéressant qu'un overflow soit systématiquement une erreur, le cas inverse me semble plus anecdotique...
Dans tous les cas, l'option de la jvm ne me semble pas bonne, il faudrait déjà savoir qu'on est en présence d'un problème lié à l'overflow pour le corriger.

Quel sont les cas où l'overflow serait utilile ? Moi, j'en vois pas

[millie]

Envoyé par OButterlin

Dans tous les cas, l'option de la jvm ne me semble pas bonne, il faudrait déjà savoir qu'on est en présence d'un problème lié à l'overflow pour le corriger.

Il suffirait en cas de problème non habituel de lancer la JVM en mode test qui regrouperait un ensemble d'option du type "tester les overflow".

Evidemment, il est plus intéressant qu'un overflow soit tout le temps détecté, mais as tu une idée de la dégradation des performances que cela engendre ? (moi non, mais si tu me dis que ça change rien alors c'est sûr que c'est mieux que ce soit tout le temps présent )

[OButterlin]

Envoyé par millie

Evidemment, il est plus intéressant qu'un overflow soit tout le temps détecté, mais as tu une idée de la dégradation des performances que cela engendre ? (moi non, mais si tu me dis que ça change rien alors c'est sûr que c'est mieux que ce soit tout le temps présent )

ben pour être franc, j'en sais rien du tout... j'imagine que ça ne devrait pas être la lune, mais d'un autre côté, s'ils ne l'ont pas fait, il est possible que si

[openWorld]

Baptiste Wicht oui je parlais en unsigned. Tu m'en voudras pas si ya une d'un coefficent 2. T'a fait une erreur d'un coefficient 8000 : hihihi
Menfin aucune importance

[Deadpool]

Et si on allait voir ce que font les concurrents?

En C# en l'occurrence, les overflows sont très bien gérés. Une exception est lancée en cas de dépassement de capacité lors d'une opération arithmétique ou d'un cast.

Il est ainsi possible d'activer ou de désactiver la vérification du dépassement de capacité d'une opération arithmétique particulière ou d'un cast via les 2 mot clés spécifiques checked et unchecked.

Petit exemple d'utilisation (tiré de la msdn):

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
//code c#
        short x = 32767;   // Max short value
        short y = 32767;
        int z = 0;
        try
        {
            z = checked((short)(x + y));
            Console.WriteLine(z);
        }
        catch (System.OverflowException e)
        {
            Console.WriteLine(e.ToString()); //dépassement de capacité, on entre dans le catch, z ne sera jamais affiché
        }

Enfin, il existe une option particulière du compilateur c# (csc de son petit nom) qui permet également d'activer ou non la vérification du dépassement de capacité pour toutes les opération arithmétique pour lequelle il n'a pas été spécifié de mot clé checked ou unchecked, c'est l'option /checked.

Ca doit bien être faisable en Java, non?


Edit : j'ai oublié de préciser, par défaut (pas de mot clé checked ou unchecked mis devant une opération, option checked du compilo non utilisée), C# ne contrôle pas les dépassement de capacité (mode unchecked donc).

[LGnord]

Je ne connais pas la norme IEEE 754. Je vais quand même essayer de faire avancer le débat.

Within an FP-strict expression, all intermediate values must be elements of the float value set or the double value set, implying that the results of all FP-strict expressions must be those predicted by IEEE 754 arithmetic on operands represented using single and double formats. Within an expression that is not FP-strict, some leeway is granted for an implementation to use an extended exponent range to represent intermediate results; the net effect, roughly speaking, is that a calculation might produce “the correct answer” in situations where exclusive use of the float value set or double value set might result in overflow or underflow.

JLS3 §15.4

[Uther]

Quel sont les cas où l'overflow serait utilile ? Moi, j'en vois pas

Ca m'a déjà été utile quelques fois, même si c'est vrai que ça ne sert pas tous les jours et à tout le monde. On peut l'utiliser par exemple faire un checksum basique:

Code :

1
2
int checksum=0;
for(int i=0; i<byteArrayToCheck.length; i++) checksum += byteArrayToCheck[i];

Ceci dit, un comportement comme celui du C# serait préférable:
- Une option à la ligne de commande pour activer/désactiver la vérification(désactivé par défaut pour la compatibilité, même si je trouverai plus sur que ce soit activé par défaut),
- Tout en conservant la possibilité de spécifier individuellement le comportement des variables dont on attend un comportement particulier, comme la variable checksum de mon exemple.