Genauigkeit des Sinus in Excel

naja so einfach bekommst du in excel auch keine schönen grafiken... soll 
aber jetzt nicht das thema sein.

ich nehme stark an, dass das ein generelles genauigkeits problem von den 
verwendeten floating point operationen ist...

https://support.microsoft.com/de-de/help/78113/floating-point-arithmetic-may-give-inaccurate-results-in-excel

wie viel bist du von 0 entfernt? wenns irgendwo um 10e-5, 10e-6 ists 
definitiv so..

H. S. schrieb:
> Ich habe nun aber festgestellt, dass der Sinus nicht sonderlich genau zu
> sein scheint: Schon nach einigen Perioden ist man bei Vielfachen von 180
> Grad nicht mehr genau auf 0, da scheint sich was zu verschieben.

die Frage ist doch wie du das berechnest?

Den Vergleich verstehe Ich nicht. Ich rechne =SIN(5*3,1415962) = 2E-5.

H. S. schrieb:

> Den Vergleich verstehe Ich nicht.
> Ich rechne =SIN(5*3,1415962) = 2E-5.

Das ist nicht Dein Ernst?!

Excel ist schuld, weil Du einen falschen Wert für Pi
verwendest?

...und ein auch nur halbwegs brauchbarer Ingenieur kann Pi ohne 
Zahlendreher mindestens 15 Stellen aufsagen...

Mal probieren:

3,14159265358979323

Geht doch.

Gibt in Excel auch ein PI()

SIN(5*PI()) ist bei mir 6.12574e-16

Keine Ahnung wie das hier kommt. Richtig ist, dass Ich das PI mit zu 
wenigen Stellen eingetragen habe. Ich habe aber auch schon aufwändigeres 
mit der Funktion PI selber berechnen lassen. Kam trotzdem ein Offset 
rein.

Kann es sein, dass der mit Zwischenergebnissen rechnet?

H. S. schrieb:
> Richtig ist, dass Ich das PI mit zu
> wenigen Stellen eingetragen habe.

...die auch noch falsch waren!
(3,1415962 statt 3,1415926)

H. S. schrieb:
> Keine Ahnung wie das hier kommt. Richtig ist, dass Ich das PI mit
> zu
> wenigen Stellen eingetragen habe. Ich habe aber auch schon aufwändigeres
> mit der Funktion PI selber berechnen lassen. Kam trotzdem ein Offset
> rein.
>
> Kann es sein, dass der mit Zwischenergebnissen rechnet?

Bei Rechnungen mit Gleitkommazahlen exakte Ergebnisse zu erwarten sollte 
man sich tunlichst abgewöhnen, es liegt in der Natur der Dinge, dass das 
nicht klappt.

Das ist schon klar, wobei manchmal schon auch exakte Berechnungen 
gebraucht werden. Normalerweise rechne Ich das mit einer Varianzrechnung 
durch.

Warum es bei manchen Berechnungen trotzdem klemmt, muss Ich nochmal 
schauen. Ich mache sicher nicht überall Tippfehler.

H. S. schrieb:
> Warum es bei manchen Berechnungen trotzdem klemmt, muss Ich nochmal
> schauen. Ich mache sicher nicht überall Tippfehler.

Wie schon oben gesagt: es liegt in der Natur der Dinge. Float bietet 
einen großen Dynamikumfang aber nur begrenzte Genauigkeit. Auch bei 
double precision ist das nicht viel anders. Wenn du wirklich exakt 
rechnen möchtest, so musst du auf eine besser geeignete Darstellung 
wechseln. z.B. 128-bit fixed point mit passender Skalierung.

Falls du Ingenieur bist, ist das Problem wohl eher, dass dazu kein 
Zahlenverständnis mehr notwendig scheint.

Eine Abschätzung der Genauigkeit und eine eigenständige Prüfung bei 
Tippfehlern(!)  könnte man von Ingenieuren erwarten.

Und darum ist Excel ein hervorragender moderner Rechenschieber, der für 
99,9% der Aufgaben eines Ingenieurs super ist.

Wie hoch ist der Klirrfaktor?

H. S. schrieb:

> Verwendet ihr manchmal Excel?

Ziemlich oft sogar.

> Für Ingenieure und Informatiker ist das
> Programm bekanntlich verpönt

Nur Idioten tun das. Richtige Ingenieure und Informatiker kennen die 
Fähigkeiten und Grenzen ihrer Werkzeuge...

