Fachrat Informatik - Forum

schon mal mit einer E-Mail probiert?

eMail wäre wirklich ne bessere Idee gewesen ... naja, so kriegens wenigstens alle mit.

Der Tip mit der Rundung bezieht sich genau auf die Berechnung bei Brüchen. Sorgt einfach irgendwie dafür, dass alle Zahlen, die irgendwie aus ner Methode kommen zwei Stellen nach dem Komma haben, damit der vergleichende Test nicht ständig fehlschlägt bei Zahlen wie im Beispiel auf dem Übungsblatt.

EDIT: Und noch genauer: Wenn Du von einem braven 2-Stellen-nach-dem-Komma-Füllstand einen doofen 7-Nachkommstellen-Bruchwert (möglicherweise Ergebnis einer Division) abziehst, hat der Füllstand auch keine 2 Stellen mehr nach dem Komma, sondern mehr. Also mach das doch einfach nicht - oder lass die Stellen verschwinden.

Packages allgemein:
http://www2.in.tum.de/~seidl/Courses/WS2006/i19.ps

Sonstiges:
www.javabuch.de

Viel Spaß

@Neo: Hä?

@Lars:
Irgendwie hab ich den Eindruck, dass du die Frage von Philipp nicht so wirklich beantwortet hast. Es ging nicht um die Frage wozu es gut ist, dass wir die Ergebnisse runden sollen, sondern vielmehr darum dass deine Klasse Testrange - trotz korrekter Berechnung und Rundung in Car - ausspucken kann, dass der "Test nicht bestanden" wurde, und zwar einfach weil das Ergebnis der Division durch zwei nicht gerundet wird. Zum Beispiel so (was ja Pjilipp auch schon geschrieben hat):

double maxRange = mobile.getRange();
//maxRange = 3225.81

mobile.drive(maxRange / 2);
double newRange = mobile.getRange();
//newRange = 1612,9 wegen Rundung
//maxRange/2 ist aber 1612,905, also ist
//(newRange == maxRange / 2) == false.


EDIT: selbst wenn man das Ergebnis der Division noch runden würde (wie ich oben meinte) würde das ja auch nichts bringen, weil man dann (1612,91 == 1612,90) prüfen würde... Die einzige Möglichkeit wäre da wohl eine Toleranz einzubauen und zu prüfen ob das Ergebnis eine maximale Abweichung von x% vom "genauen" Wert aus der Division hat.

Das da oben sind übrigend die Werte die sich mit einem Standard-Auto mit 75 PS, Tankgröße 60L und Fahrmodus Überlandfahrt ergeben. Das kann schon verwirrend sein, wenn der Test immer "nicht bestanden" ausgibt und man alles schon zig mal geprüft hat und eigentlich hundertprozentig sicher ist, dass alles klappt.



Aber mal zur Aufgabe allgemein: wieso sollen wir den Verbrauch runden? Tankinhalt und Reichweite sehe ich ja ein, aber wenn man den Verbrauch rundet hat man hinterher in den meisten Fällen nur noch drei signifikante Stellen (mit ungerundetem Verbrauch ergibt sich als Reichweite 3233.05 km statt 3225.81, schon ein hübscher Fehler).
Mir ist schon klar, dass wir hier keine physikalisch korrekte Simulation eines Autos programmieren wollen, aber ich wollts halt mal gesagt haben.

Übrigens, meinst du im Hinweis auf dem Übungsblatt statt 1,2333339 und 1,23 nicht eher 1,2300001 oder 1,2299999 und 1,23 oder sowas?

Quoted

Original von Schokoholic
@Neo: Hä?

Wenn man versucht, ein Programm in einer Package Struktur per
Konsole aufzurufen... Da das bekannte IDE-Ecli**e wahrscheinlich nicht verwendet
werden soll, muss man das auch per Konsole können.

Edit: Es kann auch nicht schaden, sich bisschen mit Packages ausein-
anderzusetzen.

Quoted

Original von Schokoholic


Aber mal zur Aufgabe allgemein: wieso sollen wir den Verbrauch runden?

So direkt steht da ja nicht drin, dass man den Verbrauch runden soll.
Wo man rundet, ist eine Frage, wie du es implementiert hast.
Am Ende soll halt "Test bestanden!" ausgegeben werden.
Keep it smart and simple

Quoted

