Java Vektoren und Matrizen

TheLordix

Ensign Pro
Registriert
Sep. 2010
Beiträge
216
Hallo zusammen!

Um meine schon etwas eingerosteten Programmierkenntnisse aufzufrischen, habe ich begonnen ein kleines 2D Java Spiel zu Programmieren. Dabei bin ich schnell draufgekommen, dass händische Vektor- und Matrizenoperationen mühsam sind.
Momentan benutze ich folgende Klasse (zweckentfremdet) für meine Vektoren:

Point2D.Float aus dem Package java.awt.geom.Point2D

Diese Klassen sind aber eher für die Graphics2D Objekte optimiert und es fehlen elementare Vektoroperationen wie Skalarprodukt, Drehmatrizen, ect.

Deshalb meine Frage: Welche Bibliotheken oder Packages nimmt man heutzutage so in Java für Lineare Algebra? Wichtig wäre mir nichts zu exotisches und trotzdem etwas performantes und einigermaßen einfaches zu verwenden.

Danke für eure Ideen,
TheLordix
 
Danke für die Antwort.

Ich habe währenddessen selbst gesucht und diese Klasse gefunden:

org.apache.commons.math3.geometry.euclidean.twod.Vector2D

ist das ein Teil des offiziellen Java SDK und empfehlenswert? Dann wäre es mir nämlich lieber als eine externe Bibliothek. Außer ihr sagt, dass die Performance von la4j um Welten besser ist, dann probiere ich das mal aus.

Thx, TheLordix
 
Beides externe libs. Apache commons ist meiner Erfahrung nach immer eine gute Wahl, aber auch das la4j macht einen guten Eindruck. Ich würde mir auch nicht zu viele Gedanken um Performance machen. Zumindest im 2D-Bereich ist das doch so simple Mathe, das kann man sich zur Not auch selbst schreiben.

Interessant wäre noch zu vergleichen, ob eine der beiden Optionen unveränderliche (immutable) Objekte, z.B. für Vector2D anbietet. Mit veränderlichen kann man sich viel leichter schwer zu findende Fehler einhandeln.
 
Tumbleweed schrieb:
Zumindest im 2D-Bereich ist das doch so simple Mathe, das kann man sich zur Not auch selbst schreiben.

Interessant wäre noch zu vergleichen, ob eine der beiden Optionen unveränderliche (immutable) Objekte, z.B. für Vector2D anbietet. Mit veränderlichen kann man sich viel leichter schwer zu findende Fehler einhandeln.

gerade bei eigenen, seltenst performancekritischen anwendungen ist die (hoffentlich) hohe codequalität viel mehr wert, so kann man sich viel unnötiges debuggen ersparen.
 
Zurück
Oben