| Autor |
Beitrag |
Matty92
      
Beiträge: 34
|
Verfasst: Sa 24.04.10 23:02
Hi,
ich habe an der Facharbeit weitergearbeitet und auch schone einige Lehrergespräche.
Mit dem schreiben der Facharbeit hab ich auch schon angefangen.
Nur das Programm bereitet mir Probleme, und zwar stürzt es zu schnell ab, als dass ich die Fehlermeldung lesen kann (im Moment noch Konsolenanwendung).
Ich habe das ganze in drei Units aufgeteilt, eine für die Vektoren, eine für Planeten und eine für das Berechnen:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39:
| unit umehrkoerper;
interface uses SysUtils, math, Uplanet, UVektor;
type Tmehrkoerper=class(TPlanet) protected Planet: array of TPlanet; maxV, minV, maxOrt, minOrt:TVektor; anzahl:longint; G:extended; zeitschritt,zeit:extended; public [...] procedure berechnen;
end; implementation
[...]
procedure tmehrkoerper.berechnen; var i,j:integer; betrag,ax,ay,vxneu,vyneu,xneu,yneu:extended; abstand:TVektor; begin for i:=0 to high(planet) do for j:=0 to high(planet) do if i<>j then begin abstand:=planet[i].ortalt.vektordifferenz(planet[j].Ortalt); betrag:=power(abstand.Betrag,3); ax:=(g*planet[j].getmasse*abstand.getx) / betrag; ay:=(g*planet[j].getmasse*abstand.gety) / betrag; vxneu:=planet[i].valt.getx + (ax*zeitschritt); vyneu:=planet[i].valt.gety + (ay*zeitschritt); xneu:=planet[i].ortalt.getx + (vxneu*zeitschritt); yneu:=planet[i].ortalt.gety + (vyneu*zeitschritt); planet[i].neuevektoren(vxneu,vyneu,xneu,yneu); end;
end; |
Die Zeile ruft folgende auf (Die Vektoren ortneu,ortalt, vneu, valt sind die einzigsten Attribute der Units des Programmes die Public sind):
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31:
| unit UPlanet;
interface uses SysUtils, math, UVektor;
type TPlanet=class(TVektor) protected Vstart:TVektor; Ortstart:TVektor; Masse:extended; public Ortalt,ortneu:TVektor; Valt,vneu:TVektor; [...] procedure neuevektoren(vx,vy,x,y:extended);
end;
implementation
[...] procedure TPlanet.neuevektoren(vx,vy,x,y:extended); begin self.Valt:=vstart.kopierevektor; self.Ortalt:=ortstart.kopierevektor; self.vneu.setzex(vx); self.vneu.setzey(vy); self.ortneu.setzex(x); self.ortneu.setzey(y); end; |
Und diese Zeile führt dann zu der Methode, die das Programm abstürzen lässt:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24:
| unit UVektor;
interface uses SysUtils, math;
type TVektor=class protected x,y:extended;
public [...] procedure setzex(x:extended); procedure setzey(y:extended); [...]
end;
implementation [...] procedure TVektor.setzex(x:extended); begin self.x:=x; end; [...] |
Und bei dieser Anweisung ist Schluss, und ich habe keine Ahnung wieso das passiert. Habt ihr eine Idee?
Delphi 2005 läuft bei mir btw. in einer Virtual Machine, da mein Windows 7 64bit nicht mit dieser Delphiversion klar kommt.
Viele Grüße,
Matty
|
|
SvenAbeln
      
