Verwendet ihr manchmal Excel? Für Ingenieure und Informatiker ist das Programm bekanntlich verpönt, aber für einfache grafische Darstellung von Berechnungen ist es mitunter recht brauchbar. 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?
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?
Also nach 10 Perioden ist der Fehler von sin() bei -2.4503E-15. Da kann
man nicht meckern. Die scheinen mit 64bit(double precision) zu rechnen.
EXCEL
=SIN(3600/180*4*ATAN(1))
-2.4503E-15
Gnu-Octave
>> sin(3600/180*4*atan(1))
ans = -2.4492e-015
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?
H. S. schrieb: > Den Vergleich verstehe Ich nicht. Ich rechne =SIN(5*3,1415962) = 2E-5. 4*atan(1) = pi Gnu-Octave >> 4*atan(1) ans = 3.14159265358979 Ich sehe gerade in EXCEL gibt es ein fertiges PI(). =SIN(3600/180*PI()) -2.4503E-15
:
Bearbeitet durch User
...und ein auch nur halbwegs brauchbarer Ingenieur kann Pi ohne Zahlendreher mindestens 15 Stellen aufsagen... Mal probieren: 3,14159265358979323 Geht doch.
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? Dann aber eher mit den Berechnungen davor siehe Beispiel. =360*10-3600.1 +0.1 9.0955E-14 Aber auch da rechnet Gnu-Octave genau den gleichen Fehler.
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.
H. S. schrieb: > Verwendet ihr manchmal Excel? Für Ingenieure und Informatiker ist das > Programm bekanntlich verpönt, aber für einfache grafische Darstellung > von Berechnungen ist es mitunter recht brauchbar. Ich bin kein Ingenieur und ich finde Excel toll, auch für mehr als "einfache grafische Darstellung von Berechnungen". So, so, Excel ist also nur "recht brauchbar"? 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. > > Ist das bekannt? Das ist vollkommen normal. Das Schlüsselwort heißt Numerik und das Problem ist vermutlich der Excel-Benutzer! :) H. S. schrieb: > Den Vergleich verstehe Ich nicht. Ich rechne =SIN(5*3,1415962) = 2E-5. Zum einen solltest Du besser =SIN(5*Pi()) rechnen um mehr gültige Stellen von Pi zu verwenden. Der "Offset", wie Du ihn nennst, wird natürlich mit größerem Koeffizienten viel größer, weil der Fehlerterm wächst. Bin kein Mathematiker, versuche das mal zu zeigen: Die Pi()-Funktion in Excel weicht von der echten Zahl pi ab. => pi<> Pi() Selbst wenn sin(pi)=0 ist, ist in Excel sin(pi())<>0! Die Excel-Funktion Pi() ist nichts anderes als die Zahl Pi zuzüglich eines Fehlers e: Pi()=pi+e Dann ist sin( x*pi() ) = sin( x*(pi+e) ) Daran kann man erkennen: Für betragsmäßig große x wird das Argument um den Fehlerterm x*e verfälscht und dieser Fehler pflanzt sich in das Ergebnis der Sinusfunktion fort. Beispiel: Berechne in Excel sin(Pi()) und sin(1e6*Pi()). Mathematisch ist es dasselbe, numerisch aber eben nicht. Heilung ist möglich! Wenn Du Argumente im Gradmaß vorliegen hast, die Du in das Bogenmaß wandelst, solltest Du das Argument vorher in den Wertebereich von -360 bis +360 normieren: statt sin(winkel/180*Pi()) zu rechnen, rechne sin(rest(winkel,360)/180*Pi()) Bei Argumenten im Bogenmaß gewinnt man meiner Meinung nach nichts, weil man für das Normieren des Arguments ja nur durch das Stummel-Pi() aus der Excel-Funktion dividieren kann, nicht aber durch die lange "echte" Zahl pi.
:
Bearbeitet durch User
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.
Peter M. schrieb: > Bei Argumenten im Bogenmaß gewinnt man meiner Meinung nach nichts, weil > man für das Normieren des Arguments ja nur durch das Stummel-Pi() aus > der Excel-Funktion dividieren kann, Ich nehme aber an, dass Exel genau das intern macht! Wenn Exel den Sin intern in einer Reihe entwickelt macht es einfach Sinn das Argument klein (Pi/2 reicht weil sin/cos symstrien haben) zu halten damit die Reihe in vernüftiger Zeit konvergiert. Falls Exel eine Tabelle benutzt macht es keinen Sinn sie größer als 0 - Pi/2 vorzuhalten. Mann versucht also ALS INGENIEUR von vorn herein Argumente größer +/-Pi zu vermeiden. Z.b. in dem mann nich einfach blauäugig aus 35,64 Umdrehungen ein Bogenmass von 111,966488568 erzeugt und erwartet das Exel daraus einen korrekten Sin macht.
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...
Angehängte Dateien:
Mal eine Zusammenfassung dessen was als Lösungen gepostet wurde in LibreOffice. Have fun...
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(!).
Jemand schrieb: > Bei Rechnungen mit Gleitkommazahlen exakte Ergebnisse zu erwarten sollte > man sich tunlichst abgewöhnen Genauso ist es. Daher benutzt man z.B. für Finanzanwendungen, welche genau sein müssen, den Datentypen "Decimal". Hier eine schöne Abhandlung: https://technet.microsoft.com/de-de/library/ms187912(v=sql.105).aspx
für alle (hier) zu spät gekommenen: die Stellen von PI wurde falsch von Hand eingetippt ...
Hallo Torsten! Torsten K. schrieb: > Mal eine Zusammenfassung dessen was als Lösungen gepostet wurde in > LibreOffice. > > Have fun... Wenn Du die Effekte vergleichen willst, bietet es sich an, ausgezeichnete Werte zu nehmen, bei denen der Pi()-Term im Argument des Sinus nicht wegfällt. Wir wissen: sin (180°)=0. Berechne nun sin(180°) in Excel und addiere Vollkreise auf: sin(180°+360°*n) (n ganzzahlig). Da kann man schön sehen, wie der Fehler wächst. Ich hätte da noch ein Beispiel für Dich, weiß nicht, ob das in Libre Office Basic so läuft:
1 | Sub test() |
2 | Dim x As Long |
3 | Dim y As Double |
4 | For x = 1 To 100 |
5 | y = y + 0.01 |
6 | Debug.Print y |
7 | Next x |
8 | End Sub |
Dimensionier' mal y als Single oder verlängere die Schleife! Mit einer kleinen Code-Änderung, die auf die numerischen Effekte Rücksicht nimmt, zeigt y das gewünschte Verhalten. Thomas S. schrieb: > für alle (hier) zu spät gekommenen: > die Stellen von PI wurde falsch von Hand eingetippt ... Das geht komplett am Kern der Sache vorbei. :)
:
Bearbeitet durch User
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
Waldo et alii, ersetzt mal das n durch 10^n, dann sieht man den Zusammenhang zwischen Zehnerpotenz und Fehler besser.
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
Waldo schrieb: > 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 Es ging mir nur darum, das Fehlerwachstum aufzuzeigen.
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,!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.