Kann es sein, dass die Math.h Sinus Funktion nicht genau ist?

Ich definiere const double pi = 4 * atan(1.0);
Wenn ich dann den sin(pi) berechne kommt nicht genau 0 raus, aber eine extrem kleine Zahl nah bei null. Der Cosinus wird richtig berechnet.
Runden kann ich mir nicht erlauben, weil dann meine anderen Werte zu stark verfälscht werden würden.
Das ist für mein Programm zu ungenau. Gibt es für das Problem eine Lösung?

Gibt es eine C++ Mathe Bibliothek die den Sinus, Cosinus und Arctangens von 0 bis 360 in Grad berechnet ?

Mein billiger Casio Taschenrechner kann das wunderbar. Da muss es doch auch schon fertige Funktionen können, die es unter C++ genauso berechnen ??

Kommt bei mir -1.#IND000000000000 raus. Frag mich nicht was das heißen soll.

Im übrigen ist C++, wenn es ungenau sein sollte, weniger daran schuld, sondern die FPU deiner CPU die ja die Berechnung durch führt. (sowas machen die FPUs heute in Hardware)

Schau mal am besten hier nach, was du am besten gebrauchen kannst:
http://www.cplusplus.com/ref/cmath/index.html

Und für die 2 Zeilen Code muss man es ja auch nicht übertreiben :p. Die versteht auch jeder ohne schickes code tag.

Der Wert bedeutet, dass es nach negativ unendlich geht. Also, dass die Zahl die rauskommt zu klein ist um sie als double darzustellen.

const double pi = 3.1415926535897932384626433832795; // mehr oder weniger Stellen

bzw.

Und wenn du PI schon selbst mit ner Genauigkeit (Nachkommastellen) berechnen willst musst Du nen bissl selbst Hand anlegen.
Bastel Dir ne Funktion der du die Genauigkeit übergeben kannst, und intern
näherst du Dich mit ner Taylorreihe auf diese Genauigkeit für PI an.

Und mach dann alle nötigen Berechnungen.

mfg sclearscreen

Kommt bei mir -1.#IND000000000000 raus. Frag mich nicht was das heißen soll.

Das heißt, dass arc sin π nicht definiert ist.

Gibt es denn keine vernünftige freie Mathe Bilbiolthek ?

Ich habs schon mit 60 Nachkommastellen probiert und es kommt nicht richtig raus.
Wenn mein billger Taschenrechner aus Schulzeiten das hinbekommt, muss es doch auch ne komfortabler Lösung unter C++ geben.

Gibt es denn keine vernünftige freie Mathe Bilbiolthek ?

Ja, dann scheinen die hyper mega Pentium 4er nichts zu bringen? Keine Ahnung...

Freie Mathelibs gibts, google ist dein Freund, Suchworte: c++ math lib

1. Ergebnis: http://www.thefreecountry.com/sourcecode/mathematics.shtml

Und suchst dir eine aus, z.B.: http://www.oonumerics.org/blitz/ ist die bekannteste.

Wenn mein billger Taschenrechner aus Schulzeiten das hinbekommt, muss es doch auch ne komfortabler Lösung unter C++ geben.

Jaja, der rechnet auch nur gerundete Werte aus...

Bye, TGGC

Ich habs schon mit 60 Nachkommastellen probiert und es kommt nicht richtig raus.

"Richtig" liegt hier wohl im Auge des Betrachters
Das "Problem" ist, dass man sich mit Fließkommazahlen sehr sehr weit an 0 annähern kann, nur der Exponent bildet die Grenze. Also 10^-200 ist überhaupt kein Problem.
Du kannst dich aber nicht soweit an 1 annähern (du sagtest, der cos(0) wär genau), da hier die Anzahl der signifikanten Stellen ins Spiel kommt. Es ist da eben 1,0000000001*10^0 und nicht 1 + 10^-9 ... demzufolge ist die Angabe 1 als Ergebnis im Grunde ungenauer als das, was du beim sin(0) rauskriegst.

Wenn mein billger Taschenrechner aus Schulzeiten das hinbekommt, muss es doch auch ne komfortabler Lösung unter C++ geben.

Hast du mal dran gedacht, dass der vielleicht einfach rundet? Oder 0 als Spezialfall behandelt, damit Schüler keine Panik kriegen?

