Sinus im Gradmaß berechnen

Bloodymaster

Hallo, ich habe ein Problem mit der Berechnung des Sinus/Cosinus in c++. Ich will ein Programm schreiben, das mir Pi berechnet. Zur Lösung will ich n-Ecke nutzen und folgende Formel verwenden :

(sin (360/n*2)) * (cos(360/n*2)) * n = Pi .

Das Problem ist dass die sinus Funktion der math.h den Sinus im Bogenmaß berechnet ich ihn aber im Gradmaß benötige. Um das Bogenmaß in das Gradmaß umzurechnen benötigt man die Formel :

Gradmaß = Bogenmaß * Pi / 180 .

Ein Programm zum berechnen von Pi sollte nicht Pi benötigen deshalb frage ich, ob es eine Funktion gibt , mit der der Sinus sofort im Gradmaß ausgerechnet werden kann.

SeppJ

Wenn dein Programm zum Berechnen von Pi selber nicht Pi benutzen darf, dann darfst du auch keinen Sinus und Cosinus benutzen, denn die verstecken das Pi bloß (Zumindest im Gradmaß. Und wenn du im Bogenmaß rechnest, dann kennst du Pi sowieso schon).

Was ist denn genau das Ziel der Aktion? Reihenentwicklungen zu Pi gibt es wie Sand am Meer (->Wikipedia), daher bin ich etwas verwundet, dass du eine Rechnung wählst, die trigonometrische Funktionen benutzt, da das (wie oben erklärt) geschummelt ist. Wenn du aber wiederum unbedingt den Ansatz über n-Ecke weiterverfolgen möchtest, dann brauchst du dazu doch weder Sinus noch Cosinus (oder höchstens beim Aufstellen der Formel), am Ende kürzt sich alles Weg und du bekommst einen Ausdruck, wo maximal noch ein paar Wurzeln drin vorkommen (ich nehme mal an, Wurzeln sind erlaubt). Auch dies sollte sich leicht im Netz erklärt finden.

krümelkacker

du hast da übrigens einen dreher drin; denn es ist bogenmaß = winkelmaß*pi/180.

Ich verstehe auch nicht ganz das Problem.

Wie wär's mit std::atan(1.0)*4 ?

SeppJ

krümelkacker schrieb:

Wie wär's mit std::atan(1.0)*4 ?

Oder 103993/33102. Oder der Klassiker: 3 + 0.1415926535

krümelkacker

#include <cassert>
#include <complex>
#include <iostream>

typedef std::complex<double> cdouble;

/// nimmt einen Punkt auf dem komplexen Einheitskreis
/// und gibt einen neuen, auf dem Einheitskreis liegenden, Punkt zurueck,
/// dessen Winkel zur X-Achse nur halb so groß ist wie der vom
/// Eingabepunkt.
cdouble halbiere_winkel(cdouble von)
{
    assert(0.99 < abs(von) && abs(von) < 1.01);
    assert(-1 < real(von));
    cdouble tmp = von + 1.0;
    tmp /= abs(tmp);
    return tmp;
}

int main()
{
    int n = 4;
    cdouble p (0,1);
    // p = cos(360/n) + sin(360/n)*i
    while (n<999) {
        n *= 2;
        p = halbiere_winkel(p);
        // p = cos(360/n) + sin(360/n)*i
    }
    double kantenlaenge = abs(p-1.0);
    std::cout << "halber Umfang eines regelmaessigen " << n << "-Ecks: ";
    std::cout << kantenlaenge*(n/2) << std::endl;
}

Fazit: Die Frage war falsch gestellt.

Bloodymaster

Danke die Lösungen haben geholfen

Stehe ich gerade auf dem Schlauch oder warum möchte ich gerade nicht glauben dass krümels halbiere_winkel-Funktion den Winkel wirklich halbiert?

volkard

Decimad schrieb:

Stehe ich gerade auf dem Schlauch oder warum möchte ich gerade nicht glauben dass krümels halbiere_winkel-Funktion den Winkel wirklich halbiert?

vom Urspung nach VON geht eine Einheit weit schräg hoch.
Davon geht er eine Einheit genau nach rechts.
Man könnte auch vom Ursprung eine Einheit weit nach rechts gehen und dann schräg hoch.
Das ist eine Raute.
Vom Ursprung nach VON+1 die Strecke geht genau durch die Mitte.

Welchen Gedanklichen Fehler mache ich denn gerade, wenn ich mir denke, dass je kleiner der Winkel wird, desto schneller wandert der Schnittpunkt mit irgendeiner -> zur X-Achse <- parallelen Linie nach außen?

ARGZ, dafür wird die Winkelveränderung ja auch immer kleiner beim Halbieren -.- Oh mann...

Ein klarer Fall von zu kompliziert gedacht und zu stümperhaft nicht zuende gedacht!

Edit: angepasst.

dot

Decimad schrieb:

Welchen Gedanklichen Fehler mache ich denn gerade, wenn ich mir denke, dass je kleiner der Winkel wird, desto schneller wandert der Schnittpunkt mit irgendeiner parallelen Linie nach außen?

Solange wird es mit euklidischer Geometrie zu tun haben, schneiden parallele Geraden sich per Definition nicht...