P1 Task 2: testEvaluate

alexanderheinrich
Erstie
Erstie
Beiträge: 12
Registriert: 17. Apr 2013 11:47

P1 Task 2: testEvaluate

Beitrag von alexanderheinrich »

Entweder mache ich einen Denkfehler oder im test testEvaluate in TestTask2 fehlt nach Zeile 215 buildList der call auf assembleNumbers(). Sonst wird kann man den Term nicht berechenn da die 100 zu einer 1 und einer 0 wird.

Lg Alex
Zuletzt geändert von Bug am 24. Apr 2013 16:33, insgesamt 1-mal geändert.
Grund: Threadtitel geändert, damit andere schneller erkennen können, auf welchen Task es sich bezieht - bitte in Zukunft die entsprechende Konvention beachten

Benutzeravatar
Bug
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 161
Registriert: 12. Okt 2011 10:28

Re: P1 Task 2: testEvaluate

Beitrag von Bug »

Es ist nicht die Aufgabe des Tests assembleNumbers() aufzurufen, sondern gehört zu den Teilen des Evaluate-Prozesses.

Oder nochmal generell gesagt: Im Laufe der Aufgabenstellung werden einige Funktionen implementiert, die nicht nur nach Außen verfügbar sein sollten (in einem echten großen Softwareprojekt würde man die Sichtbarkeit sicherlich weiter einschränken, aber so lässt es sich leichter testen), sondern die Methoden sollten natürlich dazu genutzt werden, eine Auswertung der Liste durchzuführen. :mrgreen:
Ophasen-Leitung Winter 2014/15, Sommer 2015, Sommer 2016 & Winter 2016/17
TGdI Tutor WiSe 14/15, 13/14 und 12/13
GdI II Betreuung Praktika SoSe 13
CMS Tutor SoSe 13

Schnell
Nichts ist wie es scheint
Beiträge: 23
Registriert: 11. Feb 2010 22:27

Re: P1 Task 2: testEvaluate

Beitrag von Schnell »

Beim 1. Testcase "3+5*6-5/10*100+2", erwartet er die Lösung "35". Aber laut meinem Kopf und laut http://www.wolframalpha.com/input/?i=3% ... 10*100%2B2 müsste -15 sein.
Im Test wird ja offensichtlich zuerst 10*100 und dann 5/1000 gerechnet, sodass eine dezimal zahl rauskommt die dann ignoriert wird weil der Test mit dem integercalc rechnet. Ohne irgendwelche Klammern müsste es aber 0.5*100=50 sein.
Mein programm kriegt zwar komischerweise keines von beiden raus, obwohl alle anderen tests erfolgreich durchliefen, aber was zählt dann am ende?
Edit: Mir ist gerade eingefallen, dass er wahrscheinlich schon bei 0.5 nur noch mit 0 rechnet und dementsprechend dann 0*100 rechnet. Somit erübrigt sich dieser post dann wohl.

Benutzeravatar
JannikV
Nerd
Nerd
Beiträge: 609
Registriert: 24. Apr 2011 12:42

Re: P1 Task 2: testEvaluate

Beitrag von JannikV »

Richtig. Der IntegerCalculator wertet 5/10 zu 0 aus.

VG

DenK
Erstie
Erstie
Beiträge: 14
Registriert: 26. Apr 2013 19:13

Re: P1 Task 2: testEvaluate

Beitrag von DenK »

Bei mir spuckt er [28] raus und ich habe keinen blassen Schimmer wie er darauf kommt.
Hab ich vielleicht bei der Implementation der Rechenoperationen Fehler gemacht, die durch die anderen Tests nicht erfasst werden?
Vielleicht kann mir jemand einen kurzen Hinweis geben. Danke schomal :wink:

Gruß Dennis

Benutzeravatar
Bug
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 161
Registriert: 12. Okt 2011 10:28

Re: P1 Task 2: testEvaluate

Beitrag von Bug »

Dieses Ergebnis habe ich ehrlich gesagt noch nie gesehen. Am besten also mal schrittweise mit dem Debugger durchgehen und per Hand dabei nachrechnen, um den Fehler zu finden.
Ophasen-Leitung Winter 2014/15, Sommer 2015, Sommer 2016 & Winter 2016/17
TGdI Tutor WiSe 14/15, 13/14 und 12/13
GdI II Betreuung Praktika SoSe 13
CMS Tutor SoSe 13

