C Programm max. Geschwindigkeit vom Auto berechnen
-
Sorry hatte nicht den öffentlichen Link geposted. Das müsste nun gehen: https://onlinegdb.com/I20uiuUIS
-
@jasmin89 Deine Variablen sind nicht initialisiert.
Die können dann einen beliebigen Wert haben.
Da sollte auch der Compiler warnen.
Du kannst auch fscanf(fp, "%lf,%lf,%lf", wert1, …) zum lesen der Datei nutzen.
-
Was mir auf Anhieb auffällt:
directionist uninitialisiert...sqrt(vx*vx + vy*vy)solltest du nur einmalig berechnen und in einer Variablen speichern
Generell beachte die Warnungen des Compilers (mit Option
-Wall).Und einige der Eingabewerte haben eine höhere Anzahl von signifikanten Ziffern (> 16), als ein
doubleaufnehmen kann, s. untere Tabelle in Zahlenformate und andere Festlegungen des IEEE-754-Standards.
-
@jasmin89 Und auch C kennt Fortsetzungszeilen https://www.c-plusplus.net/forum/topic/46169/zeilenumbruch-im-code
-
@Th69 sagte in C Programm max. Geschwindigkeit vom Auto berechnen:
sqrt(vx*vx + vy*vy)solltest du nur einmalig berechnen und in einer Variablen speichern
Eigentlich braucht man das auch nur für die Ausgabe berechnen.
-
Danke für die Tipps, habe einige umgesetzt. Bin gar nicht auf die Idee gekommen dass bereits die Eingelesenenen Fließkommazahlen eine höhere Anzahl von signifikanten Stellen haben als der Datentyp. Ich verwende nicht mehr atof sonder strtold. Dabei verwende ich den Datentyp long double nur für das einlesen der Daten. Ich komme nun genau auf das Ergebnis:
https://onlinegdb.com/iE7pX7Wy2Komischerweiße wenn ich fscanf verwende (und auch für die Berechnung long double verwende) komme ich auf ein anderes Ergebnis:
https://onlinegdb.com/vCol6iQGdAf jeden Fall verwende ich die Version wo ich auf die richtige Lösung komme.
-
@jasmin89 sagte in C Programm max. Geschwindigkeit vom Auto berechnen:
Danke für die Tipps, habe einige umgesetzt. Bin gar nicht auf die Idee gekommen dass bereits die Eingelesenenen Fließkommazahlen eine höhere Anzahl von signifikanten Stellen haben als der Datentyp. Ich verwende nicht mehr atof sonder strtold. Dabei verwende ich den Datentyp long double nur für das einlesen der Daten. Ich komme nun genau auf das Ergebnis:
https://onlinegdb.com/iE7pX7Wy2Komischerweiße wenn ich fscanf verwende (und auch für die Berechnung long double verwende) komme ich auf ein anderes Ergebnis:
https://onlinegdb.com/vCol6iQGdDas liegt nicht an scanf, sondern eben daran, dass du deinen Variablen einen anderen Typ gegeben hast. Warum sollte das komisch sein, dass bei anderer Genauigkeit eine andere Genauigkeit herauskommt?
-
@jasmin89 sagte in C Programm max. Geschwindigkeit vom Auto berechnen:
Nur hat er uns gesagt dass das Ergebnis auf die Kommastelle genau stimmen muss, ansonsten erhalte ich keine Punkte. Bei mir weicht die 15.te Nachkommastelle von der Lösung ab und komme nach langer Zeit nicht selbst auf den Fehler.
...
Die Lösung ist: 5.273075844681093
Ich komme auf: 5.273075844681092Hab mir deinen Code nicht angesehen, aber ich behaupte mal diese Forderung ist Quatsch.
Selbst wenn man exakt den selben Algorithmus verwendet, macht es einen Unterschied z.B. in welcher Reihenfolge man Berechnungen ausführt. Mathematisch ist das bei z.B. Addition egal. Bloss wenn man es mit am Computer mit Gleitkommazahlen rechnet, können dabei unterschiedliche Ergebnisse rauskommen. Der Grund ist dass bei Rechnungen mit Gleitkommazahlen nach jedem Rechenschritt gerundet wird. Und zwar nicht auf eine fixe Anzahl von Nachkommastellen sondern auf eine fixe Anzahl von signifikanten Stellen (im Binärsystem).
Als Beispiel um das zu verdeutlichen nehmen wir an wir hätten dezimale Gleitkommazahlen die auf zwei signifikante Stellen runden. Und damit wollen wir drei Zahlen addieren: 0.14, 0.033 und 1.1.
0.14 + 0.033 = 0.173 = 0.17 gerundet
0.17 + 1.1 = 1.27 = 1.3 gerundetIn anderer Reihenfolge gerechnet:
1.1 + 0.14 = 1.24 = 1.2 gerundet
1.2 + 0.033 = 1.233 = 1.2 gerundetOops
Weiters kommt dann auch noch dazu dass manche Compiler, je nach Einstellung, selbst bestimmte Umformungen durchführen. Bzw. je nach Compiler und Einstellung kann es auch sein dass Zwischenergebnisse in den guten alten 80 Bit Gleitkommaregistern gehalten werden - ohne nach jedem Rechenschritt auf 64 Bit Genauigkeit beschnitten zu werden. Dabei kann dann auch schnell ein anderes Ergebnis rauskommen als wenn man durchgehen mit nur 64 Bit rechnet.
Dieses Problem liesse sich lösen indem man die genauen Compiler-Einstellungen vorgibt. Das Problem mit der Reihenfolge ist aber fundamental und bleibt.
-
@DirkB sagte in C Programm max. Geschwindigkeit vom Auto berechnen:
@Th69 sagte in C Programm max. Geschwindigkeit vom Auto berechnen:
sqrt(vx*vx + vy*vy)solltest du nur einmalig berechnen und in einer Variablen speichern
Eigentlich braucht man das auch nur für die Ausgabe berechnen.
Die Wurzel, ja. Den
vx*vx + vy*vyTeil muss man schon ausrechnen. Wie sollte man sonst das Maximum finden?
-
@hustbaer sagte in C Programm max. Geschwindigkeit vom Auto berechnen:
Den vxvx + vyvy Teil muss man schon ausrechnen. Wie sollte man sonst das Maximum finden?
Klar.
Aber bei der anschließenden Zuweisung an max_speed traue ich dem Compiler zu, dass er sich den Wert noch vom Vergleich merkt - zumindest wenn man Optimierung erlaubt.
-
@hustbaer sagte in C Programm max. Geschwindigkeit vom Auto berechnen:
Hab mir deinen Code nicht angesehen, aber ich behaupte mal diese Forderung ist Quatsch.
Selbst wenn man exakt den selben Algorithmus verwendet, macht es einen Unterschied z.B. in welcher Reihenfolge man Berechnungen ausführt. Mathematisch ist das bei z.B. Addition egal. Bloss wenn man es mit am Computer mit Gleitkommazahlen rechnet, können dabei unterschiedliche Ergebnisse rauskommen. Der Grund ist dass bei Rechnungen mit Gleitkommazahlen nach jedem Rechenschritt gerundet wird. Und zwar nicht auf eine fixe Anzahl von Nachkommastellen sondern auf eine fixe Anzahl von signifikanten Stellen (im Binärsystem).
Was dann der Grund ist, wieso man in Numerik lernen sollte, worauf man warum achten muss, bei der Wahl der Reihenfolge. Denn es gibt halt Reihenfolgen (oder gar ganze Rechenwege!), bei denen das Ergebnis genauer ist als bei anderen, und das kann man auch begründen mit Wissen um Fließkommazahlen.
Aber hier hast du vermutlich Recht und es ist Quatsch; der Prof will wahrscheinlich nur ein simples Kriterium für die Bewertung haben. Wenn die Feinheiten der Fließkommatechnik ein Thema gewesen wären, hätte die Aufgabe anders ausgesehen (Man kann ganz einfach realistische Aufgaben stellen, wo das Ergebnis sich bei falschem Rechenweg um Größenordnung unterscheiden würde) und jasmin89 hätte andere Fragen gestellt.
-
Aber hier hast du vermutlich Recht und es ist Quatsch; der Prof will wahrscheinlich nur ein simples Kriterium für die Bewertung haben.
Ja, glaube ich auch.
Natürlich ist das Beispiel so einfach dass dabei wirklich nicht viel schief gehen kann. Naiv ausprogrammiert gibt es da ja eigentlich keine Operationen die man in unterschiedlicher Reihenfolge machen könnte.
Wo ich allerdings ein echtes Problem bei diese Aufgabe sehe sind die
sinundcosFunktionen. Soweit ich weiss sind die in quasi keiner Implementierung exakt (=nur der unvermeidbare Rundungsfehler) - sondern können auch manchmal um etwas mehr als 0.5 ULP abweichen. Und natürlich machen auch nicht alle Implementierungen die selben Fehler.
-
@hustbaer Danke für die Informationen, wieder etwas gelernt.
Auf jeden Fall wird der Professor schon zufrieden sein. Keine Ahnung warum aber er hat immer ein Hawaii T-Shirt an.
-
Hello this is Gulshan Negi
Well, if you are experiencing an error that is causing a difference in the 15th decimal place of your calculations, it can be challenging to determine the source of the error. However, there are several strategies that you can use to identify and resolve the issue, such as checking your calculations, inputs, software settings, rounding, and considering the limitations of the problem. If you are still struggling, seeking assistance from your professor or a tutor can be beneficial. Remember, accuracy is important in academic and professional settings, so it's essential to take the time to identify and correct any errors in your work.
Thanks
