Wurfweitenberechnung: X-Werte bei extremen Werten falsch.

  • Themenstarter Themenstarter THuNd3rCr4cKer
  • Beginndatum Beginndatum
Status
Nicht offen für weitere Antworten.
T

THuNd3rCr4cKer

Gast
Hallo zusammen,
im Rahmen einer Schularbeit schreibe ich aktuell ein Programm, welches Wurfvorgänge mit Luftwiderstand berechnen (und grafisch darstellen soll). Nun stehe ich vor dem Problem, dass mir für relativ extreme Werte (z.B. Abwurfwinkel 89.9° oder sehr geringe Massen) das Geschoss wieder nach links abhaut, was ja nun theoretisch nicht möglich sein dürfte. Meine Frage: Warum?

Hier der zugehörige Code (Ja, ich weiß dürfte wohl kaum ressourcensparend oder besonders schön sein):
Code:
public void neuBerechnen(int i, int anzTschritte, int tAbstand)
	{
		boolean maxErreicht = false;
		vAlt = v0; 
		alphaAlt = alpha0 * (Math.PI / 180);  
		xAlt = 0.0;  
		yAlt = y0;   
		aX = 0.0;   
		aY = ay0;   
		

		vXalt = vAlt * Math.cos(alphaAlt);    
		vYalt = vAlt * Math.sin(alphaAlt);      
		alphaNeu = alphaAlt;        
		try
		{
			do
			{

			
				t = anzTschritte*dt;
				
				tabErgebnisse[i][0] = (double)Math.round(t*1000)/1000;
				tabErgebnisse[i][1] = (double)Math.round(xAlt*1000)/1000;
				tabErgebnisse[i][2] = (double)Math.round(yAlt*1000)/1000;
				tabErgebnisse[i][3] = (double)Math.round(vXalt*1000)/1000;
				tabErgebnisse[i][4] = (double)Math.round(vYalt*1000)/1000;
				tabErgebnisse[i][5] = (double)Math.round(aX*1000)/1000;
				tabErgebnisse[i][6] = (double)Math.round(aY*1000)/1000;
				

				Fwind = (0.5 * (p/100000) * cw * flaecheA * ((vXalt*vXalt) + (vYalt*vYalt))) / 10000;
				
				aX = (-1 * Math.cos(alphaNeu)) * (Fwind / m);
				aY = ay0 - (Math.sin(alphaNeu) * (Fwind / m));
				alphaNeu = Math.atan(vXalt / vYalt);
				
				vXneu = vXalt + (aX * dt);
				vYneu = vYalt + (aY * dt);
				
				xNeu = xAlt + (vXneu * dt);
				yNeu = yAlt + (vYneu * dt);
			
				if (maxErreicht == false)
				{
					if(vXalt / Math.cos(alphaAlt) > vXneu / Math.cos(alphaNeu))
					{
						vMax = vXalt;
						maxErreicht = true;
					}
				}
				xAlt = xNeu;
				yAlt = yNeu;
				vXalt = vXneu;
				vYalt = vYneu;
			
				if (yNeu < 0)
				{
					break;
				}
			
				anzTschritte++;
				if ((anzTschritte % tAbstand) != 0 && i != 0)
				{
					continue;
				}
				i++;
				if ( i >= tabLaenge)
				{
					throw new Exception();
				}
			}while(true);
		}catch(Exception kleinerMachen)
		{
			for ( int loeschen = 0; loeschen < tabLaenge; loeschen++)
			{
				tabErgebnisse[loeschen][0] = "";
				tabErgebnisse[loeschen][1] = "";
				tabErgebnisse[loeschen][2] = "";
				tabErgebnisse[loeschen][3] = "";
				tabErgebnisse[loeschen][4] = "";
				tabErgebnisse[loeschen][5] = "";
				tabErgebnisse[loeschen][6] = "";
			}	
			i = 0;
			tAbstand++;
			anzTschritte = 0;
			neuBerechnen(i, anzTschritte, tAbstand);
		}
		tMax = t;
	}

Ich hoffe die Variablen sind weitgehend selbsterklärend.
Hier der zugehörige Wikipediaartikel für die nötige Mathematik: Ballistische Kurve bei Wiki
Mein Verdacht liegt da, dass ich an einer Stelle für die richtige Berechnung die alten und die neuen Werte durcheinander hau, oder aber, dass der Zeitschritt für extreme Werte zu groß ist und deshalb gewisse 0-Punkte überschritten werden an die eigentlich nur Annäherung stattfindet.
Möglicherweise treten auch noch weitere Fehler bei der Berechnung auf, bei so augenscheinlichen Verfehlungen hab ich mir das Nachrechnen erstmal erspart...
 
Deinen Code habe ich mir nicht angeschaut. Ad hoc und allgemein lässt sich Deine Frage mit dem Hinweis auf Numerik beantworten.

Grüße, Ebenius
 
@Ebenius:
Ebenius hat gesagt.:
Deinen Code habe ich mir nicht angeschaut. Ad hoc und allgemein lässt sich Deine Frage mit dem Hinweis auf Numerik beantworten.
:applaus: :lol: das war ja ein extrem konkreter Hinweis 😉

