Discussion :

[®om]

Je n'ai jamais vu ceci (je viens de voir ça dans la classe java.lang.Double) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public static final double MIN_VALUE = 0x0.0000000000001P-1022; // 4.9e-324

Apparemment, le P déclare l'exposant - naturel, pas biaisé - (sur 11 bits) du double.
En plus la partie avant le P doit être en hexa, sinon ça compile pas (0x)... (par exemple, 1p2 ça ne marche pas, mais 0x1p2 ça marche)

Existe-t-il la même chose pour les float?

Vous connaissiez cette fonction?

[gronono]

Voici un extrait de la classe java.lang.Float :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
public static final float MAX_VALUE = 0x1.fffffeP+127f; // 3.4028235e+38f
public static final float MIN_VALUE = 0x0.000002P-126f; // 1.4e-45f

Donc oui, ca existe avec les float.
Et non je connaissais pas cette fonctionnalité. Mais j'en ai jamais eu besoin.

D'ailleurs, il y a d'autres faits étranges dans la classe Float par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 public static final float NEGATIVE_INFINITY = -1.0f / 0.0f;

[®om]

D'ailleurs, il y a d'autres faits étranges dans la classe Float

Moi j'aime bien la méthode isNan(...) (pour double et float):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
static public boolean isNaN(double v) {
    return (v != v);
}

Autre petit détail que je n'explique pas, on peut avoir un infini pour double et float, mais pas pour int et long...
Donc:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

double d = 1./0;

ça ne lève pas d'exception...
mais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int i = 1/0;
//ou encore
double d = 1/0;

ça lève une ArithmeticException...

[gronono]

C'est vrai que c'est bizarre.

Les divisions par zéro peuvent surement s'expliquer par la représentation des nombres en mémoire. Un réel n'a pas forcemenent de représentation en mémoire.
Par contre un entier est toujours "exacte". Chaque entier peut s'écrire de manière exacte en base 2.
Donc pour les divisions c'est normal.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

static public boolean isNaN(double v) {  return (v != v); }

Cette méthode doit toujours retourné false non ?

[adiGuba]

Salut,

Les réels possèdent des notions d'infini, et comme en Math 1.0/0.0 == +infini et -1.0/0.0 == -infini.
Ce doit être la même chose pour NaN qui représente une valeur incorrecte...

Ces valeurs n'existe pas pour ce qui concerne les nombres entiers... d'où la différence de comportement...

Pour le P c'est l'exposant binaire ! Tout est là : http://java.sun.com/docs/books/jls/t...al.html#3.10.2

a++

[lando]

Exactement :

Descriptif rapide de NaN

J'ai testé quelques cas, mais j'ai pas réussi à bloquer avec une division par zero mais racine carré de -1 ca marche bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
double sqrt = Math.sqrt(-1.);
System.out.println("sqrt : "+ Double.isNaN(sqrt));

sqrt : true

[®om]

J'ai du mal à comprendre leur choix concernant le 'p'.

Pourquoi la partie à gauche du p doit forcément être exprimée en hexa (avec le 0x forcé, même pour écrire un nombre plus petit ou égal à 9), alors que la partie droite du p doit forcément être exprimée en décimal...?