Hallo Lothar
Die Stoßtransformationen vergleichen fand auch ich eine gute Idee, nur leider findet man deine nur auf einer einzigen Seite im Netz, nämlich bei struktron.de. Deswegen solltest du mit ja auch sagen, was da so in Schritt 7 abgeht und da hast du nicht geliefert. Deswegen solltest du halt meine in ein SMath-Arbeitsblatt bringen, weil ich das nicht hinbekomme, es bzw. länger dauert. Mit SMath und mir verhält es sich ebenso wie mit Java und dir - wir haben da anscheinend beide keine Lust, in etwas neues einzusteigen. Und ausserdem liegt erstens die Beweislast deiner These immer noch alleine bei dir und zweitens wäre deine Stoßtransformation falsch, wenn sie andere Delta_Vs als meine liefert, denn meine wurde bereits auf Herz und Nieren getestet und hat sich schon sehr oft bewährt. Die Stoßtransformatione zu vergleichen bleibt also an dir hängen. Meine Stoßtransformation findest du z.B. bei NeonHeliumProduktions in OpenGL Lesson 30.
Meinen Code zum DeVries-Algo hatte ich in meinem ersten Beitrag in diesem Faden veröffentlicht, auf Seite 83 um genau zu sein, du bist auch schon drauf eingegangen. Die sukzessive Approximation ist bei Kettenbruchentwicklungen jedenfalls 100%ig genau, dauert nur halt manchmal ewig - für 1000 Nachkommastellen FSK z.B. 2h13min auf meinem Rechner bzw. in der vorliegenden Anwendung (Code ist deswegen auskommentiert). Eine Kettenbruchentwicklung mit festen Intervallen, erst recht eine geschachtelte wie bei DeVries, kann nur dann genau sein, wenn die Intervallobergrenze hoch genug geschätzt wurde. Bei höherer Anzahl an Nachkommastellen macht es nicht den geringsten Sinn, Konstanten zu verwenden, die nur 16 Signifikante Stellen haben (z.B. Pi und Euler in double-precision bei dir und Leighton) - Gottfried Helms hat dies auch gewusst, deswegen stimmt seine Zahl mit 64(?) Nachkommastellen auch mit meiner überein. Der Grund dafür ist: Hier werden Daten ausgelöscht, weil Eingangswerte (signifikante Nachkommastellen in Konstanten) fehlen - sowas muss man wissen, erst recht wenn man irgendwann mal Informatik studiert hat. In Schulbüchern wirst du btw. nirgendwo einen FSK-Wert finden, der nicht dem von CODATA entspricht, das bedeutet, selbst wenn Gottfried Helms's und mein Wert, warum auch immer, nicht stimmen sollten, müssen die berechnenden Algorithmen überprüft werden und meistens (um nicht zu sagen immer) kommt dabei heraus, dass unsere Algos (also Gottfried Helms's und meiner) die genauesten sind.
Die Werte in meiner Simulation bedeuten folgendes:
1. setSpeed: Hat für einzelne Betriebsarten verschiedene Bedeutungen.
THERMALISING: Alle Kugeln werden mit dieser Geschwindigkeit initialisiert.
DISTRIBUTED: Hier wird setSpeed zur Ermittlung der Schrittweite der einzelnen Geschwindigkeitsintervalle verwendet. Die Geschwindigkeiten der einzelnen Kugeln werden anschliessend gemäß vorrausberechneter MB-Verteilung vorverteilt.
RANDOM: Hier werden die Kugeln mit zufälligen Geschwindigkeiten zwischen 0 und setSpeed initialisiert. Die Vorschau zur MB-Verteilung wird mit "setSpeed / wurzel(PI)" erstellt und die ermittelten Geschwindigkeitswerte stellen sich während der Laufzeit auch stets ein, der Grund dafür ist mir allerdings ein Rätsel.
BOILER: Hier wird genau eine Kugel mit setSpeed initialisiert, der Rest mit 0. setSpeed ist hier auch gleichzeitig die Maximalgeschwindigkeit (ungeachtet der Fehler durch den Datentyp double). Für die Vorschau der MB-Verteilung verwende ich "setSpeed / (wurzel(numSpheres) + PI)". Auch hier ist es mir ein Rätsel, warum sich genau bei diesem Wert die Geschwindigkeiten annähernd gemäß Vorschau verteilen.
Die Bewegungsrichtungen der Kugeln werden in jeder Betriebsart zufällig initialisiert.
2. avSpeed: (AverageSpeed) Ist die mittlere Geschwindigkeit gemäß Wikipedia-Artikel. Dieser Wert ist leider nicht sehr genau, weil er einer gewissen Auslöschung unterliegt.
3. maxSpeed: Ist der Wert der höchsten aufgetretenen Geschwindigkeit, die durch die Stöße zustande kam. Logisch, dass es in der Betriebsart "BOILER" stets der Wert von "setSpeed" sein muss, weil sich "setSpeed" nach und nach auf all die anderen Kugeln verteilt.
4. avDelta: Ist die Änderung der mittleren Geschwindigkeit nach einem Stoß. Auch dieser Wert ist nicht sehr genau, weil er von avSpeed abhängt.
5. Delta_V: Diesen Wert kann man auf zwei Arten berechnen lassen.
DELTA_VALUE: Hier wird Delta_V gemäß Lothars FSK-Arbeitsblättern errechnet: "abs((speed1_alt + speed2_alt) - (speed1_neu + speed2_neu)). "speed1_x" und "speed2_x" sind dabei die Geschwindigkeiten der Stoßpartner vor und nach einem Stoß.
DELTA_VECTOR: Hier wird Delta_V per Vektoraddition ermittelt. Vor und nach einem Stoß werden die Relativgeschwindigkeiten der Stoßpartner ermittelt und voneinander abgezogen.
Gemäß Lothars FSK-Arbeitsblättern werden die ermittelten Delta_Vs in beiden Fällen aufsummiert und durch die Anzahl der Stöße geteilt.
6. markedSpeed: ist der untere Grenzwert des grün markierten Intervalls in der MB-Grafik (Haeufigkeit).
7. Stoesse: Ist die Anzahl der stattgefundenenStöße.
8. colums: (oh... da hat wohl ein "n" geklemmt.
) Ist die Anzahl der Intervalle in der MB-Verteilung.
9. Spheres: Ist die Anzahl der simulierten Kugeln.
btw.: Ich habe keine Fragen zur Zeitdilatation, sondern Antworten! Zeit dilatiert nicht! Aufgrund von Trägheit ändern sich nur Lebensdauern zusammenhängender Materie und das ist der Invarianz der LG geschuldet, da einzelne Teilchen aufgrund dieses Tempolimits langsamer auseinanderdriften. Genau deswegen passt da ja auch die Lorentztransformation oder der Lorentzfaktor, wie sooft bestätigt wurde. Meine Interpretation diesbezüglicher Experimente bedeutet nicht, dass ich von Physik keinen Plan hätte. Eine Theorie kleinster diskreter Teilchen ohne Potential lehne ich deswegen ab, weil man diesen "Wahnsinn" schon im Keim ersticken kann, indem man solche "Teilchen" als Knoten (ähnlich einer Wollbommel) el. mag. Wellen betrachtet, Materie demnach aus "Nichts" besteht. Alternativ müsste man nämlich endlos nachfragen, aus welchem Material wohl Materie bestünde.