Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Aufgabe 1.3 b Ergebnis an sich richtig, aber mit “0000000005” als zusätzliche Nachkommastellen
Hey!
Ich hab bei der 1.3 b ein kleines Problem. Meine Lösungswerte und die zur Überprüfung angegebenen Werte sind identisch, allerdings hängt bei meinen Werten noch irgend ein Unsinn dran:
77 PS = 56.633500000000005 kW statt den angegebenen 56.6335 kW.
Ich verstehe nicht ganz wie der Fehler zustande kommen kann da ich keine Typumwandlungen durchgeführt habe sondern nur eine einfache Multiplikation: double-Wert * Zahl. Kann mir jemand weiterhelfen? 
Rechnen mit Gleitkommazahlen ist immer mit einer gewissen Ungenauigkeit behaftet. Dein Rechenweg ist also vermutlich schon korrekt.
Für die Korrektur ist das auch egal, da hier eine gewisse Abweichung ε erlaubt ist.
Und warum das so ist lernst du in GTI 
Ich vermute mal, dass dies der Hintergrund sein müsste:
http://stackoverflow.com/questions/7856136/java-inaccuracy-using-double
Gibt, wenn man weiter sucht, auch einige Snippets, wie man das vermeiden kann. Aber das wäre ja ein Plagiat 
Zur Aufgabe:
Ich kann dir sagen, dass ich das weder in C# noch in Java als Ergebnis bekomme.
Inwiefern darf man eigentlich die Übungsaufgaben im Vorfeld besprechen? Dachte eigentlich, dass dies nicht so gern gesehen ist.
Es ist, vor allem bei Gruppenaufgaben, ausdrücklich gewünscht, dass sich Studenten auch zusammen über Aufgaben Gedanken machen und gegenseitig helfen. Was nicht gewünscht ist, sind Sachen wie Schritt-für-Schritt-Anleitungen und Posten von eigenem Code. Damit würdest du dir auch nur selbst ins Bein schießen, da du dann vermutlich als Plagiatspender erkannt wirst.
Ich hab den Code mal im EST hochgeladen und trotzdem kein “error in given testcase” oä gekriegt, ich belasses mal dabei. Vielen Dank für die Antworten!
hatte das gleiche “Problem”, habs gelöst.
Kleiner Tipp: manchmal ist eine “clevere” oder “kompaktere” Lösung nicht immer die beste ;D
Ich hoffe ich hab hier jetzt nicht zu viel “verraten”…
Es ist ja kein Problem, es ist nur ein „Rundungsfehler“, welcher bei Gleitkommazahlen einfach vorkommt.
Darum sollte man Gleitkommazahlen auch nie(!!) mit einem „==“ vergleichen, sondern bei einem Vergleich immer Prüfen ob die Differenz kleiner als eine Toleranz ε ist.
Das ist kein Rundungsfehler. Rundungsfehler kommen vor wenn gerundet wird. Sonst nicht.
Nö. Das ist kein Plagiat. Sofern die Verwendung des Codes nicht gegen die Lizenz verstößt unter der das Snippet veröffentlicht wurde, kann man den Code übernehmen. Das wäre ja ein Grauß, wenn man als Programmierer wirklich jedes Rad neu erfinden muss. Von einem anderen AuD-Teilnehmer würde ich den Code natürlich wegen direkt nachweisbarem Plagiatismus nicht übernehmen. Obwohl man auch in diesem Fall durch sauberes Refactoring jeglichen Verdacht auf ein Plagiat ausmerzen kann.
On topic: Die zusätzlichen Nachkommastellen sind der Ungenauigkeit von Fließkommazahl-Datentypen wie double oder float geschuldet. 56.6335 kann nicht exakt per double repräsentiert werden. Mit solchen Problemen schlägt man sich auch in der Numerik rum. Ein Beispiel für dieses Problem findet man auch in diesem Wikipedia Artikel zu IEEE 754: IEEE 754 – Wikipedia
Dann poste doch bitte nach Abgabefrist (20.10, 10 Uhr) hier eine Lösung zu der Aufgabe, die einen exakten (ungerundeten) Rückgabewert hat.
Prelude Data.Ratio> 7355 % 10000 == toRational (0.7355 :: Double)
False