Sinus-Problem

[Socke_SG]

Hallo zusammen,

ich habe ein kleines (Großzahligs Problem). Und zwar möchte ich SinusCosinus-Werte für große Frequenzen ausgeben lassen. Heisst dass das Argument vom Sinus auch den Wert von 1E+15 übersteigen kann. Bis zu dieser Grenze sind alle Sinuswerte zwischen -1 und +1 was ja auch richtig ist. Werte darüber liefenr jedoch Sinus-Werte, die alle Grenzen sprengen. Z.B. sin(5E+19)=5E+19. Sprich der SInus kann diese Zahlen offenbar nicht mehr verarbeiten.
Gibt es nun dabei eine Beschränkung des Zahlenbereichs, den der Sinus (numerisch) verarbeiten kann? Oder gibt es vielleicht einen kleinen Trick dass man doch die richtigen Werte bekommt?

Freue mich auf eure Antworten und bedanke mich schonmal im Voraus

mfg

[edit=Matze]Sprache von "Delphi .NET" in "Delphi Win32" geändert. Das scheint eine "Win32"-Frage zu sein. MfG, Matze[/edit]

[sirius]

:gruebel:

Delphi-Quellcode:

showmessage(floattostr(sin(20e15)));

--> -0,976...
Bei Win32 kein Problem.


Edit: Bei sin(5E+19) kommt bei mir 0 raus. Liegt wohl daran, dass hier die Genauigkeit von Fließkommazahlen zu Ende ist.

[Socke_SG]

Klappt bei mir auch. Aber mit

Delphi-Quellcode:

procedure TFrmClient.Button1Click(Sender: TObject);
var i: integer;
begin
for i:=1 to 600 do begin
testmemo.lines.add(FloatToStr(sin((5E+19)*1)));
end;
end;

dem hier kommen falsche werte raus

[Socke_SG]

Also bei mir kommt mit showmessage bei 5E+19 auch 5E19 raus.... seltsam

Genauigkeit ist gut...der Sinus ist periodisch. Versuchs mal mit anderen großen Werten z.B. 2E+24...kommt bei mir auch 2E+24 raus.

[Wolfgang Mix]

Bei Sinus/Cosinus sind doch nur Werte von 0 bis 2 pi bzw. 0 .. 360 Grad interesssnt.
Alles andere sind Vielfache davon. Was willst Du mit so hohen Werten?

Gruß

Wolfgang

[Socke_SG]

Es ist Teil eines Programms. Dabei sollen Frequenzwerte vorgegeben werden und. Mit diesen Frequenzen werden die Werte berechnet und graphisch dargestellt.
Eine Möglichkeit wäre vielleicht ein ganzzahliges Vielfaches vom Argument mit 2*PI zu mutliplizieren und das vom Argument abzuziehen. Nur irgendwie klappt das nicht, weil dieses ganzzahlige Vielfache den Integerwert übersteigt.

[Wolfgang Mix]

Integerwerte machen bei Sinus/Cosinus sowieso keinen Sinn, denn Minimalwerte sind -1
und Maximalwerte sind +1.
[Edit] Alle wirklich interessanten Werte liegen dazwischen [/Edit]

Gruß

Wolfgang

[Socke_SG]

Eben. Hmm... Dann schau ich mal ob ich das nicht irgendwie anders lösen kann

[himitsu]

Bei so hohen Werten kann nie etwas rauskommen, denn wie schon von Wolfgang Mix gesagt wurde, interessiert nur der untere Anteil (die Wiederholungen von 2*PI).

Und da selbst beim größten Fließkommatypen nur 19-20 signifikante Stellen existieren, ist der wichtige Anteil immer praktisch nicht existent!

[Wolfgang Mix]

Das Problem scheint eher ein elektrotechnisches zu sein.
Mach' Dich 'mal bitte über Frequenz und Periodendauer schlau.

Gruß

Wolfgang

[DeddyH]

Zitat:

Zitat von Wolfgang Mix

Mach' Dich 'mal bitte über Frequenz und Periodendauer schlau.

[OT] Das waren doch so 4 bis 5 Tage, oder nicht? :mrgreen: (Sry, es war stärker als ich ^^) [/OT]

[Wolfgang Mix]

Die fachliche Antwort lautet:

Bei 50 Hertz sind es 20 Millisekunden, also weeeesentlich weniger als Du dachtest :-D

Topic on


Gruß

Wolfgang

[Matze]

Zitat:

Zitat von Wolfgang Mix

Integerwerte machen bei Sinus/Cosinus sowieso keinen Sinn, denn Minimalwerte sind 0
und Maximalwerte sind 1.
[Edit] Alle wirklich interessanten Werte liegen dazwischen [/Edit]

Meine lagen immer zwischen -1 und +1 :zwinker:

[Wolfgang Mix]

Sorry, hast natürlich recht, meine bisher auch :wall:

Gruß

Wolfgang

[Edit] Schnell korrigiert, damit es sonst keiner merkt [/Edit]

[gammatester]

Delphi und Rechengenauigkeit: Das ist leider eine sehr traurige Geschichte. Hier für sin/cos: Die Güte der Implementation nimmt mit den Versionsnummern monoton ab. Für große Argumente wie sin(1e19) signalisiert die FPU ein 'Out of range'. Borland Pascal 7 wirft noch ein RTE 207 (wie's eigentlich sein sollte), bis Delphi 7 wird gecheckt, ob dieser Fall eintritt; dann sin := 0 und cos := 0 gesetzt,

Code:

        FSIN
        FNSTSW  AX
        SAHF
        JP      @@outOfRange
        RET
@@outOfRange:
        FSTP    st(0)   { for now, return 0. result would       }
        FLDZ            { have little significance anyway       }

Irgendwie scheint man bei Borland/Codegier zu hoffen, daß trotzdem noch sin^2 + cos^2 = 1 gilt. Delphi 10 und höher treiben es noch wilder in dem sie (wie schon gemerkt) einfach sin=1e19, cos=1e19 liefern und noch mehr hoffen (2*1e38 = 1 ??)

Natürlich ist sin(1e19) = sin(1e19 mod 2*pi). Das Problem ist also die Reduktion modulo 2*pi. Für sin(1e19) kann man diese Reduktion zB mit double-double Arithmetik angehen. Oder man benutzt gleich Multipräzisionsarithmetik für alle Funktionen.

Mein Delphi-Implementation MPArith rechnet wie folgt:

Code:

Test of MPArith V1.13.03 (15/16 bit) [mp_rcalc]   (c) W.Ehrhardt 2008-2009
Karatsuba  cutoffs: mul/sqr = 64/96
Toom-3, BZ cutoffs: mul/sqr = 128/192,  div = 96
Type "?<enter>" to get some info about commands, "\q" or "quit" to end.
Current bit precision = 240,  decimal precision = 72.2

[D]:=> prec 128
New bit precision = 128,  decimal precision = 38.5
[D]:=> x=sin(1e19)
X = -9.2706316604865038523412228966493597547E-1
Time = 0.275 ms
[D]:=> y=cos(1e19)
Y = -3.7490516955071783015322054600961073097E-1
Time = 0.214 ms
[D]:=> x*x + y*y - 1
Result = 0.0000000000000000000000000000000000000
Time = 0.050 ms

@Socke_SG: Wenn Du also nicht gerade Zillionen Werte ausrechnen mußt, wär das doch vielleicht was für Dich?

Gruß Gammatester