Nombre double : écriture étrange

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

Code:

---

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?

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

Code:

---

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:

---

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

---

Citation:

---

Envoyé par gronono

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:

---

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:

---

double d = 1./0;

---

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

Code:

---

1 2 3

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

---

ça lève une ArithmeticException...

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:

---

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

---

Cette méthode doit toujours retourné false non ?

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++

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:

---

1 2 3

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

---

Citation:

---

Envoyé par sysout

sqrt : true

---

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...?