Möglichkeit cartesianAngle(Sin[c],-Cos[c]) weiter zu optimieren?
-
Das sieht aus wie der entsprechende Gegenwinkel unter anderem Vorzeichen.
Die atan2 Funktion nimmt bei negativen y, den Winkel mit negativem Vorzeichen. Hast also einen Wertebereich von [-pi, pi]
Bei deiner cartesian_angle Implementierung nimmst du jeweils den positiven Winkel und hast den Wertebereich von [0, 2pi]
Bei folgendem Link findest du 'ne ganz nette Grafik, die den Wertebereich des atan2 wiedergibt: https://de.mathworks.com/help/fixedpoint/ref/atan2.html
-
Und bevor jetzt groß um den Unterschied herum gearbeitet wird: Wenn der Code zur Weiterverarbeitung des Ergebnisses etwas taugt, sollte es ihm egal sein, ob man 350 Grad oder -10 Grad sagt. Ist schließlich die gleiche Richtung, die man damit beschreibt.
-
Ich hab jetzt mal Testweise die cartesian_angle durch std::atan2 ersetzt und die Berechnung liefern immer noch identische Ergebnisse zum Original
- auch die Reduzierung auf nur Cos[c],Sin[c] funktioniert - weniger geht nicht - noch mal 10-20sek schneller Jetzt muss ich nur noch herausbekommen ob das anderer Verhalten von atan2 an den bestimmten Stellen problematisch sein kann
bisher vielen Danke für alle Tips
-
Lass mich raten: Der Winkel wird dann sowieso wieder in irgendwelche anderen trigonometrischen Funktionen eingesetzt. Falls ja, kann man sich das ganze Theater auch sparen und gewinnt ungeheuer viel Zeit.
Faustregel: Eine konkrete Winkelangabe ist etwas, das man praktisch niemals innerhalb einer Rechnung benötigt. Einen Winkel tatsächlich auszurechnen ist etwas, das man fast immer nur ganz am Ende macht, damit sich beispielsweise ein Mensch ein schönes Bildchen mit den Ergebnissen zeichnen möchte. Beim Numbercrunching selbst ist es (gewaltige!) Zeitverschwendung, Winkel zu berechnen.
-
Lass mich raten: Der Winkel wird dann sowieso wieder in irgendwelche anderen trigonometrischen Funktionen eingesetzt. Falls ja, kann man sich das ganze Theater auch sparen und gewinnt ungeheuer viel Zeit.
genau so ist es - es gehen als Parameter {sin(c),-cos(c)} in eine If-Orgie mit Atan,Cot und Tan usw. ein - und nach der Vereinfachung(durch atan2) kommt raus das das Ergebnis einfach immer {cos(c),sin(c)} ist - das hatte ich gehofft
jetzt ist nur noch eine (wieder sehr aehnliche) Rotations-Party übrig welche dieses {cos(c),sin(c)} nutzt - mal schauen ob das auch so zusammenfällt wie bei diesen Punkt hier
nochmals Danke
-
Nach meinem Gefühlt reduziert sich dadurch auch die Ungenauigkeiten - und wenn am Ende nur noch sin(c) und cos(c) übrig bleiben gibt es dafür bestimmt auch noch eine schöne SSE2/3/4... sincos, whatever Lösung - danach kann ich immer noch die Eingangsdaten mit n Threads durchkauen - aber eben erst mal schauen das Single-Threaded alles rausgeholt ist
-
Wie gesagt, die Lösung ist bestimmt eher beim Algorithmus für das Gesamtproblem bzw. der Mathematik zu suchen, als in der technischen Umsetzung dieses kleinen Abschnitts.
-
Wie gesagt, die Lösung ist bestimmt eher beim Algorithmus für das Gesamtproblem bzw. der Mathematik zu suchen, als in der technischen Umsetzung dieses kleinen Abschnitts.
Das ist mit klar - ich probiere das auch nur so weil der Algorithmus auch schon mit dieser Vorgehensweise ins fast nichts verdampft - und er auch nicht so gross ist
-
Mal aus Neugierde: Du hast geschrieben, dass es sich um eine 5 Achsen Kinematic handelt.
Meinst du damit tatsächlich, ein Glied, welches durch 5 Achsen angesteuert wird? Oder eine kinematische Kette mit 5 Gelenken?
Und geht es nur um die Vorwärts Kinematik, also die Bestimmung des Endpunktes, oder auch die Rückwärtskinematik?
Ich frage, weil ich mich damit selbst mal rumschlagen musste und mir damals zwischenzeitlich ganz schön einen abgebrochen habe
-
Meinst du damit tatsächlich, ein Glied, welches durch 5 Achsen angesteuert wird? Oder eine kinematische Kette mit 5 Gelenken?
es sind 2 Glieder mit 3 und 2 Achsen
Und geht es nur um die Vorwärts Kinematik, also die Bestimmung des Endpunktes, oder auch die Rückwärtskinematik?
nur Endpunkbestimmung
