fredericmazue wrote:Ca parait quand même incroyable que tu n'ais pas Infinity.
Je parlais de mes essais à moi (avec le Math.random). Avec ton code, j'ai bien "infinity", peut importe la JVM (1.4 et 1.5 avec des brouettes derrière).
C'est pour celà que j'ai réécrit le code en gardant le Math.random. J'ai ajouté un contrôle sur l'affectation d'une valeur à 0 par le Math.random et un test s'il y a une division par 0. Or mon joli message pleins de "****" ne s'affiche pas et pourtant j'ai des NaN en sortie.
Donc, la division par 0 n'est pas la seule explication.
Le phénomène du NaN ne semble pas apparaître si on multiplie par 10 le Math.random, ce qui faisait soupçonner l'imprésion de calcul. Mais lors que l'on fait affiché la différence entre "norme" et "sumSQR", il y a plus de 1 et nom pas un chiffre type -0,0000000001 par exemple. Il y a donc un réel écart entre les 2 nombres.
On peut me répondre par " c'est normal, celà correspond à la somme des incertitudes cumulées dans sumSQR". C'est effectivement une possibilité, mais la variable norme suit le même principe. Et pourquoi, lorsque que l'on affecte la matrice par des valeurs croissantes, nous n'avons plus le même problème avec par exemple (Math.sqrt(i*j+1))/100.
Et il y a le phénomène de lecture de la partie supérieure de la matrice, remplit de 0. Dans le cas d'un très petit nombre, le fait de manquer d'une valeur peut entraîner suffisament d'écart pour que sumSQR soit supérieur à norme.
Je pense que je vais arrêter là, car nous n'avons plus vu notre ami à la matrice :cry: donc, je ne sais pas si les recherches servent à quelques choses, ou nous sommes en train de nous livrer une bataille d'algorithme juste pour le plaisir, et je ne voudrais pas lancer de Troll sur la qualité des langages et encore moins Java, car je suis payé suffisament cher pour défendre ce langage auprès de mes clients par ma société (Ah! le vil prestataire que voilà) 8) .
Si j'ai encore le courrage, je tenterais bien une double exécution du programme avec les mêmes valeurs, la première fois affectée directement, la seconde fois trié par ordre croissant et voir éventuellement avec un ordre décroissant, juste pour voir si la croissance des coordonnées a une influence sur le problème de calcul. Il est aussi possible de remplir la matrice avec la plus petite valeur double possible afin de voir comment le phénomène se produit. Bref un peu d'expérimentation. Mais comme notre ami ne semble plus s'intéresser au problème, je vais retourner à mon laborieu travail ..... en Java
Je parlais de mes essais à moi (avec le Math.random). Avec ton code, j'ai bien "infinity", peut importe la JVM (1.4 et 1.5 avec des brouettes derrière).
C'est pour celà que j'ai réécrit le code en gardant le Math.random. J'ai ajouté un contrôle sur l'affectation d'une valeur à 0 par le Math.random et un test s'il y a une division par 0. Or mon joli message pleins de "****" ne s'affiche pas et pourtant j'ai des NaN en sortie.
Donc, la division par 0 n'est pas la seule explication.
Le phénomène du NaN ne semble pas apparaître si on multiplie par 10 le Math.random, ce qui faisait soupçonner l'imprésion de calcul. Mais lors que l'on fait affiché la différence entre "norme" et "sumSQR", il y a plus de 1 et nom pas un chiffre type -0,0000000001 par exemple. Il y a donc un réel écart entre les 2 nombres.
On peut me répondre par " c'est normal, celà correspond à la somme des incertitudes cumulées dans sumSQR". C'est effectivement une possibilité, mais la variable norme suit le même principe. Et pourquoi, lorsque que l'on affecte la matrice par des valeurs croissantes, nous n'avons plus le même problème avec par exemple (Math.sqrt(i*j+1))/100.
Et il y a le phénomène de lecture de la partie supérieure de la matrice, remplit de 0. Dans le cas d'un très petit nombre, le fait de manquer d'une valeur peut entraîner suffisament d'écart pour que sumSQR soit supérieur à norme.
Je pense que je vais arrêter là, car nous n'avons plus vu notre ami à la matrice :cry: donc, je ne sais pas si les recherches servent à quelques choses, ou nous sommes en train de nous livrer une bataille d'algorithme juste pour le plaisir, et je ne voudrais pas lancer de Troll sur la qualité des langages et encore moins Java, car je suis payé suffisament cher pour défendre ce langage auprès de mes clients par ma société (Ah! le vil prestataire que voilà) 8) .
Si j'ai encore le courrage, je tenterais bien une double exécution du programme avec les mêmes valeurs, la première fois affectée directement, la seconde fois trié par ordre croissant et voir éventuellement avec un ordre décroissant, juste pour voir si la croissance des coordonnées a une influence sur le problème de calcul. Il est aussi possible de remplir la matrice avec la plus petite valeur double possible afin de voir comment le phénomène se produit. Bref un peu d'expérimentation. Mais comme notre ami ne semble plus s'intéresser au problème, je vais retourner à mon laborieu travail ..... en Java