Beiträge: 334
Erhaltene Danke: 3
|
Verfasst: So 25.04.10 01:27
Wird dein vneu auch wirklich irgendwo erzeugt? Das ist in deinen Code Teilen leider nicht zu sehen.
Sprich, hast du irgendwo
Delphi-Quelltext 1:
| vneu:= TVector.Create; |
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: So 25.04.10 01:40
SvenAbeln hat folgendes geschrieben : | Wird dein vneu auch wirklich irgendwo erzeugt? Das ist in deinen Code Teilen leider nicht zu sehen.
Sprich, hast du irgendwo
Delphi-Quelltext 1:
| vneu:= TVector.Create; | |
Hi Sven,
nein, danke.
Ich sehe gerade, dass dieses Attribut niemals geschaffen wird.
Aber auch wenn ich es im Konstrukter erzeuge stürzt es an der gleichen Stelle ab.
Gibt es eine Möglichkeit, die Fehlermeldung aus dem Konsolenfenster irgendwie auszugeben?
Das Programm endet zu schnell.
Ich sehe gerade auch, dass ich, nachdem ich den vektorkopierer geändert habe, dieser auch nicht klappt, und zwar bei folgender Anweisung abstürzt:
Delphi-Quelltext
So eine ähnliche Anweisung führt auch weiter oben zum Absturz:
Delphi-Quelltext
Liegt es vielleicht an der VM? Ich werde das morgen mal auf meinem Tablet probieren, der hat WinXP  .
Viele Grüße,
Matze
|
|
Xion
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: So 25.04.10 09:27
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: So 25.04.10 14:29
Moderiert von Narses: Komplett-Zitat des letzten Beitrags entfernt.
Hi,
so, hab mal geguckt, der Fehler tritt auch auf dem anderen Rechner auf, da läuft zwar Delphi 7, aber wenigstens wird die Fehlermeldung nicht im Konsolenfenster, sondern extra ausgegeben:
| Zitat: | Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt Project1.exe ist eine Exception der Klasse EAccessViolation aufgetreten. Meldung: 'Zugriffsverletzung bei Adresse 00408A07 in Modul 'Project1.exe'. Schreiben von Adresse 00000008'. Prozess wurde angehalten. Mit Einzelne Anweisung oder Start fortsetzen. |
TPlanet its von TVektor abgeleitet, weil der Planet durch Vektoren beschrieben wird, so hab ich mir das gedacht.
Hier ist nochmal der Konstruktor von TPlanet:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| constructor TPlanet.create(Vstart,Ortstart:TVektor;masse:extended); begin self.vstart:=TVektor.create(Vstart); self.Ortstart:=TVektor.create(Ortstart); self.vneu:=TVektor.create(0,0); self.ortneu:=TVektor.create(0,0); self.valt:=TVektor.create(vstart); self.ortalt:=TVektor.create(ortstart); self.masse:=masse; end; |
|
|
Xion
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: So 25.04.10 18:05
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| constructor TPlanet.create(Vstart,Ortstart:TVektor;masse:extended); begin self.vstart:=TVektor.create(Vstart); self.Ortstart:=TVektor.create(Ortstart); self.vneu:=TVektor.create(0,0); self.ortneu:=TVektor.create(0,0); self.valt:=TVektor.create(vstart); self.ortalt:=TVektor.create(ortstart); self.masse:=masse;
inherited Create; end; |
Probiers mal so. Damit auch die Klasse, von der TPlanet geerbet wird, erstellt wird. Auch wenn du sie nie verwendest, der Witz an der Vererbung wäre ja, dass du Planet.X und Planet.y ansprechen kannst.
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: So 25.04.10 18:14
Moderiert von Narses: Komplett-Zitat des letzten Beitrags entfernt.
Hi Xion,
sorry, das bringt auch keine Änderung  . Wie gesagt, das Programm stürzt bei der Anweisung ab, bei der die Vektoren neue Werte bekommen.
Viele Grüße,
Matty
Zuletzt bearbeitet von Matty92 am So 25.04.10 18:23, insgesamt 1-mal bearbeitet
|
|
SvenAbeln
      
Beiträge: 334
Erhaltene Danke: 3
|
Verfasst: So 25.04.10 18:23
Das inherited Create; gehört eigentlich an den Anfang des Konstruktor, ob dies aber hier was ausmacht kann man in diesen Code Bruchstücken nicht erkennen.
Du rufst ansonsten immer einen überladenen Konstruktor von TVektor auf, ist der Default Konstruktor überhaupt richtig implementiert?
Kannst du vielleicht mal die kompletten Klassen Posten, damit man mal sehen kann was da sonst noch passiert? Im Moment sieht man nur sehr kleine Bruchstücke. (Falls die Klassen zu groß sind vielleicht als ZIP)
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: So 25.04.10 18:27
Moderiert von Narses: Komplett-Zitat des letzten Beitrags entfernt.
Hi Sven
ich hab es hier im Anhang gepackt.
Einloggen, um Attachments anzusehen!
|
|
SvenAbeln
      
