Sinusproblem
-
Kekskiller
- Beiträge: 752
- Registriert: 14.09.2004 21:39
- Kontaktdaten:
Sinusproblem
Als ich mich heute abend etwas näher mit den Feinheiten meiner kleinen
Vektorgrafikengine beschäftige, ist mir aufgefallen, dass mit einer Art der
Sinus- und Cosinus-Einbeziehung irgendwie nicht alles hinhaut. Normalerweise
habe ich das immer mit Gradwwerten von 0° bis 360° gemacht, was beispielsweise
in Blitzbasic sehr schön klappte. Aber wo ich jetzt in PB versuche, einiges
umzusetzen/zu portieren merke ich, dass anscheinend nur Gradangaben
von 0 bis Pi (3.141593) wirklich genau umgesetzt werden. Dich bei Cosinus
ist es anscheinend andersherum und das verwirrt mich einigermaßen...
Könnte mir jemand dieses "Phänomen" genauer erklären?
Jedenfalls kann ich so meine Engine nicht qualitativ umsetzen, ich brauch
dazu die "gewissen Feinheiten".
Vektorgrafikengine beschäftige, ist mir aufgefallen, dass mit einer Art der
Sinus- und Cosinus-Einbeziehung irgendwie nicht alles hinhaut. Normalerweise
habe ich das immer mit Gradwwerten von 0° bis 360° gemacht, was beispielsweise
in Blitzbasic sehr schön klappte. Aber wo ich jetzt in PB versuche, einiges
umzusetzen/zu portieren merke ich, dass anscheinend nur Gradangaben
von 0 bis Pi (3.141593) wirklich genau umgesetzt werden. Dich bei Cosinus
ist es anscheinend andersherum und das verwirrt mich einigermaßen...
Könnte mir jemand dieses "Phänomen" genauer erklären?
Jedenfalls kann ich so meine Engine nicht qualitativ umsetzen, ich brauch
dazu die "gewissen Feinheiten".
- Froggerprogger
- Badmin
- Beiträge: 855
- Registriert: 08.09.2004 20:02
PB arbeitet bei den Mathefunktionen konsequent im Bogenmaß.
Siehe dazu auch die Hilfe.
Hier nochmal zum Verständnis und Umrechnen:
(Zu den Variablenbezeichnungen: deutsch: grad = englisch: DEGree, deutsch: bogenmaß = englisch: RADiant)
Siehe dazu auch die Hilfe.
Hier nochmal zum Verständnis und Umrechnen:
Code: Alles auswählen
#Rad2Deg = 180.0/#PI
#Deg2Rad = 1 / #Rad2Deg
grad.f
bogen.f
grad = 45
bogen = #Deg2Rad * grad
Debug grad
Debug bogen
Debug Sin(bogen)
Debug Cos(bogen)
Debug ""
bogen = 3.0/2.0 * #PI
grad = #Rad2Deg * bogen
Debug bogen
Debug grad
Debug Sin(bogen)
Debug Cos(bogen)!UD2
Ich glaub' das hatter schon berücksichtigt, wenns von 0 bis Pi richtig läuft
.
Ich denke, dass die Ungenauigkeit vielleicht mit der von Float zusammenhängt.
Wenn man in BB in Grad rechnet, ist das ja schon Integer, also genau. Die Rückgabe ist zwar auch Float (Ungenau), aber genauer als mit Eingabe und Rückgabe Float.
Ich denke, dass die Ungenauigkeit vielleicht mit der von Float zusammenhängt.
Wenn man in BB in Grad rechnet, ist das ja schon Integer, also genau. Die Rückgabe ist zwar auch Float (Ungenau), aber genauer als mit Eingabe und Rückgabe Float.
God is real, unless declared integer.
-
Kekskiller
- Beiträge: 752
- Registriert: 14.09.2004 21:39
- Kontaktdaten:
Danke an euch. Habe auch mittlerweile was nettes rausbekommen.
Ich hatte nähmlich eine kleine Procedur, welche beliebig viele Ecken in
einen Kreis einbinden konnte, dazu hätte ich sonst 360 / Punkte geschrieben,
aber nach einigem rumprobieren nahm ich mal Pi. Nur da stellte sich raus,
dass alles nur zur Hälfte dargestellt wurde, aber alle Ecken da waren.
Kurz nahm ich das doppelte von Pi: 6.283186
Das habe ich dann entsprechende einbezogen und mir ein paat Zwischen-
konstanten gemacht. Aber wie es ausscheint, kann sollte ich es doch besser
bei Umrechnungsformeln per Grad belassen, Danke jedenfalls.
@Heroglyph:
Bei BB kannste auch Floats per Parameter angeben, eben von 0.0...
bis 360.0... , obwohl man das im allgemeinen nicht so ungeheuer genau braucht
.
Ich hatte nähmlich eine kleine Procedur, welche beliebig viele Ecken in
einen Kreis einbinden konnte, dazu hätte ich sonst 360 / Punkte geschrieben,
aber nach einigem rumprobieren nahm ich mal Pi. Nur da stellte sich raus,
dass alles nur zur Hälfte dargestellt wurde, aber alle Ecken da waren.
Kurz nahm ich das doppelte von Pi: 6.283186
Das habe ich dann entsprechende einbezogen und mir ein paat Zwischen-
konstanten gemacht. Aber wie es ausscheint, kann sollte ich es doch besser
bei Umrechnungsformeln per Grad belassen, Danke jedenfalls.
@Heroglyph:
Bei BB kannste auch Floats per Parameter angeben, eben von 0.0...
bis 360.0... , obwohl man das im allgemeinen nicht so ungeheuer genau braucht
-
Kekskiller
- Beiträge: 752
- Registriert: 14.09.2004 21:39
- Kontaktdaten:
- Froggerprogger
- Badmin
- Beiträge: 855
- Registriert: 08.09.2004 20:02
In Physik kommt das oft vor, wenn man Schwingungen behandelt. (Kreisfrequenz, Winkelgeschwindigkeit, etc.)
Ist aber echt nicht schwer zu verstehen: 2 PI sind nunmal der Umfang des Einheitskreises (also mit r=1). So läßt sich jede Gradzahl einem solchen Wert (genannt Bogenmaß) zuordnen. Z.B. 90 Grad zu PI/2, etc.
Wenn man nun immer im Bogenmaß rechnet kann man also ganz schnell den Kreisabschnitt berechnen. Z.B. legt man auf einem Kreis mit Radius 3 cm eine Strecke von PI/4 * 3 zurück, wenn man 45 Grad vorangeschritten ist.
Ist aber echt nicht schwer zu verstehen: 2 PI sind nunmal der Umfang des Einheitskreises (also mit r=1). So läßt sich jede Gradzahl einem solchen Wert (genannt Bogenmaß) zuordnen. Z.B. 90 Grad zu PI/2, etc.
Wenn man nun immer im Bogenmaß rechnet kann man also ganz schnell den Kreisabschnitt berechnen. Z.B. legt man auf einem Kreis mit Radius 3 cm eine Strecke von PI/4 * 3 zurück, wenn man 45 Grad vorangeschritten ist.
!UD2
-
Kekskiller
- Beiträge: 752
- Registriert: 14.09.2004 21:39
- Kontaktdaten:
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
dann konntest du ja mit meiner bemerkung über arrays
mit sin und cos werten nicht wirklich was anfangen....
so meinte ich das, das spart extrem rechenzeit gegenüber einem funktionsaufruf
in jedem schleifendurchlauf...
mit sin und cos werten nicht wirklich was anfangen....
Code: Alles auswählen
Dim Sinus.f(360)
Dim Cosin.f(360)
pi.f = 3.14159265
for n.f = 0 to 359
Sinus(n) = Sin(n*pi/180)
Cosin(n) = Cos(n*pi/180)
Next nin jedem schleifendurchlauf...