DenK
Erstie
Erstie
Beiträge: 14
Registriert: 26. Apr 2013 19:13

Re: P1 Task 2: testEvaluate

Beitrag von DenK »

Nach langer suche bin ich jetzt darauf gekommen, dass ich einfach den Aufruf von assembleNumbers() in evaluate() vergessen hatte. Man sollte sich auch die Tests genauer anschauen. Bin einfach davon ausgegangen, dass das schon gemacht wurde :-P

Danke aber!

hendrik
Neuling
Neuling
Beiträge: 3
Registriert: 2. Mai 2013 23:22

Re: P1 Task 2: testEvaluate

Beitrag von hendrik »

hallo also bei mir kam auch 28 statt 35 raus wenn ich nun in evaluate erst this.assembleNumbers(); aufrufe, erhalte ich einen error
java.lang.NumberFormatException: For input string: "("
at java.lang.NumberFormatException.forInputString(Unknown Source)
.
.
.
ich weiß einfach nicht an welcher stelle das problem liegen könnte.
lg hendrik

Benutzeravatar
Bug
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 161
Registriert: 12. Okt 2011 10:28

Re: P1 Task 2: testEvaluate

Beitrag von Bug »

Du versuchst irgendwo in der assembleNumbers ein "(" in eine Zahl zu parsen. Das wirft eine Exception. Wo genau kann ich natürlich nicht sagen, also einfach mal debuggen.

Achtung: Es ist nicht ausreichend, Zahlen in einen Integer zu parsen, da die Zahlen größer werden können als der maximale Wert, der in Integer gespeichert werden kann. Genaueres dazu steht in der Aufgabenstellung...
Ophasen-Leitung Winter 2014/15, Sommer 2015, Sommer 2016 & Winter 2016/17
TGdI Tutor WiSe 14/15, 13/14 und 12/13
GdI II Betreuung Praktika SoSe 13
CMS Tutor SoSe 13

ConnorVD
Neuling
Neuling
Beiträge: 10
Registriert: 2. Mai 2013 11:16

Re: P1 Task 2: testEvaluate

Beitrag von ConnorVD »

Ich habe folgendes Problem bei dem Test:
Wenn ich die findAddOrSubOperation()- und findMulOrDivOperation()-Methode nicht abbrechen lasse, wenn sie an eine schließende Klammer kommen, bricht der Test bei der dritten Eingabe ab.

Code: Alles auswählen

1) "(33+43)*434-45/10+((10-52)*(6-100)*(0-1)+(5*(5*(5*(((5)))))))"
2) "(76)*434-45/10+((10-52)*(6-100)*(0-1)+(5*(5*(5*(((5)))))))"
Meine evaluateSimpleExpression()-Methode beginnt an der first-Position (1) und rechnet die simple Expression an dieser Stelle aus.
Bevor sie die Klammer eliminiert läuft die findAddOrSubOperation()-Methode nochmals drüber, um sicherzugehen,dass auch alle Additionen und Subtraktionen innerhalb dieser simpleExpression evaluiert wurden.
(So vermeide ich dass Konstrukte a la "(1+1+1+1)" nicht vollständig evaluiert werden)
Wenn die Methode nun allerdings über Klammern hinaus läuft, kommt sie an die "10+..." ( "(76)*434-45/10+(...)" ) und bleibt hängen, weil der zweite Operand der Addition eine Klammer ist.
Das macht ja rein logisch gar keinen Sinn, da dieser Ausdruck noch nicht evaluiert werden solle.
Wenn ich nun allerdings die find-Methoden an den schließenden Klammern abbrechen lasse, läuft der Test für die evaluate()-Methode, aber selbstverständlich die Tests für die beiden find-Methoden nicht mehr.

Ich kann verstehen, dass die gewünschte Vorgehensweise bei Konstrukten wie: "(5)+3" sinnvoll sind, da man so die unnötige Klammer umgehen kann.
Allerdings ist meine evaluateSimpleExpression so aufgebaut, dass in so einem Fall erst die Klammern wegevaluiert würden und anschließend die Addition berechnet wird.

Ich bin mir sicher dass es auch eine Lösung gibt bei der beide Tests positiv verlaufen, aber warum kompliziert wenns auch einfach geht? :?

Benutzeravatar
Bug
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 161
Registriert: 12. Okt 2011 10:28

Re: P1 Task 2: testEvaluate

Beitrag von Bug »

