3dimensionale Vektorrechnung in Java?

[SimProtect]

Hallo Zusammen,

Im Rahmen der Entwicklung eines weiteren Projekts benötigen eine Umsetzung der Vektorrechnung in räumlicher Dimension. Bei meiner Suche bin ich überwiegend auf unfertige Software oder - wenn überhaupt - auf zweidimensionale Bibliotheken gestoßen, die auch nicht mehr weiterentwickelt wurden.
Dieser "Tradition" folgend hatten wir in unserem SVN auch noch eine Implementierung herumfahren, die aber einerseits nicht vollständig fertig gestellt wurde und andererseits weder dokumentiert / kommentiert noch mit sinnig benannten Methoden versehen wurde.
Ebenso könnte ich ein unfertiges, ungetestes und eher ungeschickt implementiertes Programmschnippsel, das ich "damals" für meine Masterarbeit zusammengestückelt habe.

Kurz: Wir verfügen derzeit über nichts, das ich ruhigen Gewissens irgendwo sinnvoll verwenden kann. Wir benötigen allerdings recht viele Elemente jener Vektorrechnung, die man vorzugsweise damals in der Oberstufe hatte.

• Primär Vektoren und Geraden
  
• Aber auch Untersuchung von Lagebeziehung zwischen Punkten, Geraden, Ebenen und Objekten wie z.B. Kugeln

Nun haben wir uns gefragt, warum man eigentlich für fast alles sinnvolle Bibliotheken in Java findet, aber an solchen Dingen bei der Suche scheitert und dann doch auf andere Sprachen angewiesen ist (korrigiert mich bitte, wenn ich mich irre)

Mögliche Probleme/Fragen, die mir jetzt spontan einfallen wären:

• Zu betrachtenden Rundungsproblematik: Da bin ich zu Studienzeiten in meiner Masterarbeit bereits drauf gestoßen und habe es mehr schlecht als recht umgangen. Hierbei war es zu unschönen Rundungsabweichungen gekommen - so waren faktisch gleiche Koordinaten (bzw. welche, die es nach händischer Berechnung hätten sein sollen) von minimaler Abweichung. Dies konnte zwar angefangen werden, war jedoch eine Problematik, die betrachtet werden muss. - Es kann natürlich auch gut sein, dass ich damals einen Fehler gemacht habe.
• Wie sieht das mit den internen Berechnungsalgorithmen in Java auf unterschiedlichen Prozessorarchitekturen aus? Ich meine mich daran zu erinnern, dass bestimmte Algorithmen leicht unterschiedlich funktioniert hätte und somit auch leichte Abweichung produziert hätte.

Wir wohl oder übel die Berechnungen selbst implementieren - ich wollte mich aber vorher informieren, welche Fallstricke uns in Java hier erwarten könnten oder eine saubere Implementierung vielleicht sogar verhindern.

Wir wissen, dass es sicherlich performanter sein dürfte, eine Bibliothek einer mathematisch orientierten Sprache zu verwenden, jedoch ist dies von unserem Architekten "erstmal" nicht gewünscht.

Sollte uns eine saubere Implementierung gelingen, stellen wir unsere Implementierung natürlich auch gerne zur Verfügung.

Beste Grüße
SimProtect

 

[kneitzel]

Also ich bin im Augenblick leicht verwirrt. Ich habe evtl. die Anforderungen nicht verstanden?