@thund3rcr4ck3r
omfg... :shock: wo hast du denn schon jemals gesehen dass bei solch einfachen physikalischen simulationen irgendwelche Winkel bei zwischenschritten berechnet werden?

[edit]
OMFG, WAS UM HIMMELS WILLEN???? :shock: :shock: :shock:
Okay kollege, du bist leider Opfer eines völlig unzurechnungsfähigen wikipedia-artikel-schreibers geworden, nicht wirklich deine schuld :roll: Das was da steht ist einfach nur zum erbrechen. :x Ich werd mal bei gelegenheit ein kräftiges wörtchen auf die diskussionsseite bei wikipedia posten, dass sie diesen scheiß da bloß wegmachen. :autsch:

Vergiss einfach diesen ganzen winkel-scheißdreck der da steht, ok? Du brauchst genau ein mal am anfang sin und cos zu berechnen, um die benutzereingaben in eine akzeptable form umzuwandeln. Ab da geht alles mit den 4 grundrechnearten und evtl. der wurzelfunktion, vollkommen trigonometrie-frei. Das läuft dann auch dreiundsiebzig größenordnungen schneller und ohne abartige rechenfehler.
 
Gut, ge? 🙂 Eigentlich wollte ich nur ein bisschen warm werden, den Thread wieder aus der sich anbahnenden Versenkung holen und habe von dem konkreten Thema keine Ahnung. :-D

Nachtrag: Du zickst ja grad nur rum wegen des GridBagLayouts, ge? ;-)
 
@Ebenius:
wieso sollte ich deswegen "rumzicken", wenn du eine Lösung meines Problems mit GridBagLayout lieferst? 🙂 nene, alles was du hier geschrieben hast ist ja schön und gut. :toll: für die demonstration der Möglichkeiten des GridBagLayouts danke ich nochmal explizit an dieser stelle^^ 😉


Aber dieser Artikel... ach du meine Fresse...
Die Berechnung der Ballistischen Kurve in „geschlossener Form“ dürfte mit Hilfe von Differentialgleichungen zu kompliziert und damit unmöglich sein - mit Tabellenkalkulation sind noch längst nicht alle Möglichkeiten ausgeschöpft.
:x :x :x
diesen Artikel sollte man schleunigst nach Stupidedia verschieben, sowas niveauloses :?
 
Andrey hat gesagt.:
@Ebenius:
Ebenius hat gesagt.:
Deinen Code habe ich mir nicht angeschaut. Ad hoc und allgemein lässt sich Deine Frage mit dem Hinweis auf Numerik beantworten.
:applaus: :lol: das war ja ein extrem konkreter Hinweis 😉
trotzdem der richtige? Wenn ja, kann man den gerne noch etwas präzisieren 😉
Andrey hat gesagt.:
@thund3rcr4ck3r
omfg... :shock: wo hast du denn schon jemals gesehen dass bei solch einfachen physikalischen simulationen irgendwelche Winkel bei zwischenschritten berechnet werden?
noch nirgends. hab allerdings auch noch keinen code für solche simulationen gesehen. bin programmierfrischling und das ist mein erstlingswerk 😉

Andrey hat gesagt.:
[edit]
OMFG, WAS UM HIMMELS WILLEN???? :shock: :shock: :shock:
Okay kollege, du bist leider Opfer eines völlig unzurechnungsfähigen wikipedia-artikel-schreibers geworden, nicht wirklich deine schuld :roll: Das was da steht ist einfach nur zum erbrechen. :x Ich werd mal bei gelegenheit ein kräftiges wörtchen auf die diskussionsseite bei wikipedia posten, dass sie diesen scheiß da bloß wegmachen. :autsch:

Vergiss einfach diesen ganzen winkel-scheißdreck der da steht, ok? Du brauchst genau ein mal am anfang sin und cos zu berechnen, um die benutzereingaben in eine akzeptable form umzuwandeln. Ab da geht alles mit den 4 grundrechnearten und evtl. der wurzelfunktion, vollkommen trigonometrie-frei. Das läuft dann auch dreiundsiebzig größenordnungen schneller und ohne abartige rechenfehler.
Weitere Winkel brauch ich nicht? Wegen numerischer statt geometrischer Lösung?

Danke schon mal soweit. 🙂
 
THuNd3rCr4cKer hat gesagt.:
Andrey hat gesagt.:
@Ebenius:
Ebenius hat gesagt.:
Deinen Code habe ich mir nicht angeschaut. Ad hoc und allgemein lässt sich Deine Frage mit dem Hinweis auf Numerik beantworten.
:applaus: :lol: das war ja ein extrem konkreter Hinweis 😉
trotzdem der richtige? Wenn ja, kann man den gerne noch etwas präzisieren 😉

Ja, trotzdem der richtige. Die Fließkomma-Zahlen werden nach IEEE-754 abgebildet. Diese Zahlendarstellung beinhaltet immer sowas wie Rundungsfehler. Bei jeder Operation wirken sich diese Fehler aus. Deshalb wird in Extrembereichen das Ergebnis merklich falsch. Das hilft Dir noch immer nicht weiter, erklärt aber die Ursache. 🙂

