Probleme mit "ungenauer" Sinusberechnung
-
@Turing: Das ungenau war schon aus einem Grund in Anführungsstrichen geschrieben, aber das ist wahrscheinlich zu trivial, um von allen verstanden zu werden .... Wie ein anderer Autor hier treffend schrieb, können solche Sachen im Auge des Betrachters liegen, also wäre super wenn mal produktiver Beiträge kommen, als immer wieder die gleiche Korrektur von genau/ungenau.
@all:
"Richtige" Werte war anscheinend irreführend ausgedrückt,
Wenn Du einen Wert nimmst, beispielsweise 155 für H. Dann müsste ja nachdem man die Formeln berechnet hat wieder 155 oder was in der Nähe rauskommen.
Unter C++ muss man jeztz schon mal bei der atan Berechnung berücksichtigen in welchem Quadranten des Einheitskreises H liegt (Sonderfälle sind immer noch 0, pi, -pi).Beim Taschenrechner ist es aber so, dass ich wenn ich ihn auf grad einstelle und mit rad Werten im Bereich von H=0...360 fülle, immer das gewünschte Ergebnis erscheint (ohne Berücksichtigung irgendwelcher Quadranten oder von Sonderfällen). Das ist eigentlich merkwürdig, aber für das was ich will gut. Also frag ich micht, ob man das so nicht auch in C++ hinbekommt und wieso, dass beim Taschenrechner überhaupt so ist.
@otze:
Die Sonderfälle frag ich jetzt als Berech ab. Danke für einen der wenigen produktiven Beiträge.
-
Sel schrieb:
Beim Taschenrechner ist es aber so, dass ich wenn ich ihn auf grad einstelle und mit rad Werten im Bereich von H=0...360 fülle, immer das gewünschte Ergebnis erscheint (ohne Berücksichtigung irgendwelcher Quadranten oder von Sonderfällen). Das ist eigentlich merkwürdig, aber für das was ich will gut. Also frag ich micht, ob man das so nicht auch in C++ hinbekommt und wieso, dass beim Taschenrechner überhaupt so ist.
Kannst du mal die Formeln dafür posten? Das hört sich ja fast so an, als wär die ganze Geschichte mehr oder weniger invariant gegenüber den verwendeten Funktionen
-
Ach so, ne mir ist wieder eingefallen warum es beim Taschenrechner geht. Ihr müsst mir schon verzeihen, ich bin etwas verzweifelt wegen dem Programm und seh den Wald vor lauter Bäumen nicht. Aargh
In dem ich die rad Werte eingebe werden sie vom Taschnrechner natürlich denoch wie grad brechnet. Da da rad Werte von 0..360 erstens eindeutig und zweitens in einen günstigen kleinen Bereich fallen kommt immer das gewünschte/richtige raus.
Unter c++ geht das nicht, weil eh schon mit rad gerechnet wird. Wenn man die jezt noch mal in einen günstigen Bereich normalisiert, ... könnte das .... Muss ich mal länger drüber nachdenken.
Müsst man im Prinzip eine Funktion schreiben, die Sinus und Cosinus mit grad berechnet. Gibt es das schon?
-
Wenn du weißt, wie man rad in grad und umgekehrt umrechnet schon.
-
Ja, das weiß ich. Aber ich seh nicht wie mir das weiterhilft?
-
Sel schrieb:
Ja, das weiß ich. Aber ich seh nicht wie mir das weiterhilft?
Ja überleg doch mal. Du hast ne Funktion die mit rad arbeitet, weißt aber wie man von Grad in rad umrechnet.
-
Ist wahrscheinlich auch zu trivial...
-
Entweder reden wir aneinander vorbei oder ich kapier nicht was ihr mir sagen wollt.
Vielleicht noch mal ganz für doof erklären ??Ich weiß wie ich den Sinus in c++ berechne. Das ist ja nicht mein Problem, sondern, dass man aufgrund der -pi bis +pi Verteiling der Werte immer noch Abfragen muss in welchem Quadranten des Einheitskreises man sich befindet und sich darauf basierend die Rechnung von H Mittelwert : atan( B / A) ändert (dazu kommen halt die viel beschriebenen Sonderfälle).
Ich will die Rechnung aber so haben, dass es keine Sonderfälle gibt (wie es halt mit dem Taschenrechner durch Normalisierung der Werte in einen kleinen Bereich geht).
Ich hab die Lösung auf jeden Fall jetzt glaub ich endlich gefunden. Man erziehlt den gleichen Effekt wie beim Taschnrechner, folgendermaßen:
double d = 360;
d= d * pi / 180;
d= d * pi / 180;Dadurch bringt man die rad Werte in einen ähnlich kleinen Bereich wie bei der Taschnrechner Methode, und alle Berechnung laufen wie von mir gewollt komfortable und einfach ab.
Wenn Ihr mir das sagen wolltet mit Euren Beiträgen dann habe ich es aus Euren Beschreibungen leider nicht verstanden. Nächstes Mal bitte mit der Holzhammermethode erklären.
Vielen Dank für die Aufmerksamkeit
.@Turing: Wenn Du dich nur streiten willst und nichts produktives beizutragen hast, spar Dir doch einfach die Zeit und antworte nicht.
-
Wenn Du dich nur streiten willst und nichts produktives beizutragen hast, spar Dir doch einfach die Zeit und antworte nicht.
Ich finde es nur nicht sehr nett, wie Du antwortest. Schließlich wollte ich nur helfen!
In Zukunkt werde ich mir dann unproduktive Beiträge Dir gegenüber halt sparen...Gruss
turing
-
Er kennt den Unterschied zwichen grad und rad nicht. Hab mir schon früher nicht erklären können was mit
Sel schrieb:
In dem ich die rad Werte eingebe werden sie vom Taschnrechner natürlich denoch wie grad brechnet. Da da rad Werte von 0..360 erstens eindeutig und zweitens in einen günstigen kleinen Bereich fallen kommt immer das gewünschte/richtige raus.
oder
Sel schrieb:
Beim Taschenrechner ist es aber so, dass ich wenn ich ihn auf grad einstelle und mit rad Werten im Bereich von H=0...360 fülle, immer das gewünschte Ergebnis erscheint (ohne Berücksichtigung irgendwelcher Quadranten oder von Sonderfällen). Das ist eigentlich merkwürdig, aber für das was ich will gut.
meint. Na dann ist ja jetzt alles gut
Sel schrieb:
Ich hab die Lösung auf jeden Fall jetzt glaub ich endlich gefunden. Man erziehlt den gleichen Effekt wie beim Taschnrechner, folgendermaßen:
double d = 360;
d= d * pi / 180;Ja das stimmt so rechnet man von grad nach rad um.
Kurt
-
Es geht doch gar nicht um die Umrechnung von Rad nach Grad. Wie das geht war schon beim ersten Beitrag des Themas bekannt.
Anscheinend kann man das Problem in nem Forum nicht genau genug erklären.
Das Hauptproblem ist die vernünftige Mittelwertbildung von Winkeln... aber Schwamm drüber.