Vielleicht sollte ich mal an Casio schreiben und fragen wie die das machen .

Das Problem mit der genaueren/ungenaueren Berechnung von C++ ist, dass dadurch bei mir völlig falsche Werte rauskommen, die das gesamte Programm sozusagen "sabotieren".

Aber vielleicht kennt ihr eine bessere Lösung.

Das Grundproblem ist folgendes. Es geht mal wieder um das Farbmodell HSI ;-).

Es gibt ein 2 Dimensionales Feld mit, nenen wir es HSI-Pixeln Werten.
Nebeneinanderliegende Pixel werden, wenn sie ein gewisses Kriterium erfüllen (Distanz des Farbwertes zum Beispiel) zu Regionen zusammengefasst.
Wenn jetzt ein Pixel zu einer Region hinzugefügt wird, dann muss man den Mittelwert von H, S, I bilden (also Aktualisierung der Mittelwerte).

Von S und I ist das kein Problem. Da H ein Winkel ist wird der Mittelwert folgendermaßen berechnet.

A = Summe aller cos(H)
B = Summe aller sin(H)
Mittelwert von H = atan( B / A);

H ist normalerweise im Bereich von 0 bis 360 grad.
Kurioses Phänomen, wenn ich oben genannte Formeln mit meinem Taschenrechner der auf grad eingestellt ist mit rad Werten rechne kommt immer das richtige raus. Wenn jemand weiß, warum das so ist und wie man den Effekt in C++ nachstellen kann werd ich vor Freude explodieren .

Wenn ich es mit grad werten rechne, muss ich ganz normal berücksichtigen in welchem Quadranten des Einheitskreises ich mich befinde und basierend darauf die Berechnung anpassen.

In C++ ist jetzt schon mal das Problem, dass von -pi bis +pi gerechnet wird, man also den H Wert schon mal grundsätzlich in diesen Bereich transformiern.
Bei jeder Aktualisierung des Mittelwertes von H müssen jetzt wieder Bereichsprüfungen gemacht werden, sowie auf Sonderfälle wie 0, 180 und -180 geprüft werden (bzw. 0, pi, -pi). Die Sonderfälle werden aber schon gar nicht erkannt, da wegen (ganz ganz) obigem Problem diese nicht eindeutig abgefragt werden können.
Die Farbmittelwert werden stark verfälscht, was zu weiteren Folgefehlern führt usw.

Ich habe da einfach keinen Durchblick mehr, wie man das Problem lösen kann.

Das Problem lag primär an einer anderen Stelle *erröt*, die mit dem Problem nix zu tun hat. ähem

Aber wenn Euch trotzdem ne elegantere Lösung (für obiges Problem) einfällt, fände ich das super :).

Die Sinusfunktion ist eine unendliche Reihe, insofern gibt Dein Taschenrechner und jeder Rechner der Welt, der den Sinus durch eben eine solche Reihe approximiert niemals den genauen Wert an.
Davon abgesehen liegt die Maschinengenauigkeit sowieso bei 10^-16. Was genaueres als das solltest Du nicht erwarten.

Und nochwas: Woher weisst Du, dass Dein Taschenrechner immer richtig rechnet und nicht einfach Standardwerte für 0 und 90° etc. benutzt und ansonsten ziemlich miese Approximationen ausspuckt? Woher weisst Du, dass C++ so falsche Werte ausspuckt? Hast Du mal von Hand eine Taylorapproximation von einem willkürlichen Wert (z.B 0.5471) bis zur gewünschten Genuaigkeit berechnet und dann das Deinen Taschenrechner / C++ Programm machen lassen und verglichen?

Gruss

turing

Hier ein Beispiel wie man damit leben kann:

double d=5.5;//keine ahnung ob das jetzt eine schlecht darstellbare zahl ist
//schlecht
if(d==5.5){
    //...
}
//besser
if((d-5.5)<=0.00001){//für den genauen wert gabs glaub ich was bei den numic_limits...
     //...
}

Darf keine Probleme machen, denn intern sollte die Maschine wenigstens identische Rundungsfehler machen.

Davon mal abgesehen, wieso brauchst Du eigentlich super genaue Sinus und Cosinus-Werte. Schlussendlich musst Du sie auch wieder speichern und dabei entstehen wieder Fehler.

Gruss

turing

@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.

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

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?

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.

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

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

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.