|
|
|
|
Die Gaußsche Fehlerfortpflanzung von SilentAssasin gilt übrigens für das Fortpflanzen des statistischen Fehlers; wenn man Messwerte mit gleichem statistischem Fehler hat, kommt man auch schnell drauf, dass der Fehler des arithmetischen Mittels mit geht, somit wie man es erwartet kleiner wird, wenn man viele Werte mittelt.
Für systematische Fehler nimmt man die Größtfehlerfortpflanzung wie hier als Fehlergrenzen angegeben. Ein systematischer Fehler wäre z. B., dass dein Messgerät im Messen des Bereichs der Größe, die du dir anschaust, immer 5% zu viel angibt (immer in die selbe Richtung). Dann ist es auch evident, dass dieser Fehler beim Bilden des arithmetischen Mittels gleich bleibt, er betrifft schließlich jeden Messwert gleich, ist nicht statistisch.
Dann hätte man bei Aufnahme mehrer Werte zwar immer den selben systematischen Fehler, aber z. B. ein statistischer Fehler, den man in so einem Fall durch die Standartabweichung bestimmen würde, würde mit vielen Messwerten kleiner werden, wenn sie nicht zu grob streuen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Robotronic am 23.01.2013 21:24]
|
|
|
|
|
|
Uh, das hab ich sogar verstanden, danke!
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von RichterSkala am 23.01.2013 21:27]
|
|
|
|
|
|
Da ich deinen anderen Post noch gesehen hab:
Wenn du die gleiche Messung wiederholst, heißt das noch nicht, dass die Messgrößen wirklich statistisch korreliert sind, das hängt vom Messaufbau ab; meist tritt sowas glaube ich auf, wenn man schnell misst, und dem System keine Zeit für eventuelle Relaxation gibt. Das ist aber ziemliches Halbwissen, da ich (bisher zumindest) starker Theoretiker und kein Experimentalo bin. Wo es noch passieren kann ist, dass man in einem System zwei unterschiedliche Größen misst, und die Messung der einen das Ergebnis der anderen beeinflusst (was jetzt nicht unbedingt so extrem wie in der Quantenmechanik zu verstehen ist). Wenn du daraus eine dritte Größe berechnest, musst du dich unter Umständen auch mit Korrelation rumschlagen.
Für den Fall, dass deine Werte wirklich korreliert sind, müsste man halt hier ganz unten schauen, da steht es nochmal allgemein unter Einbeziehung der Korrelation.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Robotronic am 23.01.2013 21:38]
|
|
|
|
|
|
| Zitat von SilentAssassin
| Zitat von RichterSkala
Oh Gott, Fehlerrechnung ist viel zu lange her
Ich hab hier zwei Messwerte mit Unsicherheit . Jetzt mach ich die Summe aus denen und teile durch Zwei. Was mach ich denn dann mit der Unsicherheit?
| |
Dann ist
| |
Ou shit, du hast ja recht.
|
|
|
|
|
|
|
| Zitat von Robotronic
Wenn du die gleiche Messung wiederholst, heißt das noch nicht, dass die Messgrößen wirklich statistisch korreliert sind
| |
Aaaachso! Das wusste ich nicht. Je länger ich drüber nachdenke, desto mehr Sinn macht es aber.
|
das hängt vom Messaufbau ab; meist tritt sowas glaube ich auf, wenn man schnell misst, und dem System keine Zeit für eventuelle Relaxation gibt. | |
Interessant. Mal schauen ob ich da morgen was gescheites zum lesen zu finde.
|
|
|
|
|
|
|
| Zitat von Achsel-des-Bösen
Nehmen wir an ich habe einen Sensor, den ich X mal pro Sekunde abtasten kann und bei dem ich live rhythmische Peaks erkennen möchte und dann reagieren wenn sie fehlen.
Wertebereich des Sensors ist mir bekannt auch die ungefähre Frequenz der Peaks. Außerdem ist der Sensor noch ein wenig verrauscht.
Vorschläge und Methoden die ich verwenden könnte?
| |
Ich würde jetzt eine Periode des Signals in ein Array schreiben und dann für die nächsten Werte immer bei einem Intervall den Fehler mit den ersten "erwarteten" Werten berechnen. Dann kannst Du mit einem Schwellwert abschätzen, ob du reagieren musst.
¤: Zweite Möglichkeit wäre eine FFT und dann Koeffizienten vergleichen.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von klmann am 23.01.2013 22:56]
|
|
|
|
|
|
Gott was ist meine Motivation nahe bei 0 morgen ein paar Vollhorsten näherzubringen, was spezifische Wärmekapazität ist und dass sie das nicht essen können. Außerdem müssen die selbst löten, mit jetzt noch sichererem Lötzinn, ganz ohne Blei, dessen Schmelztemperatur noch ein wenig näher an der Lötkolbentemperatur liegt, als das schon vorher der Fall war.
Hell yeah!
|
|
|
|
|
|
|
Warum musst du Leuten Löten beibringen?
|
|
|
|
|
|
|
Ich hasse bleifreies Lot
|
|
|
|
|
|
|
| Zitat von nobody
Warum musst du Leuten Löten beibringen?
| |
Weil ... es im Versuch steht ... das ist einer der wenigen sinnvollen Sachen die sie da lernen, wenn sie es nicht eh schon können, was ich von einem guten Nerd eigentlich erwarte.
|
|
|
|
|
|
|
Reicht es, zu wissen, wie das prinzipiell geht und es vor ~15 Jahren mal gemacht zu haben?
Live long and prosper.
|
|
|
|
|
|
|
Blöde Frage, aber ihr kennt mich ja.
Ich übergebe einer Funktion einen Pointer auf ein Array. Das will ich in der Funktion vergrößern:
|
Code: |
event *
add_event(event ** events, ...)
{
runprms.num_events_alloced += EVENT_CHUNK_SIZE;
*events = realloc(*events,
runprms.num_events_alloced * sizeof(event));
...
} |
|
a) Kann ich davon ausgehen, dass außerhalb des Funktionsaufrufes, also davor und danach, der Zeiger auf das Array unverändert ist, das Array lediglich größer ist?
b) Kann ich davon ausgehen, dass die vorherigen Elemente des Arrays die gleichen Speicheradressen haben wie vorher? Oder bewegt realloc das irgendwie rum?
Das scheint bei mir nämlich nen Fehler zu verursachen, irgendwo.
/e: meh. The function may move the memory block to a new location (whose address is returned by the function).
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 24.01.2013 10:55]
|
|
|
|
|
|
Ich versuche die Frage meines Vorredners zu übertreffen.
Wie integriere ich diese Funktion?
Mittels partieller Integration komme ich da nicht weiter.
Auch geschickte Substitution bringt mich nicht weiter, oder übersehe ich was? Durch Substitution bin ich schon auf oben genannte Form gekommen, evtl kann man da schon noch was machen.
Bin für jede Hilfe dankbar!
|
|
|
|
|
|
|
Partialbruchzerlegung...?
I'm a performance artist, and my medium is irate ladies.
|
|
|
|
|
|
|
| Zitat von Oli
Blöde Frage, aber ihr kennt mich ja.
Ich übergebe einer Funktion einen Pointer auf ein Array. Das will ich in der Funktion vergrößern:
|
Code: |
event *
add_event(event ** events, ...)
{
runprms.num_events_alloced += EVENT_CHUNK_SIZE;
*events = realloc(*events,
runprms.num_events_alloced * sizeof(event));
...
} |
|
a) Kann ich davon ausgehen, dass außerhalb des Funktionsaufrufes, also davor und danach, der Zeiger auf das Array unverändert ist, das Array lediglich größer ist?
b) Kann ich davon ausgehen, dass die vorherigen Elemente des Arrays die gleichen Speicheradressen haben wie vorher? Oder bewegt realloc das irgendwie rum?
Das scheint bei mir nämlich nen Fehler zu verursachen, irgendwo.
/e: meh. The function may move the memory block to a new location (whose address is returned by the function).
| |
Genau. Problem ist halt, wenn z.B. schon etwas hinter dem bestehenden Speicherblock allokiert wurde. Dann muss der Bereich ja woanders neu angelegt werden, weil sonst kein zusammenhängender Speicherbereich erzeugt werden kann.
|
|
|
|
|
|
|
Wäre auch ne Idee.
Aber ich glaub ich habs!
Partielle Integration, wähle (gemäß folgender Notation) den Zähler als g(x), und den restlichen Bruch als f'(x). Dann muss ich zwar den ekligen Bruch integrieren, doch das stand (wie gerade bemerkt) auf der Rückseite der Angabe unter "Diese Integrale könnten von Nutzen sein...".
|
|
|
|
|
|
|
Bazooker: Uff, ich komm auf die Schnelle nicht drauf.
Aber das steht auf jeden Fall im Bronstein.
|
|
|
|
|
|
|
Scheisse, ich komm auch mit meiner Tollen Substitution nicht drauf. Ja steht in ner Integraltabelle. Aber das muss doch auch so gehen. Crap.
\Edith: Danke Oli und WoS. Vielleicht hat ja der eine oder andere ncoh einen Gedankenblitz.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Bazooker am 24.01.2013 11:35]
|
|
|
|
|
|
Hmmm... Du kannst ein x ausklammern und dann die Geometrische Reihe anwenden. Summe und Integral vertauschen* und dann kannst du die Integration ausführen. Nur beim Vereinfachen des Ergebnisses hab ich aufgehört.
Aber es gibt sicherlich einfachere Wege.
* An die Mathematiker: Das ist völlig legitim und geht IMMER!!!!
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 24.01.2013 11:42]
|
|
|
|
|
|
|
|
|
|
*
|
|
|
|
|
|
|
| Zitat von klmann
Genau. Problem ist halt, wenn z.B. schon etwas hinter dem bestehenden Speicherblock allokiert wurde. Dann muss der Bereich ja woanders neu angelegt werden, weil sonst kein zusammenhängender Speicherbereich erzeugt werden kann.
| |
Fuck this, Linked List to the rescue.
|
|
|
|
|
|
|
Hm. Ich hab das Gefühl ich musste das schon mal Lösen. So in Ana2 oder so.
|
|
|
|
|
|
|
Ich kann mit Gewissheit sagen, dass ich das nicht musste und auch nie drauf kommen würde. Aber für mich stumpfen Anwender gibt's ja zum Glück o.g. Alternativen.
Ana 2 wurde aber auch als ich angefangen habe aus dem Lehrplan geworfen, falls das als Entschuldigung zählt. (Auch wenn ich es später im Studium hätte gebrauchen können )
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von nobody am 24.01.2013 12:44]
|
|
|
|
|
|
Danke dir.
Naja, kann man schonmal lässig in ner Physik Klausur raushauen, das Integral
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Bazooker am 24.01.2013 12:44]
|
|
|
|
|
|
| Zitat von Bazooker
Naja, kann man schonmal lässig in ner Physik Klausur raushauen, das Integral
| |
Sieht halt auf den ersten Blick (zumindest für mich) nicht so widerlich aus, wie es dann letztenendes ist. :P
|
|
|
|
|
|
|
Man muss halt die Substitution mit tan kennen und erkennen, ab da ist es ja nur noch Handwerk.
|
|
|
|
|
|
|
Gott, liebe ich Binärbäume. Damit kann man so viel optimieren.
|
|
|
|
|
|
|
| Zitat von Oli
| Zitat von klmann
Genau. Problem ist halt, wenn z.B. schon etwas hinter dem bestehenden Speicherblock allokiert wurde. Dann muss der Bereich ja woanders neu angelegt werden, weil sonst kein zusammenhängender Speicherbereich erzeugt werden kann.
| |
Fuck this, Linked List to the rescue.
| |
Warum nicht einen std::vector als Referenz übergeben?
|
|
|
|
|
|
Digits - Messgenauigkeit
|
Versteh noch nich ganz wie ich 1 Digit von einem digitalen Messgerät berechne. Was mir noch nicht ganz klar ist: wodran macht es das aus? Ist es ein Unterschied, ob ich 20V eingestellt habe oder 2V ? Bei 200mV zu 20V würde ich sagen ja, aber bei 2V und 20V? Ich habe ja auf der Anzeige 00,000V stehen sowohl bei 2V als auch bei 20V. Demnach wäre 1 Digit bei beiden ja gleich, oder?
Ist es des weiteren vom Messgerät abhängig? Angenommen ich hätte ein Messgerät, welches 00,000000 Stellen anzeigt. Wäre es ja bie 20V anders. Oder geht man generell von 5 Stellen aus?
Danke im Voraus.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Gepan.3dsvs.com am 24.01.2013 15:47]
|
|
|
|
|
Thema: pOT-lnformatiker, Mathematiker, Physiker XII ( Jetzt mit Primzahlen > 1024 ) |