|
|---|
|
1. Beispiel f(x) = 1/x² Fläche A [1;b[ lim b → ∞ A = Integral [1;b[ 1/x² dx A = [-1/x] [1;b[ A= -1/b - (-1/1) A = 0 + 1 A = 1 doch fürs Integral [1;10^99] 1/x² dx gibt der eine Rechner das Ergebnis 0 der andere 5,35 * 10^-86 2. Beispiel f(x) = e^x Ableitung = (e^(x+h) - e^x) / h Ableitung= ((e^x)*(e^h) - e^x) / h Ableitung = ((e^x)*((e^h) - 1) / h Ableitung = (e^x)*((e^h) - 1) / h der Term ((e^h) - 1) / h müsste für h → 0 gegen 1 laufen Das ist für die Funktion f(x) = ((e^x) - 1) / x eigentlich auch der Fall, doch für ((e^10^-99) - 1) / 10^-99 gibt der eine Rechner das Ergebnis 0 der andere 3,78 * 10^98 Für alle, die mir helfen möchten (automatisch von OnlineMathe generiert): "Ich möchte die Lösung in Zusammenarbeit mit anderen erstellen." |
| Hierzu passend bei OnlineMathe: Flächenberechnung durch Integrieren Stammfunktion (Mathematischer Grundbegriff) Ableitung (Mathematischer Grundbegriff) Differenzenquotient (Mathematischer Grundbegriff) Differenzierbarkeit (Mathematischer Grundbegriff) Ableitung einer Funktion an einer Stelle (Mathematischer Grundbegriff) Ableitungsfunktion (Mathematischer Grundbegriff) Ableitungsregeln (Mathematischer Grundbegriff) Online-Übungen (Übungsaufgaben) bei unterricht.de: Ableiten mit der h-Methode Ableitungsregeln für Polynomfunktionen Extrema / Terrassenpunkte Kettenregel Ableiten mit der h-Methode Ableitungsregeln für Polynomfunktionen Extrema / Terrassenpunkte Kettenregel |
|
|
|
1. ist richtig. www.wolframalpha.com/input?i=integrate+1%2Fx%5E2+from++1+to+infinite 2. An dieser Stelle kommt die Definition von ins Spiel. Die Zahl ist genau so definiert, dass die Steigung der Funktion ex an der Stelle exakt 1 beträgt. Welche Rechner benutzt du? |
|
|
Hallo Das klingt nach Rechnergläubigkeit, numerischen Schwierigkeiten, ungünstigen Eingaben, . Du lässt nicht wissen, welche 'Rechner' du nutzt, was du eingegeben hast, wie die internen Algorithemen damit umgehen. Nur als Ahnung: Bei deinem ersten Beispiel hast du vermutlich einen numerischen Rechner & Algorithmus genutzt und blauäugig als obere Grenze eingegeben. Selbst wenn der Rechner (äquidistante) Schritte nutzen sollte, hat der erste Schritt die Schrittweite Oh je, oh je, was soll da Sinnvolles dabei raus kommen? Es gelten eben die alte Regeln: shit in, shit out; ein wenig Mitdenken und sinnvolle Eingaben nimmt dir kein Rechner ab. PS, zu 2.Beispiel: Zitat: "eigentlich schon der Fall, doch für" . Wenn man sich das mal bildlich vor Augen führt, dann steht da sinngemäß: Und jetzt mach dir klar, dass ein Rechner diese beiden Zahlen intern in Speicher-Darstellung darstellen und voneinander abziehen sollte. Das können vielleicht einzelne spezielle CAS, ganz sicherlich aber nicht gewöhnliche Taschenrechner. |
|
|
> doch für > ((e^10^-99) - 1) / 10^-99 > gibt der eine Rechner das Ergebnis 0 > der andere 3,78 * 10^98 Dazu braucht man Informationen über das interne Format der verwendeten Floating-Point-Zahlen. 0 ist plausibel für alle gängigen IEEE754-Formate, da dort sofort zu 1 gerundet wird - klar, wenn man z.B. bei 64Bit-Floatingpoint nur ca. 16 Dezimalstellen Genauigkeit hat. Die Subtraktion ergibt dann natürlich 0. Szenarien für das andere Ergebnis "3,78 * 10^98" fallen mir allerdings nicht ein. Man sollte Berechnungsformeln auf solche Auslöschungsgefahren abklopfen und nach Möglichkeit in "robustere" Varianten umformen - Beispiel: für betragsmäßig sehr kleine Werte wird instabil, wenn man es genau so berechnet. Nutzt man hingegen die dritte Binomische Formel , so sieht das deutlich besser aus. Im Falle der obigen e-Funktion kann bereits der Einsatz einer Taylorformel mit nur wenigen Gliedern der Auslöschung trotzen. |
|
|
>Welche Rechner benutzt du? Ti nspire und Geogebra Für f(x) = ((e^x) - 1) / x sieht es in der Grafik ja bei beiden so aus, als ob das für x →0 auch gegen 1 läuft, zoomt man näher ran, erhält sieht man, dass es denm Rechner doch nicht so klar zu sein scheint. Man kann das ja noch weiter aufteilen in f(x) = (e^x)/x - 1 / x . Der Term 1 / x sollte ja für x →0 gegen unendlich laufen. Der Term (e^x)/x läuft für für x →0 auch gegen unendlich. So kommt man also nicht weiter. Geogebra: (e^0.01)/0.01 - 1 / 0.01 = 1,005 (e^0.001)/0.001 - 1 / 0.001 = 1,0005 (e^0.0001)/0.0001 - 1 / 0.0001 = 1,0001 (e^0.0000001)/0.0000001 - 1 / 0.0000001 = 1 Für f(x) = 1/x² ist das Ergebnis Integral [1;10^99] = 0 auf jeden Fall falsch. Die Fläche kan ja nicht kleiner werden Mathematisch interessant ist ja, dass das Integral [1;b] für b → unendlich für f(x) = 1/Wurzel(x) auch gegen läuft für f(x) = 1/x² jedoch gegen 1 obwohl beide Funktionen ja gegen Null laufen. [(x^(3/2))*2/3] [1;b] für b → unendlich = unendlich – 2/3 = unendlich > und blauäugig als obere Grenze 10^99 eingegeben Der Ti nimmt eigentlich selbst 9^999 für unendlich, fürs Integral [1;9^999] 1/x^2,dx kommt allerdings „Überlauf“ |
|
|
"Ti nspire und Geogebra" Die zählen ganz gewiss nicht zu Programmen, die intern darstellen und damit umgehen können. |
|
|
Bleibt nocht die Frage, warum das Integral im Interval [1;unendlich[ für 1/x² gegen eine feste Größe läuft und für 1/Wurzel(x) gegen unendlich, obwohl beide Funktionen für x gegen unendlich gegen Null laufen? [-1/x] [1;b] für b → unendlich = 0 - (-1) = 1 [(x^(1/2))*2] [1;b] für b → unendlich = unendlich - 2 = unendlich |
|
|
Das ist jetzt aber eine ganz andere Frage. Alle Integrale sind konvergent für sind divergent für . Warum? Weil man das Integral ja leicht lösen kann. Am besten nicht wild mit Taschenrechner, sondern per Papier und Bleistift. |
|
|
Man sollte nicht dem Werkzeug eine Fehlerhaftigkeit , einen Bug, unterstellen, wenn der Fehler doch eigentlich darin liegt, dass man sich zu wenig mit dem Werkzeug und dessen Arbeitsweisen beschäftigt hat und/oder für eine Aufgabe schlicht das falsche Werkzeug benutzt. Du solltest dir klar darüber werden, dass für die (endliche!) Zahlenmenge der von einem Rechner darstellbaren Zahlen nicht die gleichen Gesetze wir für die Menge der reellen Zahlen gelten. So gilt zB nicht mal das Kommutativgesetz. Das klassische Beispiel dazu sind kleine Unterschiede in den Ergebnissen von und welche je nach verwendetem Programm oder Gerät mal schon für kleinere oder dann auch erst für recht große (natürliche Zahl) auftreten können. Hier der Screenshot von einem numerischen Desktopprogramm, welches intern das übliche IEEE Zahlenformat benutzt. ![]() Du kannst das Beispiel ja mit deinen Möglichkeiten durchspielen oder auch mal Excel sich daran versuchen lassen. Schuld an solchen Ungenauigkeiten sind bei rein numerischen Systemen die idR verwendeten IEEE Zahlenformate. Aber auch Systeme für symbolische Berechnungen, die ihr eigenes Zahlenformat und ihre eigene Arithmetik mitbringen haben ihre Grenzen. Selbst Systeme, welche intern ausschließlich mit (beliebig langen) ganzen Zahlen rechnen (ein früher Vertreter davon war das geniale Derive) müssen mal . geben, denn hier ist der limitierende Faktor der verwendbare Speicherplatz und die Rechenzeit. Und was die für dich offenbar irritierenden numerischen Effekte bei den integralen anlangt - sowas kannst du auch billiger haben. Bekanntlich ist Wenn man in die Funktion also immer größere Werte einsetzt, müsste das Ergebnis immer näher an die Eulersche Zahl kommen. Wenn du auf einem Billig-TR für einsetzt, erhältst du noch einen Wert, der aber bereits in der zweiten Nachkommastelle noch deutlich von abweicht. Für und größere Werte spuckt der TR dann immer nur noch 1 aus und keinesfalls etwas in der Gegend von . Liegt in dem Fall daran, dass die Rechnergenauigkeit sprengt und die letzte 1 einfach verworfen wird. Für den Rechner ist das einfach 1 und die kann man nun zur beliebigen Potenz nehmen, sie bleibt eine Eins... Bei besseren Modellen wird die Grenze, ab der das Ganze kippt, höher liegen. Hier der Screenshot eines Desktop Numbercrunchers, an dem man schön die Grenzen des IEEE Zahlenformats erkennt. ![]() Ab wird das Ergebnis sogar ungenauer und weicht stärker von ab und für stellt sich gar ein extremer Ausreißer ein. Das Programm hat auch einen Modus für symbolische Berechnungen und da liegt die Grenze deutlich höher, aber irgendwann gibts die eben auch (abgesehen von der abschreckenden langen Rechenzeit). |
|
|
Noch ein Fun Fact zur Numerik der oben schon erwähnten Harmonischen Reihe: Rechnet man nur mit 32Bit-Floatingpoint ("float" in C/C++, mit 23 Bit Mantisse), so erscheint die Reihe konvergent mit einem ungefähren Wert . Grund dafür ist, dass bei der sukzessiven Partialsummenberechnung ab wegen Auslöschung numerisch nichts mehr hinzukommt. ;-) |
|
Diese Frage wurde automatisch geschlossen, da der Fragesteller kein Interesse mehr an der Frage gezeigt hat.
|