Beiträge: 334
Erhaltene Danke: 3
|
Verfasst: So 25.04.10 19:47
Es stürzt in tmehrkoerper.berechnen; ab, weil du dort eine Division durch 0 hast. Wenn du diesen Fall abfängst läuft das Programm durch.
Delphi-Quelltext 1: 2: 3: 4: 5:
| [...] abstand:=planet[i].ortalt.vektordifferenz(planet[j].Ortalt); betrag:=power(abstand.Betrag,3); ax:=(g*planet[j].getmasse*abstand.getx) / betrag; [...] |
Noch ein paar andere Tipps, die mir so aufgefallen sind:
- Tmehrkoerper braucht nicht von TPlanet abgeleitet werden, die Eigenschaften benutzt du sowieso nirgends
- Tmehrkoerper braucht einen destructor, wo du alle erzeugten Objekte wieder frei gibst.
- Tmehrkoerper.berechnen hat ein MemoryLeak.
Delphi-Quelltext 1:
| abstand := Planet[i].ortalt.vektordifferenz(Planet[j].ortalt); |
hier wird für abstand immer ein neues Objekt von TVektor erzeugt, aber nie wieder frei gegeben.
- randomize sollte nur einmal aufgerufen werden, deswegen am besten im Hauptprogramm
- im Hauptprogramm erzeugst du ein Tmehrkoerper, das wird aber nie wieder frei gegeben.
- TPlanet braucht einen destructor
- TVektor hat einen destructor, braucht aber keinen
- der destructor heißt destroy und nicht free.
Delphi-Quelltext 1: 2:
| destructor destroy; override; |
- schau dir vielleicht auch mal Properties an, denn deine getX und setzeX sind nicht gerade intuitive, vor allem da deutsch und englisch.
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: So 25.04.10 20:48
SvenAbeln hat folgendes geschrieben : | Es stürzt in tmehrkoerper.berechnen; ab, weil du dort eine Division durch 0 hast. Wenn du diesen Fall abfängst läuft das Programm durch.
Delphi-Quelltext 1: 2: 3: 4: 5:
| [...] abstand:=planet[i].ortalt.vektordifferenz(planet[j].Ortalt); betrag:=power(abstand.Betrag,3); ax:=(g*planet[j].getmasse*abstand.getx) / betrag; [...] |
|
Hi Sven,
danke für das ansehen  . Ich dachte, ich hätte die Division durch 0 ausgeschlossen, da vorher "if i<>j then" steht, also planet[i]=planet[j] nicht ist. Hm, seltsam.
SvenAbeln hat folgendes geschrieben : |
Noch ein paar andere Tipps, die mir so aufgefallen sind:
- Tmehrkoerper braucht nicht von TPlanet abgeleitet werden, die Eigenschaften benutzt du sowieso nirgends
- Tmehrkoerper braucht einen destructor, wo du alle erzeugten Objekte wieder frei gibst.
- Tmehrkoerper.berechnen hat ein MemoryLeak.
Delphi-Quelltext 1:
| abstand := Planet[i].ortalt.vektordifferenz(Planet[j].ortalt); |
hier wird für abstand immer ein neues Objekt von TVektor erzeugt, aber nie wieder frei gegeben.
- randomize sollte nur einmal aufgerufen werden, deswegen am besten im Hauptprogramm
- im Hauptprogramm erzeugst du ein Tmehrkoerper, das wird aber nie wieder frei gegeben.
- TPlanet braucht einen destructor
- TVektor hat einen destructor, braucht aber keinen
- der destructor heißt destroy und nicht free.
Delphi-Quelltext 1: 2:
| destructor destroy; override; |
- schau dir vielleicht auch mal Properties an, denn deine getX und setzeX sind nicht gerade intuitive, vor allem da deutsch und englisch.
|
Ok, nochmal danke hierfür, hab ich geändert.
Den destruktor für abstand hatte ich in der ersten Version drinnengehabt, keine Ahnung wieso ich den jetzt vergessen habe  . Das randomize wird nur einmal aufgerufen, und zwar im Konstruktor für TMehrkoerper.
Properties sieht auch interessant aus, aber jetzt funktioniert der Algorithmus endlich, da will ich jetzt nicht noch etwas abändern.
Viele Grüße und nochmal danke  ,
Matty
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: Di 04.05.10 16:37
Hi,
so, hab es nochmal anders gelöst, darauf hätte ich auch direkt kommen sollen,
ich hab einfach das i<>j durch planet[i]<>planet[j] ersetzt, und voilà, schon klappt es ohne Probleme  .
Viele Grüße,
Matty
|
|
Xion
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Di 04.05.10 18:04
Matty92 hat folgendes geschrieben : | ich hab einfach das i<>j durch planet[i]<>planet[j] ersetzt, und voilà, schon klappt es ohne Probleme . |
Das ist unlogisch (zumindest für mich). Pass auf, dass es nicht nur durch Zufall hilft...das gibts durchaus, und in 1 Woche hast du das selbe Problem wie oben. Und dann womöglich sonst wo (das sind meistens Speicher-Probleme des Programms und die fallen dann zufällig irgendwo auf, je nach dem wo das Programm den Speicher überschrieben hat). Ich hatte es schon, dass ich array Elemente ohne Fehler ausgelesen hab, die es garnicht mehr gab. Erst später (2 Tage) gab es dann Fehler, an einer andren Stelle.
Jetzt hatte ich noch nen ewig langen Absatz über die Physik in deinem Programm aber ich hab nach ca. 30 Zeilen gemerkt, dass es doch richtig ist was du da stehen hast...irgendwie hab ich das damals "schöner" aufgeschrieben ^^ nicht so kompakt.
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: Do 06.05.10 16:01
Xion hat folgendes geschrieben : | Matty92 hat folgendes geschrieben : | ich hab einfach das i<>j durch planet[i]<>planet[j] ersetzt, und voilà, schon klappt es ohne Probleme . |
Das ist unlogisch (zumindest für mich). Pass auf, dass es nicht nur durch Zufall hilft...das gibts durchaus, und in 1 Woche hast du das selbe Problem wie oben. Und dann womöglich sonst wo (das sind meistens Speicher-Probleme des Programms und die fallen dann zufällig irgendwo auf, je nach dem wo das Programm den Speicher überschrieben hat). Ich hatte es schon, dass ich array Elemente ohne Fehler ausgelesen hab, die es garnicht mehr gab. Erst später (2 Tage) gab es dann Fehler, an einer andren Stelle.
|
Hi,
hm, falls es doch irgendwann zu einem Fehler kommen sollte, kann ich ja als Bedingung not(planet[i]=planet[j]) setzen, das wird ja true, wenn die beiden Objekte, genauer gesagt die Adressen gleich sind oder?
Xion hat folgendes geschrieben : |
Jetzt hatte ich noch nen ewig langen Absatz über die Physik in deinem Programm aber ich hab nach ca. 30 Zeilen gemerkt, dass es doch richtig ist was du da stehen hast...irgendwie hab ich das damals "schöner" aufgeschrieben ^^ nicht so kompakt. |
Nur so aus Neugierde, wo wäre denn der Fehler gewesen (oder die Fehler, bei so einer Menge Text  )?
Was meinst du mit schöner? Leichter verständlich? Schöner vom Aussehen  ? Ich hab die Berechnungsprozedur nochmal verändert und zusammengestampft:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18:
| procedure tmehrkoerper.berechnen2(planetenfeld:Planet); var i,j:integer; betrag,ax,ay,vxneu,vyneu,xneu,yneu:extended; abstand:TVektor; begin for i:=0 to high(planetenfeld) do for j:=0 to high(planetenfeld) do if planetenfeld[i]<>planetenfeld[j] then begin abstand:=planetenfeld[i].ortalt.vektordifferenz(planetenfeld[j].Ortalt); betrag:=power((sqr(abstand.Betrag)+sqr(e)),1.5); ax:=(g*planetenfeld[j].getmasse*abstand.getx) / betrag; ay:=(g*planetenfeld[j].getmasse*abstand.gety) / betrag; vxneu:=planetenfeld[i].valt.getx + (ax*zeitschritt); vyneu:=planetenfeld[i].valt.gety + (ay*zeitschritt); xneu:=planetenfeld[i].ortalt.getx + (vxneu*zeitschritt); yneu:=planetenfeld[i].ortalt.gety + (vyneu*zeitschritt); planetenfeld[i].neuevektoren(vxneu,vyneu,xneu,yneu); abstand.Destroy; end; end; |
e sorgt jetzt dafür, dass es niemals zu einer Kollision kommen kann, d.h. keine Division durch 0.
Im Anhang hab ich nochmal die Formel die dem ganzen zugrunde liegt  .
Einloggen, um Attachments anzusehen!
Zuletzt bearbeitet von Matty92 am Do 06.05.10 17:23, insgesamt 2-mal bearbeitet
|
|
Xion
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Do 06.05.10 16:36
Matty92 hat folgendes geschrieben : |
hm, falls es doch irgendwann zu einem Fehler kommen sollte, kann ich ja als Bedingung not(planet[i]=planet[j]) setzen, das wird ja true, wenn die beiden Objekte, genauer gesagt die Adressen gleich sind oder?
|
Ne, das Problem ist dass der Fehler irgendwo im Speicher ist. Bsp man schreibt in ein Array-Feld rein dass es nicht gibt. Normal gibts dann eine Fehlermeldung. manchmal aber nicht, und dann fällt der Fehler erst Delphi auf, wenn er irgendwo was auslesen will und da wurde drin rumgeschrieben ^^ Dann gibts die Fehlermeldung, aber ganz wo anders. Wenn es bei dir jetzt einen Unterschied macht, ob du i<>j und Planet[i]<>Planet[j] schreibst, dann vermute ich mal, dass du durch den Vergleich der Adressen irgendwas anders im Prozessor machst und in den tiefen des Systems trifft er dann nicht auf den Fehler. Aber der Fehler ist ja trotzdem da. Weil wenn i=j, dann ist auch Planet[i]=Planet[j], da gibts ja keinen Unterschied. Wo der Fehler dann ist...tja, gute Frage. Nicht da wo der Fehler angezeigt wird
Matty92 hat folgendes geschrieben : | Xion hat folgendes geschrieben : |
Jetzt hatte ich noch nen ewig langen Absatz über die Physik in deinem Programm aber ich hab nach ca. 30 Zeilen gemerkt, dass es doch richtig ist was du da stehen hast...irgendwie hab ich das damals "schöner" aufgeschrieben ^^ nicht so kompakt. |
Nur so aus Neugierde, wo wäre denn der Fehler gewesen (oder die Fehler, bei so einer Menge Text )?
Was meinst du mit schöner? Leichter verständlich? Schöner vom Aussehen ? Ich hab die Berechnungsprozedur nochmal verändert und zusammengestampft:
|
Ich hatte mich etwas gewundert, dass du Betrag^3 nimmst. Ich hatte das damals anders, bei mir stand im Code die Formel a=G*m1/r² direkt im Code, wobei die Formel ja eigentlich F=G*m1*m2/r² und F=m1*a (das m1 mit einrechnen und dann wieder teilen hab ich mir auch gespart). Und dann hab ich erst die Beschleunigung aufgeteilt. Am Ende kamen dann auch die Formeln raus, aber man hat im Code besser gesehen was passiert. Übrigens ist G <> g in Physik ^^
Matty92 hat folgendes geschrieben : |
e sorgt jetzt dafür, dass es niemals zu einer Kollision kommen kann, d.h. keine Division durch 0. |
e? Du musst ja nur gucken, ob Betrag=0, dann krachts ^^ Oder noch besser, wenn Betrag<=Radius vom Planet, dann krachts ^^
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: Do 06.05.10 17:45
Xion hat folgendes geschrieben : | Matty92 hat folgendes geschrieben : |
hm, falls es doch irgendwann zu einem Fehler kommen sollte, kann ich ja als Bedingung not(planet[i]=planet[j]) setzen, das wird ja true, wenn die beiden Objekte, genauer gesagt die Adressen gleich sind oder?
|
Ne, das Problem ist dass der Fehler irgendwo im Speicher ist. Bsp man schreibt in ein Array-Feld rein dass es nicht gibt. Normal gibts dann eine Fehlermeldung. manchmal aber nicht, und dann fällt der Fehler erst Delphi auf, wenn er irgendwo was auslesen will und da wurde drin rumgeschrieben ^^ Dann gibts die Fehlermeldung, aber ganz wo anders. Wenn es bei dir jetzt einen Unterschied macht, ob du i<>j und Planet[i]<>Planet[j] schreibst, dann vermute ich mal, dass du durch den Vergleich der Adressen irgendwas anders im Prozessor machst und in den tiefen des Systems trifft er dann nicht auf den Fehler. Aber der Fehler ist ja trotzdem da. Weil wenn i=j, dann ist auch Planet[i]=Planet[j], da gibts ja keinen Unterschied. Wo der Fehler dann ist...tja, gute Frage. Nicht da wo der Fehler angezeigt wird  |
Ich hoffe, dass der Fehler nie wieder kommt  . Naja, Delphi 2005 läuft bei mir in einer VM (der Windows XP-Mode, den man bei Microsoft runterladen kann) welche in Win7 64bit läuft. Da gibt es schon recht flott irgendwelche Fehler, die unter WinXP nicht da sind  .
Xion hat folgendes geschrieben : |
Matty92 hat folgendes geschrieben : | Xion hat folgendes geschrieben : |
Jetzt hatte ich noch nen ewig langen Absatz über die Physik in deinem Programm aber ich hab nach ca. 30 Zeilen gemerkt, dass es doch richtig ist was du da stehen hast...irgendwie hab ich das damals "schöner" aufgeschrieben ^^ nicht so kompakt. |
Nur so aus Neugierde, wo wäre denn der Fehler gewesen (oder die Fehler, bei so einer Menge Text )?
Was meinst du mit schöner? Leichter verständlich? Schöner vom Aussehen ? Ich hab die Berechnungsprozedur nochmal verändert und zusammengestampft:
|
Ich hatte mich etwas gewundert, dass du Betrag^3 nimmst. Ich hatte das damals anders, bei mir stand im Code die Formel a=G*m1/r² direkt im Code, wobei die Formel ja eigentlich F=G*m1*m2/r² und F=m1*a (das m1 mit einrechnen und dann wieder teilen hab ich mir auch gespart). Und dann hab ich erst die Beschleunigung aufgeteilt. Am Ende kamen dann auch die Formeln raus, aber man hat im Code besser gesehen was passiert. Übrigens ist G <> g in Physik ^^ |
Ja, sorum geht es auch, das war meine erste Idee die ich hatte. Da hatte ich aber Probleme das aufzuteilen in x und y. Und dann hab ich es über die Kraft probiert, was irgendwie einfacher war  .
Xion hat folgendes geschrieben : |
Matty92 hat folgendes geschrieben : |
e sorgt jetzt dafür, dass es niemals zu einer Kollision kommen kann, d.h. keine Division durch 0. |
e? Du musst ja nur gucken, ob Betrag=0, dann krachts ^^ Oder noch besser, wenn Betrag<=Radius vom Planet, dann krachts ^^ |
Das Problem ist dann aber, was soll bei der Kollision passieren? Wenn die Planeten zusammen bleiben gibt es einen neuen Planeten, dessen Bewegungsvektoren sich über einen unelastischen Stoß berechnen lassen. Allerdings kann es auch sein, dass die von einander abprallen (zwei Raumsonden z.B., oder ein festes, kleines Objekt, dass in einem flachen Winkel auf einen Planeten zufliegt und wieder abprallt (von der Atmosphäre)).
Das e kann man als den Radius des Objektes verstehen, und wenn der erreicht wird kommt es dann nicht zur Kollision und die Planeten "fliegen" einfach aneinander vorbei.
Funktionieren tut das Programm zu 70%, was noch fehlt ist das Zeichnen, das speichern von Datensätzen und ein dynamisches Array, was rumzickt  .
|
|
Xion
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Do 06.05.10 18:08
Matty92 hat folgendes geschrieben : | Naja, Delphi 2005 läuft bei mir in einer VM (der Windows XP-Mode, den man bei Microsoft runterladen kann) welche in Win7 64bit läuft. Da gibt es schon recht flott irgendwelche Fehler, die unter WinXP nicht da sind . |
NOCH mehr Fehler?...also mein Delphi läuft so unrund, dass ich mich kaum traue nen Breakpoint zu setzen...Das ist die verbuggteste Version, die es von Delphi jemals gab vermute ich mal...hatte das Pech gerade zu der Zeit eine Version gekauft zu haben, und dass war dann halt D2005...mit automatischen Speichern eingestellt und immer den Taskmanager zur Hand komm ich meist klar, aber so mind. 1x pro Stunde schmiert er total ab und ich muss ihn dann killen...besonders toll wenn ich mit OpenGL arbeite, dann ist der Bildschirm nämlich zu, da hilft am Ende manchmal nur Reset...
Matty92 hat folgendes geschrieben : |
Das Problem ist dann aber, was soll bei der Kollision passieren? Wenn die Planeten zusammen bleiben gibt es einen neuen Planeten, dessen Bewegungsvektoren sich über einen unelastischen Stoß berechnen lassen. |
So hab ich das damals gemacht. Das coole war dann, den Mond auf die Erde krachen zu lassen und dann verschiebts die Erde auf der Umlaufbahn und alle Menschen erfrieren
Matty92 hat folgendes geschrieben : |
Allerdings kann es auch sein, dass die von einander abprallen (zwei Raumsonden z.B., oder ein festes, kleines Objekt, dass in einem flachen Winkel auf einen Planeten zufliegt und wieder abprallt (von der Atmosphäre)).
|
VIEL zu kompliziert gedacht ^^ Es geht ja vermutlich mehr um Gravitation in deiner Facharbeit.
Matty92 hat folgendes geschrieben : |
Funktionieren tut das Programm zu 70%, was noch fehlt ist das Zeichnen, das speichern von Datensätzen und ein dynamisches Array, was rumzickt . |
Zeichnen, jo, da kann man ne Menge Zeit mit verbringen  . Ok man kann überhaupt ne Menge Zeit mit verbringen. Ich hatte ne halbes Jahr vor Abgabe ein funktionierendes Programm...und ein Tag vor Abgabe hab ich Nachts noch komplexes Zeug gebastelt ^^ Mensch, programmieren verbraucht ne Menge Zeit *philosophisch wird*
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: Do 06.05.10 18:32
Xion hat folgendes geschrieben : | Matty92 hat folgendes geschrieben : | Naja, Delphi 2005 läuft bei mir in einer VM (der Windows XP-Mode, den man bei Microsoft runterladen kann) welche in Win7 64bit läuft. Da gibt es schon recht flott irgendwelche Fehler, die unter WinXP nicht da sind . |
NOCH mehr Fehler?...also mein Delphi läuft so unrund, dass ich mich kaum traue nen Breakpoint zu setzen...Das ist die verbuggteste Version, die es von Delphi jemals gab vermute ich mal...hatte das Pech gerade zu der Zeit eine Version gekauft zu haben, und dass war dann halt D2005...mit automatischen Speichern eingestellt und immer den Taskmanager zur Hand komm ich meist klar, aber so mind. 1x pro Stunde schmiert er total ab und ich muss ihn dann killen...besonders toll wenn ich mit OpenGL arbeite, dann ist der Bildschirm nämlich zu, da hilft am Ende manchmal nur Reset...
|
Ah, das ist böse  . Ich meinte Delphi2005+Win7, das geht gar nicht, da klappt das Programm besser wenn man es von Hand schreibt. In der VM läuft es eigentlich recht stabil. Ich hab auch Delphi 7 und Delphi 5 von der Schule (und Turbo Pascal 5.5  ), das ist irgendwie besser von der Fehlerverfolgung her, finde ich. Die 2005er ist die PE, die es bis vor kurzem (oder längerem?) kostenlos von Borland im Internet gab.
Xion hat folgendes geschrieben : |
Matty92 hat folgendes geschrieben : |
Das Problem ist dann aber, was soll bei der Kollision passieren? Wenn die Planeten zusammen bleiben gibt es einen neuen Planeten, dessen Bewegungsvektoren sich über einen unelastischen Stoß berechnen lassen. |
So hab ich das damals gemacht. Das coole war dann, den Mond auf die Erde krachen zu lassen und dann verschiebts die Erde auf der Umlaufbahn und alle Menschen erfrieren
Matty92 hat folgendes geschrieben : |
Allerdings kann es auch sein, dass die von einander abprallen (zwei Raumsonden z.B., oder ein festes, kleines Objekt, dass in einem flachen Winkel auf einen Planeten zufliegt und wieder abprallt (von der Atmosphäre)).
|
VIEL zu kompliziert gedacht ^^ Es geht ja vermutlich mehr um Gravitation in deiner Facharbeit. |
Hm, wie hast du das mit der Kollision gelöst? Das würde mich jetzt mal interessieren.
Ja, Gravitation, Keplersche Gesetze im Mehrkörpersystem überprüfen und Swing-By-Manöver und evtl. noch mehr, wobei das Hauptaugenmerk auf den Keplerschen Gesetzen liegt.
Xion hat folgendes geschrieben : |
Matty92 hat folgendes geschrieben : |
Funktionieren tut das Programm zu 70%, was noch fehlt ist das Zeichnen, das speichern von Datensätzen und ein dynamisches Array, was rumzickt . |
Zeichnen, jo, da kann man ne Menge Zeit mit verbringen . Ok man kann überhaupt ne Menge Zeit mit verbringen. Ich hatte ne halbes Jahr vor Abgabe ein funktionierendes Programm...und ein Tag vor Abgabe hab ich Nachts noch komplexes Zeug gebastelt ^^ Mensch, programmieren verbraucht ne Menge Zeit *philosophisch wird* |
Informatik und Philosophie wäre auch ein interessantes Facharbeitsthema, oder Programmierstil, oder oder oder... Ich hoffe, dass das Programm nach dem Wochenende vorzeigbar fertig wird.
Das dynamische Array zickt nicht mehr herum, ich wollte wieder Werte auf ein nicht geschaffenes Attribut zuweisen >.<  .
|
|
Xion
      