Grüße, Ebenius
 
@Ebenius:
aaaah, herrlich :applaus:

@OP:
jaja, die IEEE-754 ist schon böse usw, aber ich würd dir zunächst dringend empfehlen, alle langsamen fehleranfälligen funktionen rauszuschmeißen.

Wimkeln spielen in diesem physikalischen System absolut keine Rolle, es ist nur für den menschen praktisch, um die anfangswerte festzulegen. Auf die Simulation hat es aber denselben einfluss, wie das Design der Schieberegler und Farbe der schaltflächen. Dem mechanischen System ist dies alles egal:

Die Gravitation zieht immer direkt nach unten.
Die reibungskraft ist der Geschwindigkeit entgegengesetzt. Um das auszudrücken musst du nur ein Minus davorschreiben, irgendeine bescheuerte Rechnerei mit irgendwelchen Winkeln ist da absolut unnötig. Da die reibungskraft proportional zur geschwindigkeit zum quadrat ist, musst du noch den Betrag der geschwindigkeit separat dranmultiplizieren, also sieht das eher irgendwie so aus:
Code:
geschwindigkeit v einlesen
wurfwinkel w einlesen
alle konstanten einlesen, zusammenmultiplizieren
dt einlesen (mach's klein genug, hier kostet's nix)

x=0;
y=0;
vx=Math.cos(w)*v;
vy=Math.sin(w)*v;

for(t=0; t<tMax; t+=dt){
  v=Math.sqrt(vx*vx+vy*vy);
  vx+=dt*(-vx*v*konstanten);
  vy+=dt*(-g-vy*v*konstanten);
  x+=dt*vx;
  y+=dt*vy;
  alles hinmalen
}
ist jetzt erstma pseudocode, und schnell hingehackt, kann sein dass ich mich da i-wo verschrieben hab, aber dürfte in etwa hinhauen. Wie du siehst: in der schleife weit und breit keine arkuskosinüsse.
 
Die for-Schleife wird so nicht funktionieren, weil ja im voraus noch kein tMax existiert. Wie lange der Vorgang dauert ist ja wiederum vom Vorgang selber abhängig. Also wieder eher mit do/while eine Endlosschleife erzeugen, die beendet wird sobald das Geschoss den Boden erreicht (y <= 0)?

Und ist's Absicht dass du noch korrekt schreibst, dass die Kraft vom Quadrat der Geschwindigkeit abhängig ist, dann aber nur den Betrag der Geschwindigkeit (anstatt ihres Quadrates) an die Konstanten dranhängst? Wenn ja, warum? Denke aber da ist im Gedankenchaos einfach ein v untergegangen oder?
 
THuNd3rCr4cKer hat gesagt.:
Die for-Schleife wird so nicht funktionieren, weil ja im voraus noch kein tMax existiert. Wie lange der Vorgang dauert ist ja wiederum vom Vorgang selber abhängig. Also wieder eher mit do/while eine Endlosschleife erzeugen, die beendet wird sobald das Geschoss den Boden erreicht (y <= 0)?
Naja, kommt drauf an, was dein standpunkt ist... sagst du
"ich will wissen was nach einer Minute passiert"
, dann setzt du einfach tMax=1 Minute. Sagst du
"ich will solange rechnen, bis das geschoss den waagrechten Boden erreicht hat"
oder
"ich will solange rechnen, bis das geschoss eine 10 km entfernte Wand getroffen hat"
dann nimmst du halt irgendeine x-beliebige andere abbruchsbedingung, die dir halt mehr gefällt.

Und ist's Absicht dass du noch korrekt schreibst, dass die Kraft vom Quadrat der Geschwindigkeit abhängig ist, dann aber nur den Betrag der Geschwindigkeit (anstatt ihres Quadrates) an die Konstanten dranhängst? Wenn ja, warum? Denke aber da ist im Gedankenchaos einfach ein v untergegangen oder?
mooment mal. ich häng v ja nicht an die konstanten dran, sondern an vx und vy. vx und vy beinhalten an sich auch schon die geschwindigkeit, insgesamt erhälst du dann für den betrag dieser kraftkomponente

sqrt( (vx*v)²+(vy*v)² )=sqrt( (vx²+vy²)*v² )=sqrt( v²*v² ) = v²

also ist das ganze doch proportional zum quadrat der geschwindigkeit.
 
Ja natürlich... ist mir mittlerweile auch aufgefallen, als ich mir deinen Post in einer stillen Minute nochmal durch den Kopf gehen hab lassen. Erst denken, dann posten :meld: :lol:
Vielen Dank nochmal, werde das mal ausprobieren. 😀
 
Funktioniert wunderbar, Ergebnisse von Versuchen/Berechnungen anderer Leute lassen sich bestätigen. Und weil man es nicht oft genug sagen kann: Danke schön! :wink: :toll:
 
Status
Nicht offen für weitere Antworten.

Neue Themen


Zurück
Oben