Es gibt diverse Projekte, die auch mit Matrizen rechnen können. Mir fällt da zum Beispiel EJML ein (http://ejml.org/) aber auch Apache commons-math (http://commons.apache.org/proper/commons-math/)

Was an diesen Libraries stört Dich? Oder was genau müsste Deine Library können, das die nicht können?

 

[kneitzel]

Evtl. noch als Ergänzung: http://stackoverflow.com/questions/10815518/java-matrix-libraries - da finden sich noch einige Libraries mehr!

 

[SimProtect]

Hoppala,
Wir haben offenbar beide Projekte übersehen (oder die wurden bei der Suche durch andere bewusst ausgelassen) - ich werde mal mit unserem Architekten sprechen, ob da etwas gegen spricht. Nicht, dass es wieder irgendwelche merkwürdigen Gründe gibt.

Ich persönlich bin - leider - eher mit den Bibliotheken im .NET-Umfeld vertraut und hatte mich daher sehr auf die Aussagen Anderer verlassen, die mir immer wieder sagen, dass es keine entsprechenden Projekte gäbe.

Im Wesentlichen brauchen wir allerdings nicht "merkwürdiges"

• Untersuchung von Lagebeziehungen zwischen 3D-Objekten inklusive Berechnung der Schnittpunkte/Flächen/Kreise/Gerade [...]
• Standardoperationen der Vektorrechnung
• Abstandsberechnung
• Berechnung des Schnittwinkels zwischen Objekten

usw.

Es hätte mich nun auch wirklich sehr gewundert, wenn es nichts entsprechendes gäbe. Tatsächlich hatte ich allerdings bei meiner Suche auch diese Projekte nicht gefunden *schäm*

 

[kneitzel]

Ist ja kein Thema. Würde mich freuen, wenn ich Dir/euch weiter helfen konnte.

 

[JStein52]

Ich denke mal der TE sucht Bibliotheken die ihm Objekte wie Vec3D, Plane und noch so ein paar zur Verfügung stellen und mit denen er dann sowas wie myPlane.intersection(vector) oder myVector.distance(other vector); oder ähnliche Dinge hat. Und das kann weder EJML noch commons.math
Habe ich nämlich auch schon mal gesucht Ich habe dann über Umwege eine selbergemachte Bibliothek der Uni Erlangen-Nürnberg in die Finger gekriegt wo die das auch zu Lehrzwecken selber gemacht hatten.

 

[stg]

Ich denke mal der TE sucht Bibliotheken die ihm Objekte wie Vec3D, Plane und noch so ein paar zur Verfügung stellen und mit denen er dann sowas wie myPlane.intersection(vector) oder myVector.distance(other vector); oder ähnliche Dinge hat. Und das kann weder EJML noch commons.math

Doch?!
https://commons.apache.org/proper/c...commons.math3.geometry.euclidean.threed.Line)
https://commons.apache.org/proper/c...ons.math3.geometry.euclidean.threed.Vector3D)

 

[JStein52]

Ja, ist schon ein paar Järchen her da hats scheinbar ein paar Fortschritte gegeben.

 

[SimProtect]

So, nach längerer Diskussion steht nun fest: Unser Architekt möchte, dass wir das selbst implementieren und der ProductOwner stimmt dem zu. Somit ist die Entscheidung getroffen.
Ansich Schade, da unsere Tests eigentlich gezeigt haben, dass man mit apache-math hätte gut arbeiten können. Aber nun gut -

Danke auf jeden Fall für Eure Hilfe

 

[JStein52]

Hatte das technische Gründe oder mehr logistische oder lizenzrechtliche Gründe ? Wobei es ja an und für sich auch kein Hexenwerk ist sowas selbst zu machen. Ist schliesslich Mathematik für Abiturienten.

 

[SimProtect]

Welche Gründe das hatte, weiß ich leider nicht. Uns wurde nur die endgültige Entscheidung mitgeteilt, die sich aus den Analysen ergeben hat.
Da die Entscheidung letztlich vom Architekten getroffen wurde, würde ich allerdings etwas technisches vermuten. Wir können Ihn derzeit allerdings nicht fragen, da er im Urlaub ist.

Wir hatten allerdings schon ähnliche Diskussionen bezüglich des Einsatzes von Spring und Hibernate. Bei Spring waren wir anfangs sogar soweit, dass wir Dependency Injection selbst implementiert hatten - das wurde später alles durch eine neuere Version von Spring ersetzt (ein Riesenaufwand unser Gerümpel aus dem Code zu entfernen und stattdessen durch Spring zu ersetzen)

Sicherlich ist es kein Hexenwerk - wie gesagt: Mir hatte man nur vorgebetet, es gäbe technische Probleme mit der Berechnung in Java und es gäbe auch keine passenden Frameworks / Bibliotheken.

 

[JStein52]

Sicherlich ist es kein Hexenwerk

Ihr könnt euch ja mal die Sources von commons math anschauen wie die das gemacht haben. Ansosnten viel Erfolg.