C'est simple et utile pour les gros débutants. Remplace juste "suppimer" par "supprimer" et ce sera impeccable.

Ce serait bien que tu postes un lien vers la source de Julien39 pour que les gens sachent de quoi nous parlons.

Tu ne devrais pas utiliser une liste pour faire ça comme tu es sensé connaître la taille de la matrice dès le début et que le temps d'accès à une liste est plus long que le temps d'accès à un tableau.

J'ai parlé des matrices creuses mais ton implémentation ne dispose pas d'optimisation pour stocker ce genre de matrice donc je ne vois pas pour le moment ce que ton implémentation apporte de plus aux APIs existantes.

Les nombres complexes peuvent être stockées sous forme de nombres réels si tu les exprimes dans leur forme vectorielle, de même pour les nombres hypercomplexes donc je maintiens que je ne vois absolument pas l'intérêt de l'utilisation de la généricité dans ce cas précis.

Elle va être super la communication avec le monde extérieur surtout dans le cas des NIO buffers s'il faut répercuter les modifications de la matrice dans une autre structure de données et allouer de la mémoire pour une structure séparée. Si tu avais utilisé un tableau, une API utilisant des NIO buffers aurait simplement eu à envelopper le tableau dans un NIO buffer (avec la méthode wrap) et les modifications dans le tableau auraient été automatiquement répercutées dans le NIO buffer. En gros, ta solution n'est pas adaptée à des solutions de calcul ayant besoin de communiquer avec OpenCL (JOCL), OpenGL (JOGL) et d'autres API écrites dans d'autres langages (en Fortran par exemple, cas courant en physique) qui peuvent avoir besoin de passer par les NIO buffers pour éviter la duplication mémoire dans la communication entre le code Java et le code natif.

Dans les API Java standards, les indices sont stockés sur des entiers signés 32 bits (int) et non sur des shorts. Pourquoi garder des shorts alors que les autres API utilisent des ints? Cela ajoute de la confusion et est sans intérêt.

Bonjour

Je n'aime pas trop la classe ArrayMatrix. Déjà, on peut stocker très peu de types d'objets différents dans une matrice, une simple classe reprenant les opérations de base sur les matrices et manipulant des instances de la classe abstraite Number aurait été un peu plus utile.

D'autre part, en informatique, on a souvent besoin de manipuler des matrices creuses, elles sont plutôt implémentées à l'aide de graphes pour occuper moins de mémoire, cela ne veut pas dire que les classes en question ont un mauvais design.

Pourquoi utiliser des shorts pour les coordonnées??

Je crois qu'on peut faire "pêter" ta classe en passant des valeurs négatives...

As-tu regardé ce qui se fait dans des APIs couramment utilisées? On n'essaie pas d'avoir une classe générique pour gérer les matrices, on fait au plus 2 classes (une pour les floats, une pour les doubles) voire 2 classes par dimension et ça s'arrête là.

Pour qu'une classe générique de matrice puisse communiquer avec des APIs basées sur des NIO buffers, il faudrait au moins que tu stockes tes valeurs dans un seul tableau à une dimension (tu peux simuler un tableau multi-dimensionnel avec un tableau à une seule dimension bien évidemment).

Tu ajoutes des valeurs nulles au lieu de simplement utiliser le constructeur qui permet de fixer la capacité d'une liste.

Pour résumer, si une classe Matrix n'existe pas dans l'API standard Java, c'est surtout parce que l'implémentation diffère beaucoup entre les matrices creuses et les autres. Tu crées des tonnes d'objets alors que dans de vrais calculs, on essaie d'utiliser à fond des types primitifs (sauf pour les très grandes valeurs, cf. les classes BigInteger et BigDecimal). Je ne vois pas la valeur ajoutée qu'apporte ta classe. Je te conseille de jeter un coup d'oeil aux codes sources d'OpenMaLi, de javax.vecmath, de C.E.R.N Colt et d'Ardor3D-core math sachant que ces bibliothèques n'ont pas d'implémentations optimisées des matrices creuses (sauf peut-être celle du C.E.R.N).