Original von Neo
So direkt steht da ja nicht drin, dass man den Verbrauch runden soll.
Wo man rundet, ist letztendlich eine Frage der konkreten Implementierung.
Am Ende soll es einfach nur heißen: Test bestanden!
Dürfte wohl nicht soooo schwierig sein. (Keep it smart and simple)

Quoted

Hinweis aus der Aufgabenstellung:
Passen Sie alle Berechnungen zu Füllstand, Reichweite und Verbrauch so an, dass in den Eigenschaftswerten nur noch double-Zahlen mit maximal zwei Nachkommstellen vorkommen können.

Das würd ich schon so interpretiren. Oder ist der Verbrauch deiner Meinung nach kein "Eigenschaftswert"?
Außerdem, damit da in jedem Fall steht "Test bestanden!" müsste der Hinweis lauten "Sorgen Sie dafür, dass die zweite Nachkommastelle der gerundeten Werte gerade ist!" - wenn du dir das Beispiel nochmal anguckst. Und es entspricht ja irgendwie nicht so ganz dem Wesen eines Tests, dass man das Ergebnis das man testen will an den Test anpasst.
Mit smart and simple kannte ich den Spruch übrigens noch nicht. Eher mit short oder stupid

Quoted

Original von Neo
Wenn man versucht, ein Programm in einer Package Struktur per
Konsole aufzurufen... Da das bekannte IDE-Ecli**e wahrscheinlich nicht verwendet werden soll, muss man das auch per Konsole können.

Edit: Es kann auch nicht schaden, sich bisschen mit Packages ausein-
anderzusetzen.

Jo, stimmt wohl. Mich hatte es nur gewundert, weil keiner danach gefragt hatte. Aber vielleicht freut sich ja jemand darüber.
Nur hat glaub ich nicht jeder ein Programm mit dem man Postscript in PDF umwandeln oder auch direkt ansehen kann. Meinste das stört den Verfasser, wenn ich das Ding hier als PDF anhänge?
In Herr Beckers Folien hab ich das mit dem Ausführen auf Anhieb so konkret auch nicht gefunden.

Wieso zensierst du das IDE? Ist das so ein böses Schmipfwort?

Man kann auch einfach diesen Link in Google pasten, und dann die Text
Version betrachten. Fehlen zwar ein paar Grafiken, ist aber nicht wirklich
wichtig, um den Inhalt zu verstehen.

Quoted

Original von Schokoholic

Das würd ich schon so interpretiren. Oder ist der Verbrauch deiner Meinung nach kein "Eigenschaftswert"?

Da hast du recht. Bin auch bisschen verpeilt. Aber ich würde einfach gucken, dass es
irgendwie hinhaut. Dabei spielt aber denke ich keine Rolle, ob der 2. Nachkomma Wert ungerade oder gerade ist, solange du das berücksichtigst.

Edit: Der Verbrauch wird nicht als Instanzvariable gespeichert, sondern berechnet.

Quoted

Original von Schokoholic
Außerdem, damit da in jedem Fall steht "Test bestanden!" müsste der Hinweis lauten "Sorgen Sie dafür, dass die zweite Nachkommastelle der gerundeten Werte gerade ist!"

hm.. muss da selbst nochmal ein Blick reinwerfen...

Zu der Sache mit den ungerade Nachkommastellen:

Die Zeile

"return (newRange == maxRange / 2);"

in Testrange.java sorgt bei mir auch für Probleme. Sobald maxRange eine ungerade Nachkommastellen hat, haut der Vergleich nicht mehr hin. Dies liegt daran, dass eine ungerade Nachkommastelle "/2" zu einer zahl mit 3 Nachkommastellen führt, welche niemals gleich einer Zahl mit 2 nachkommastellen ist. Das eine Zahl ungerade Nachkommastellen hat, kommt vor, und sollte nichts mit dem Programm oder vergessenen Rundungenzu tun haben. Die hälfte aller existierenden Nachkommastellen sind ungerade!

Beispiel für was Schiefgehendes:
NewRange (nach Drive-Aufruf aus Testrange.java; gerundet): 1616.53
MaxRange: 3233.05
maxRange durch 2: 1616.525

<Bei zeitmangel überlesen>

