@birkenfeld: Das Problem lag an einer falschen Formel von Agroschim. Bei ihm und bei mir klappte es zufällig weil ** (1/2) <=> ** 0 bzw. ** (3/2) <=> ** 1. Bei Dir funktionierte es aber nicht mehr, da Du korrekt r ** 3 berechnet hast, im Gravitationsgesetz muss es aber natürlich im Nenner r ** 2 sein.
Edit: Kommando zurück. In der vektoriellen Form muss natürlich doch r ** 3 im Nenner stehen. Die bisher schönen Grafiken dürften deshalb wohl einfach falsch schön sein. Man muss wohl einfach ein paar andere Planetendaten ausprobieren. Hier ein etwas besser funktionierendes Beispiel mit halbwegs attraktiven Grafiken: http://paste.pocoo.org/show/4022/. Die Skalierung der Kraftvektoren ist allerdings noch nicht ideal, so dass diese z.T. etwas wüst verlaufen.
MfG
HWK
Newtons Gravitation mit GNUPlot und Python
So, jetzt ist auch das Problem mit der Vektordarstellung gelöst. Plot stellt scheinbar Vektoren in der Form (x y dx dy) dar und nicht (x1 y1 x2 y2). Ich habe eine Variante geschrieben, wo die Skalierung statisch im Programm festgelegt wird, http://paste.pocoo.org/show/4033/ und eine Version mit dynamischer Skalierung je nach der größten Kraft http://paste.pocoo.org/show/4032/. Aber auch diese Variante scheitert bei großen Kräften zwischen Punkten am Bildschirmrand.
MfG
HWK
Edit: Ich habe noch eine Variante mit Numpy geschrieben: http://paste.pocoo.org/show/4101/. Diese ist nicht so schön wie birkenfelds Vorschlag, aber auch nicht so schlecht. Einen Geschwindigkeitsgewinn kann ich subjektiv bisher nicht erkennen. Möglicherweise ist sie aber bei deutlich mehr Planeten effektiver.
MfG
HWK
Edit: Ich habe noch eine Variante mit Numpy geschrieben: http://paste.pocoo.org/show/4101/. Diese ist nicht so schön wie birkenfelds Vorschlag, aber auch nicht so schlecht. Einen Geschwindigkeitsgewinn kann ich subjektiv bisher nicht erkennen. Möglicherweise ist sie aber bei deutlich mehr Planeten effektiver.
Ein "physikalischer Fehler" entstand dadurch, dass die Vektoren berechnet wurden, nachdem a, v und s bereits geändert wurden. Diese waren deshalb nicht mit F konsistent. Es muss somit korrekt heißen:
Nach dieser Änderung sehen die Kraftvektoren wesentlich glaubhafter aus. Am besten sieht man das bei lediglich 2 Planeten.
MfG
HWK
Code: Alles auswählen
for i, p in enumerate(planeten):
# Die nächsten 4 Zeilen müssen vor den letzten 3 stehen
plot[i].append([p.s.x, p.s.y])
if iteration % 20 == 0:
vektor[i].append(
[p.s.x, p.s.y, F[i].x / 250, F[i].y / 250])
p.a = F[i] / p.m
p.v += p.a * dt
p.s += p.v * dt
MfG
HWK
-
- User
- Beiträge: 9
- Registriert: Dienstag 19. Dezember 2006, 21:13
Am rande bemerkt...
vielleicht kann decimal die fehlende genauigkeit der floats liefern. Bei Python2.5 unter Maxosx10.4 ist decimal wesentlich schneller als Numpy.
Andreas
vielleicht kann decimal die fehlende genauigkeit der floats liefern. Bei Python2.5 unter Maxosx10.4 ist decimal wesentlich schneller als Numpy.
Andreas
Das ist ein Vergleich zwischen Äpfeln und Birnen. `numpy` ist für Matrix-Operationen und `decimal` sind einzelne Zahlen. Ich glaube kaum das entsprechende Klassen, die Matrizenoperationen mit `decimal` implementieren, schneller sind als `numpy`-Code.
Das kann ich mir auch nicht gut vorstellen. Und ob die größere Genauigkeit von 'decimal' hier wirklich einen Vorteil darstellt, wage ich auch zu bezweifeln.BlackJack hat geschrieben:Ich glaube kaum das entsprechende Klassen, die Matrizenoperationen mit `decimal` implementieren, schneller sind als `numpy`-Code.
MfG
HWK