A un endroit, tu as dû utiliser des radians à la place des degrés ou l'inverse d'où le ralentissement.

Il est difficile de proposer des conseils sur la manière de traiter les exceptions sans rentrer dans les particularités et ton tutoriel aura besoin d'une mise à jour à la sortie de Java 1.7 à cause de la nouvelle clause "try with resource". Je vois mal comment on peut traiter cela tout en restant assez général. Beaucoup de débutants posent des questions très bêtes sur les exceptions ici souvent soit parce qu'ils n'ont même pas regardé la documentation de la classe de l'exception soit parce qu'ils ne comprennent pas l'anglais. Fournir des tutoriels en français est une bonne chose mais il ne faut pas laisser entendre qu'on peut s'en sortir sans une maîtrise minimale de l'anglais technique ni farfouiller dans l'excellente documentation en ligne. Bon courage.

C'est un peu bizarre de présenter les choses ainsi mais ça tient la route. Par contre, je ne suis pas d'accord avec ça :
"Cependant, il est possible que cette idée soit justifiée et donc, on
sera obligé d'utiliser les casts."

Mieux vaut stocker les objets dans 2 listes différentes ou bien créer une structure qui contient un couple typé d'objets et placer ces couples dans la liste (c'est ce que je fais avec Map.Entry quand je suis à la bourre ou avec une classe bien à part de préférence).

Bonjour

Il y a des fautes d'orthographe dès le premier paragraphe :
"l'interpreteur prends".

Le Python peut être interprété ou compilé au choix alors que ce tutoriel laisse entendre le contraire.

"Le script est entièrement traduit en langage machine dans un fichier
exécutable.". Eh non, c'est du bytecode, pas du script.

"plus rapide
(mais pas autant qu'un langage compilé)". C'est faux bien que cela fasse encore débat en 2011. Les chercheurs en calcul haute performance d'IBM le disent depuis des années, l'utilisation d'une machine virtuelle permet des optimisations dynamiques inconcevables dans un langage purement compilé. Brian Goetz, auteur de plusieurs ouvrages reconnus sur Java, rappelle que les appels à méthodes et les allocations mémoire sont 2 à 4 fois plus rapides en Java qu'en C++. Pour ne pas alimenter de vieux mythes sans mettre les pieds dans le plat, il serait préférable de retirer cette phrase.

La fin du paragraphe 1.2 devrait parler du JIT au lieu de rester vague voire à côté de la plaque.

Le JRE contient aussi Java Web Start qui est très utilisé.

Le JDK contient aussi un profileur appelé JVisualVM, il est bien utile quand on n'a ni l'envie ni les moyens de mettre la main à la poche pour s'offrir une licence JProfiler ou YourKit et quand on n'est pas sous Netbeans. Cordialement.

Bonjour

En fait, même pour les exceptions de type NullPointerException, je ne suis pas d'accord, tester si c'est null ne suffit pas, il faut au moins mettre un message dans les logs si une méthode ne devrait pas être appelée avec un paramètre à null voire lancer une exception plus explicite encapsulant l'exception en question du genre throw new IllegalStateException("le prénom ne devrait jamais être à null",npe). C'est vrai pour les exceptions en général. Il faut choisir dans quelle couche on l'attrape et dans quelle couche on offre un traitement adapté.

Le tutoriel ne parle pas du tout du "finally".

Je pense que les débutants devraient surtout avoir le réflexe de lire la documentation Java.

Le dernier paragraphe sur OutOfMemoryError traite de la mémoire de manière très très superficielle, le conseil donné ne résoudra pas le problème si une augmentation de la mémoire non paginée aurait été plus adéquate et s'il n'est pas possible d'augmenter la taille passée à -Xmx de telle sorte que cette mémoire en accès direct soit suffisante.

Cela ne permet pas de se débarrasser du verrou de Cardan comme tu n'utilises pas les 2 seules méthodes connues à cet effet (les singularités et les transformations non eulériennes).

Merci, c'est mieux ainsi.