trotz “identischer Ausgabe”
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 8.3 - Ausrufezeichen
Hallo zusammen,
habe bei der Aufgabe 8.3 genau die identische Ausgabe wie in “NumberCrunchingTestOutput.txt”.
Das sagt auch “WinMerge”.
Hat jemand schon nen grünen Haken?
Gibt es wieder etwas, auf das man achten muss?
Muss man irgendwas auf eine bestimmte Art implementieren?
Vielen Dank!
Hab mir das Problem gerade mal angesehen und es liegt ausnahmsweise mal nicht an meinem Test 
Vielleicht hilft folgender Zusatztest:
System.out.println("=== Adder-Chain");
NumberCruncher chainOut = new CountingResultPrinter("Chain");
AddOperator add1 = new AddOperator();
AddOperator add2 = new AddOperator();
AddOperator add3 = new AddOperator();
add1.addListener(add2, 0);
add1.addListener(add2, 1);
add2.addListener(add3, 0);
add2.addListener(add3, 1);
add3.addListener(chainOut, 0);
add1.input(0, 2.0);
add1.input(1, 3.0);Heraus kommen sollte
[m]Chain (0): 20.0[/m]
Vielen Dank!
Dadruch habe ich einen “Fehler” in meiner “notifyListeners”-Methode entdeckt.
Jetzt ist die Ausgabe wieder identisch (auch das “Chain (0): 20.0” am Ende) und das Ausrufezeichen hat dennoch bestand.
@ hjk: Wie hast du denn die identische Ausgabe hinbekommen, wenn im Test die Fibonacci-Zahlen bis 20 statt bis 21 geprüft werden?
edit: Und wieso bekomme ich schon wieder so einen Compilerfehler wie in 8.2? Entstehen durch falsche Exceptions rote Kreuze?
[quote=Chayyam]Entstehen durch falsche Exceptions rote Kreuze?
[/quote]
Nein.
Ich hab mal eben nachgeschaut, woran es bei dir liegt:
Denkt bitte daran, dass alle Berechnungen auf [m]double[/m] durchgeführt werden sollen. Das gilt für alle Operatoren (und z.B. für deren Attribute und Konstruktoren).
Das bei mir hat sich erledigt. Meine notifyListeners()-Methode war etwas überdimensioniert… 
Man muss halt darauf achten, dass man die Verkettungen richtig gestaltet.
@ hjk:
Ich habe jetzt dieselbe Ausgabe wie du, allerdings immer noch ein Ausrufezeichen.
War deine Überdimensionierung eine Art Rekursion?
Also bei mir war in der notifyListeners-Methode das Problem, dass ich es nicht richtig an den Eingang(Input) der Listener weitergeleitet habe (falscher Methodenaufruf).
Habe das Problem dann aufgrund des weiteren Testfalls (danke nochmals dafür) erkannt und einen Workaround gebaut, der diese Weiterleitung realisiert hat.
Aber das kann der EST-Test so anscheinend nicht feststellen…aber es ging auch viel einfacher als ich gedacht habe 
Ich hoffe, dass Dir das hilft.
Danke. Meine Testergebnisse sind nämlich richtig (auch mit der 20), allerdings habe ich nirgendwo inputNumbers benötigt. Schätzungsweise muss ich das alles nochmal an dieses Array weiterleiten.
Die Indizes der Eingänge stehen in diesem Array. Die sind also schon wichtig.
Danke, hat sich erledigt. Mein Fehler waren die falschen Leerzeichen im Printer sowie einige Indexfehler.
Hallo, ich habe das gleiche Problem.
Bei mir steht trotz identischer Ausgabe nur ein Ausrufezeichen im EST.
Der Zusatztest funktioniert bei mir ebenfalls und ich habe eigentlich auch darauf geachtet, alles auf double zu berechnen.
Woran könnte das liegen?
Danke
Was laut EST oft zu ! führt:
- Werte werden an falsche input-Nummern weitergeleitet
- Werte werden zu häufig weitergeleitet, z.B. wenn sie sich gar nicht geändert haben
Es sind mittlerweile zu viele Abgaben, um jede anzuschauen, was schief geht. Geht am besten in eine RÜ, da kann euch konkret geholfen werden.
1 Like
Guten Tag Zusammen,
ich habe auch längere Zeit mit einem bösen Ausrufezeichen gekämpft (bei identischer Ausgabe), doch soeben habe ich es geschafft, es in einen
grünen Haken zu transformieren.
Damit andere nicht ebenso fast bei der Fehlersuche verzweifeln, hier eine kurze Erläuterung, was sich als Auslöser
des Ausrufzeichens herausgestellt hat:
Ich hatte in BinaryOperation beim Aufruf der operation-Methode, den ersten Wert mit Index 0
als zweiten Parameter übergeben, sowie dann den zweiten Wert als ersten Parameter.
Im Bewusstsein des Kommutativgesetzes für Addition und Multiplikation, sollte dies eigentlich egal sein! Doch dies
fabrizierte tatsächlich ein Ausrufzeichen!
So erklärt sich natürlich auch, weswegen ich bei gleicher Ausgabe eine Fehlermeldung bekam. Richtig gerechnet habe ich ja trotzdem!
Das lässt mich etwas verwundert über die teils komischen, zu einhaltenden Formalien zurück.
1 Like
Zugegeben: Bei Addition und Multiplikation ist es kein Problem und es wäre besser gewesen, wenn z.B. noch ein SubtractionOperator zu implementieren wäre.
Die abstrakte Klasse BinaryOperator darf aber nicht einfach Eingänge vertauschen, weil ja nicht bekannt ist, ob die konkrete Unterklasse eine kommutative Operation umsetzt oder nicht.
In welcher Methode meinst du das? Also in welcher Methode könnten Werte zu häufig weitergeleitet werden?
Und noch eine Frage. Ich dachte immer, man bekommt den grünen Haken, wenn die Ausgabe stimmt. Wie soll man denn herausfinden, was das Ausrufezeichen verursacht, wenn das richtige Ergebnis geliefert wird?
[quote=Cybergy]
In welcher Methode meinst du das? Also in welcher Methode könnten Werte zu häufig weitergeleitet werden?[/quote]
In [m]input()[/m], bzw in Methoden, die [m]input()[/m] benutzt um herauszufinden, ob es etwas weiterleiten muss und um es dann zu tun.
Jain. So war es schon gedacht, allerdings habe ich da eure Kreativität unterschätzt 
Da ihr alle Teile eines etwas komplexeren Systems selbst schreibt, gibts viele Möglichkeiten, Funktionalität an anderen Stellen zu implementieren, als das Blatt das vorschreibt oder Parameter für andere Dinge zu benutzen als vorgesehen. Da das Testsystem jede Komponente einzeln auf das vorgeschriebene Verhalten testet, kracht es dann im EST, obwohl die Ausgabe stimmt. Da das tatsächlich zur Fehlersuche nicht ideal ist, schaue ich ja regelmäßig nach, woher die ! kommen und gebe bei besonders häufig auftretenden Fehlern auch Hinweise.
1 Like
Guten Tag,
das EST hat mir ebenfalls ein Ausrufezeichen zurückgemeldet, obwohl meine Ausgabe bis aufs letzte Zeichen gleich dem Muster ist.
Durch den Vergleich mit einer korrekten Lsg bin ich darauf gekommen, dass ich in der Methode BinaryOperator.crunch(int, double) in der Abfrage, in der ich prüfe ob die übergebenen Werte gültig sind,
val == Double.NaN anstatt Double.isNaN(val) fälschlicherweise verwende.
Nach der Änderung ist der grüne Haken endlich da.
Vielleicht hat noch jemand dieses Problem.
1 Like
Auch von mir noch ein kleiner Tipp für eventuelle Fehlersuche:
double a[] = new double[1];
System.out.println(a[0]); // 0.0