Beiträge: 1952
Erhaltene Danke: 128
Windows XP
Delphi (2005, SmartInspect), SQL, Lua, Java (Eclipse), C++ (Visual Studio 2010, Qt Creator), Python (Blender), Prolog (SWIProlog), Haskell (ghci)
|
Verfasst: Do 06.05.10 18:43
Matty92 hat folgendes geschrieben : |
Allerdings kann es auch sein, dass die von einander abprallen (zwei Raumsonden z.B., oder ein festes, kleines Objekt, dass in einem flachen Winkel auf einen Planeten zufliegt und wieder abprallt (von der Atmosphäre)).
|
VIEL zu kompliziert gedacht ^^ Es geht ja vermutlich mehr um Gravitation in deiner Facharbeit.[/quote]
Hm, wie hast du das mit der Kollision gelöst? Das würde mich jetzt mal interessieren.
Ja, Gravitation, Keplersche Gesetze im Mehrkörpersystem überprüfen und Swing-By-Manöver und evtl. noch mehr, wobei das Hauptaugenmerk auf den Keplerschen Gesetzen liegt.[/quote]
Ganz einfach.
Ist der Differenzvektor von Planet[i] und Planet[j] < Planet[i].Radius+Planet[j].Radius dann krachts.
Die Kraft dabei ist E=1/2mv²+1/2m2*v2²...für .x und .y gerechnet. Naja, und das ganze dann wieder in ne Geschwindigkeit umgerechnet. Müsste das nochmal nachgucken so auf die schnelle. Vermutlich E=1/2m(vnew)²
gleichgesetzt:
1/2mv²+1/2m2*v2²=1/2m(vnew)² /*2
v²+m2/m*v2²=(vnew)² /m
und dann noch Wurzel ziehen...müsste ich nachgucken für den exakten Code.
_________________ a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)
|
|
Matty92 
      
Beiträge: 34
|
Verfasst: Sa 08.05.10 14:49
Xion hat folgendes geschrieben : | matze hat folgendes geschrieben: | Xion hat folgendes geschrieben : | Matty92 hat folgendes geschrieben : |
Allerdings kann es auch sein, dass die von einander abprallen (zwei Raumsonden z.B., oder ein festes, kleines Objekt, dass in einem flachen Winkel auf einen Planeten zufliegt und wieder abprallt (von der Atmosphäre)).
|
VIEL zu kompliziert gedacht ^^ Es geht ja vermutlich mehr um Gravitation in deiner Facharbeit. |
Hm, wie hast du das mit der Kollision gelöst? Das würde mich jetzt mal interessieren.
Ja, Gravitation, Keplersche Gesetze im Mehrkörpersystem überprüfen und Swing-By-Manöver und evtl. noch mehr, wobei das Hauptaugenmerk auf den Keplerschen Gesetzen liegt. |
Ganz einfach.
Ist der Differenzvektor von Planet[i] und Planet[j] < Planet[i].Radius+Planet[j].Radius dann krachts.
Die Kraft dabei ist E=1/2mv²+1/2m2*v2²...für .x und .y gerechnet. Naja, und das ganze dann wieder in ne Geschwindigkeit umgerechnet. Müsste das nochmal nachgucken so auf die schnelle. Vermutlich E=1/2m(vnew)²
gleichgesetzt:
1/2mv²+1/2m2*v2²=1/2m(vnew)² /*2
v²+m2/m*v2²=(vnew)² /m
und dann noch Wurzel ziehen...müsste ich nachgucken für den exakten Code. |
Ah, über den Energieerhaltungssatz. Es ist viel einfacher als ich dachte, gnampf >.<
Danke für Herleitung  .
Naja, jetzt funktioniert das Programm zu 90% und ich hab wieder eine Zugriffsverletzung...spaßige Sache  .
Edit: Ich schaffe es einfach nicht den Fehler zu finden, der Debugger hilft mir da leider auch nicht weiter.
Einloggen, um Attachments anzusehen!
|
|
|