Hab mich an den Vorschlag "Sorgen Sie dafür, dass die zweite Nachkommastelle der gerundeten Werte gerade ist!". Dazu hab ich wenn eine Zahl eine ungerade Nachkommastelle hat, einfach 0.1 dazuaddiert. Dies geschieht bei mir in der getRange(). Nun tritt folgendes Problem auf:
Mal angenommen, (getRange()+0.01) /2 ist nachkommastellen-ungerade (zB. bei meinem Beispiel oben), wobei "getRange()+0.01" nachkommastellen-gerade ist. Nun benutzt die Klasse Testrange.java "mobile.drive(maxRange / 2)". der darauffolgende "double newRange = mobile.getRange()" holt zwangsläufig ein nachkommastellen-gerades Ergebnis (hab ja die getRange() modifiziert). "return (newRange == maxRange / 2)" liefert zwangsläufig false. Damit dieser Ansatz funktioniert müsste die getRange (zB über ne static-variable) speichern wie oft sie aufgerufen wurde und beim newRange = mobile.getRange() einen Wert zurückliefern, wo nicht +0.01 gerechnet wurde. Dies könnte dadurch geschehen dass alle 2 getRange() aufrufe unter keinen umständen +0.01 hinzuaddiert wird. Wird zugegebenermaßen sehr hässliger code. Und Scheitern kann er immernoch zB kommt manchmal x+0.01 => +x0.010000004 und ähnliches raus. Zusätzlich könnte es unter umständen nötig sein 0.1 abzuziehen statt dazuzuaddieren (hab nicht genauer drüber nachgedacht).

</Bei zeitmangel überlesen>

Alles in allem würd ich sagen, dass man nie 2 double-variablen direkt miteinander Vergleichen sollte, unabhängig davon ob sie vorher auf nachkommastellen gerundet wurden, irgendwas kann immer schiefgehen (zB s.o, und bei fehlern beim auf/abrunden nahe an rundungsgrenzen).

Daher mein Vorschlag:
In der Testrange.java
"return (newRange == maxRange / 2);"
in
"return (Math.abs(newRange - (maxRange / 2)) <= 0.005)"
ändern (Was gegen die Aufgabenstellung, die Funktion nicht zu ändern verstoßen würde...).
Mein Änderungsvorschlag würde eine kleine Abweichung als "gleich" durchgehen lassen. Würde man nicht vorher auf 2 Nachkommastellen runden, könnte man die tolerierte Abweichung wesentlich kleiner wählen.

Hi,

sorry, ich hab das hier grade eben erst gelesen. Ich hoffe, Ihr habt alle nicht zu sehr geschwitzt, diesen Test zum Laufen zu bringen, denn trotz Rundungen kann in bestimmten Fällen der Vergleich

nicht funktionieren (danke für die Hinweise oben). Man könnte das hinkriegen, aber damit rumzufummeln ist hier nicht Sinn der Sache: Es ging in der Aufgabe vielmehr darum, dass das Interface richtig implementiert wurde und der Test überhaupt ohne Compiler-Fehler ausgeführt werden kann. Daher ändere ich die Aufgabenstellung in sofern, als dass es nicht mehr nötig ist, den Test zu "bestehen". Das ist die einfachste Lösung. Tut mir leid, geht raus in die Sonne

Lars

Ach, die Zweitsemester-Informatiker unter den Java-Teilnehmern lernen doch gerade Gleitkommazahlen in GRA - die könnten daran doch gleich lernen, wofür solches Wissen wichtig ist

Danke Julian, vielen vielen Dank. Neben Java haben wir auch noch was anderes zu tun, wie zum Beispiel GRA, oder Mathe oder ab und zu auch mal Elektrotechnik.
Naja, ich hab mich jetzt mal etwas der Aufgabenstellung widersetzt und in die TestRange eine Toleranz von 0.005 eingebaut.
Das reicht, um sich mit den Rundungen nicht allzu sehr den Kopf zu zerbrechen. Und bevor jetzt jemand was sagt, ich weiß was Lars da oben schon gepostet hat.
Kommt ja im Endeffekt nur auf die Richtigkeit der Car-Klasse an.

Quoted

Original von Brainbug
[...] und der Test überhaupt ohne Compiler-Fehler ausgeführt werden kann.[...]

Also reicht ein das hier?
Das wird auch ohne Compilerfehler ausgeführt

Quoted

Tut mir leid, geht raus in die Sonne

Jo, so geiles Wetter und meiner einer muss den ganzen Tag arbeiten *seufz*. Naja, wat solls. Morgen ist ja wieder Uni, da können wir das schöne Wetter auch genießen -- im Hörsaal, während wir andächtig Herr Steffens' Ausführungen über ... äh ja ... über <Platzhalter für aktuelles Thema>, lauschen

So long,
da Fritz