> Ich habe nun aber festgestellt, dass der Sinus nicht sonderlich genau zu
> sein scheint: Schon nach einigen Perioden ist man bei Vielfachen von 180
> Grad nicht mehr genau auf 0, da scheint sich was zu verschieben.
>
> Ist das bekannt?

Ja. Es ist wohldokumentiert, dass Excel mit Gleitkomma in 
"single"-Auflösung rechnet. Jeder, den es überrascht, dass da 
gelegentlich nicht ganz das Erwartete rauskommt, ist ein Idiot, nicht 
wert, sich "Ingenieur" oder "Informatiker" zu nennen.

Mehr noch: auch wenn Excel mit "double" oder noch mehr rechnen würde: 
Auch dann kann man nie davon ausgehen, das immer exakt das Erwartete 
rauskommt. Das liegt einfach daran, das keins dieser Formate mit einer 
UNENDLICHEN Stellenzahl rechnet, denn das würde unendlich lange 
dauern. Blöderweise ist aber der Zahlenraum der rationalen Zahlen 
unendlich fein geteilt, weswegen es VÖLLIG SELBSTVERSTÄNDLICH ist, 
dass Fehler auftreten MÜSSEN.

Kompetente Ingenieure und Informatiker wissen das nicht nur (weil sie es 
in "Numerik" gelernt haben), sondern können sogar proaktiv 
Gegenmaßnahmen treffen. Z.B.: zu entscheiden, dass ein konkretes Problem 
mit der Rechengenauigkeit von Excel nicht hinreichend zuverlässig lösbar 
ist...

Das funktioniert im Prinzip wie im Handwerk, wo z.B. der Schlosser auch 
kompetent entscheidet, dass er mit einer Schlüsselfeile keinen 800er 
T-Träger sinnvoll getrennt bekommt, sondern dass dafür wohl die große 
Flex oder der Schneidbrenner das besser geeignete Werkzeug wäre...

Kompetenz heißt: Viele Werkzeuge beherrschen und das richtige für das 
gegebene Problem wählen...

H. S. schrieb:
> Für Ingenieure und Informatiker ist das
> Programm bekanntlich verpönt


Die erstellen Ihre Tabellen auch noch mit Papier und Bleistift - einfach 
Lächerlich!

> Blöderweise ist aber der Zahlenraum der rationalen Zahlen
> unendlich fein geteilt, ...

Zu allem Überfluss gibt es dann auch noch irrationale Zahlen,
solche wie "e", √(2), oder gar Pi(!).

Jeder Computer hat zu wenig Speicher um Pi darstellen zu können.

Mal davon abgesehen, dass sich der TO vertippt zu haben scheint, um 
Excel einen Fehler nachzuweisen ...

... und es auch irgendwo klar ist, dass das schlaueste Programm nicht 
beliebig genau rechnen kann ...

... macht es IMO doch irgendwie Sinn zu fragen, ob Excel für Ingenieure 
taugt und wofür.

Als Beispiel bringe Ich mal:

sin(2 - 3) = sin(2) * cos(3) - cos(2)*sin(3) = sin(-1)

Fehler im Bereich E-12. Das finde Ich doch schon mal gut.

Also wenn ich rechne:

Sin((180+n*360)/2/pi())

Dann kommt etwas um 1e-16 für n=1 und 1e-14 für n=65.

Das ist vermutlich besser als ein 12bit Wert von einem
ADWandler bei dem 1-2 Bit flattern.

Waldo

Quatsch:

Sin((180+360*n)/360*2*pi())

Waldo

Für mich stellt sich eher die Frage, wann ich einen Winkel mit 10^16 
Grad verrechnen muß und genau den Nullpunkt treffen muss.
Wenn ich das in meiner Software brauche, dann muss ich womöglich anders 
programmieren.

Waldo

Ein Double hat eine Genauigkeit von 17 Stellen. Wenn ich 10^17 Grad 
haben will liegt die Genauigkeit bei 1 Grad. Der Fehler dürfte also bei 
180+/-1 Grad liegen.
Also:
Sin(1/360*2*pi())= 0,01745

Waldo

Peter M. schrieb:
> Waldo et alii,
>
> ersetzt mal das n durch 10^n, dann sieht man den Zusammenhang zwischen
> Zehnerpotenz und Fehler besser.

Sowas meinte Ich z.B. ja,!