Unabhängig davon, was man sinnvoll findet oder nicht: Die Interfaces sind so vorgegeben und müssen eben auch entsprechend umgesetzt werden, um die Tests zu erfüllen.

Wie genau man das jetzt mit deiner Lösung in Einklang bringen kann, weiß ich natürlich nicht...

Es ist aber Absicht, dass die find Methoden die Semantik des Ausdrucks ignorieren.
Ophasen-Leitung Winter 2014/15, Sommer 2015, Sommer 2016 & Winter 2016/17
TGdI Tutor WiSe 14/15, 13/14 und 12/13
GdI II Betreuung Praktika SoSe 13
CMS Tutor SoSe 13

djente
Neuling
Neuling
Beiträge: 8
Registriert: 2. Mai 2013 18:13

Re: P1 Task 2: testEvaluate

Beitrag von djente »

Ich habe auch ein sonderbares Phänomen:

Ich habe inzwischen evaluateSimpleExpression auf 2 verschiedenen Arten implementiert und beide werden auch von der JUnit als richtig ausgegeben, aber bei der einen liefert dann evaluate 33 statt 35 und bei der anderen 3 statt 35 '-.-

Benutzeravatar
Bug
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 161
Registriert: 12. Okt 2011 10:28

Re: P1 Task 2: testEvaluate

Beitrag von Bug »

Wie ich schonmal irgendwo anders geschrieben habe: Durch Testen kann man eben nur Fehler finden, aber sie nicht ausschließen. Also sind wohl irgendwo zumindest in einer der Implementierungen von evaluateSimpleExpression Fehler enthalten. Genaueres kann ich ohne Blick auf den Code natürlich nicht sagen.

Da bleibt wohl nur genaues Debuggen und Überprüfung der Ergebnisse per Hand.

Achtung: Zum Debuggen muss der Timeout auskommentiert werden.
Ophasen-Leitung Winter 2014/15, Sommer 2015, Sommer 2016 & Winter 2016/17
TGdI Tutor WiSe 14/15, 13/14 und 12/13
GdI II Betreuung Praktika SoSe 13
CMS Tutor SoSe 13

djente
Neuling
Neuling
Beiträge: 8
Registriert: 2. Mai 2013 18:13

Re: P1 Task 2: testEvaluate

Beitrag von djente »

ok, ich habe die Funktion nochmal neu geschrieben und inzwischen funktioniert evaluate für integer zahlen.

Also Testcase 1 funktioniert.


Beim Testcase 2 erhalte ich dann aber:

Code: Alles auswählen

 java.lang.NumberFormatException: For input string: "5.1"
	at java.lang.NumberFormatException.forInputString(Unknown Source)
	at java.lang.Integer.parseInt(Unknown Source)
	at java.math.BigInteger.<init>(Unknown Source)
	at java.math.BigInteger.<init>(Unknown Source)
	at math.IntegerCalculator.div(IntegerCalculator.java:73)
	at math.MathList.evaluateSimpleExpression(MathList.java:267)
	at math.MathList.evaluate(MathList.java:313)
	at test.TestTask2.testEvaluate(TestTask2.java:225)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:62)
Bisher habe ich immer versucht Berechnungen über den Calculator machen zu lassen in Form von:

Code: Alles auswählen

calc.div(leftoperand);
Muss ich bei evaluateSimpleExpr nochmal eine extra Entscheidung treffen, welcher calculator zu nehmen ist? (also BigInteger oder BigDecimal)


// edit: oder reicht ein Verweis bei der BigInteger Klasse auf BigDecimal aus, falls es zu einer Nicht-BigInteger-Eingabe kommen sollte?

Benutzeravatar
Bug
Endlosschleifenbastler
Endlosschleifenbastler
Beiträge: 161
Registriert: 12. Okt 2011 10:28

Re: P1 Task 2: testEvaluate

Beitrag von Bug »

Nein, der calculator wird von außen vorgegeben und in calc abgelegt. Wenn der IntegerCalculator ausgewählt wurde, sollte immer mit BigInteger und nie mit BigDecimal gerechnet werden.

Der Fehler tritt auf, wenn man versucht, eine Kommazahl in einen BigInteger zu parsen.
Ophasen-Leitung Winter 2014/15, Sommer 2015, Sommer 2016 & Winter 2016/17
TGdI Tutor WiSe 14/15, 13/14 und 12/13
GdI II Betreuung Praktika SoSe 13
CMS Tutor SoSe 13

Antworten

Zurück zu „Archiv“