Was ist eigentlich der Grund dafür, dass es mit Random.nextDouble() SO VIEL schneller als mit Math.random() geht? Mit Random laufen die Tests bei mir in angemessener Zeit durch. Bei meiner Anfangsversion mit Math.random aber habe ich etwa 5 Minuten gewartet und dann abgebrochen, weil noch nicht einmal der erste Test fertig war…
Zufallszahlengeneratoren besitzen einen internen Zustand. Bei Math.random() wird für alle Threads ein globaler Zustand verwendet, der intern synchronisiert ist. Wenn man für jeden Thread ein Random-Objekt erstellt, hat jedes dieser Random-Objekte einen eigenen internen Zustand. Daher können verschiedene Threads auch gleichzeitig Random.nextDouble() aufrufen, Math.random() hingegen nicht.
Eine Alternative zu Random-Objekten ist seit Java 7 übrigens auch ThreadLocalRandom (dazu muss man allerdings genau auf die richtige Benutzung achten).
Die Ellipse verwirrt mich gerade ziemlich.
Laut API gibt man einer Ellipse im Kontruktor doch die x-Koordinate der linken oberen Ecke (eines die Ellipse umrahmenden Rechtecks), die y-Koordinate der linken oberen Ecke, die Breite und die Höhe mit.
Wenn ich z.B. eine Ellipse2D.Double A = new Ellipse2D.Double(1, 3, 2, 2) anlege, warum ist A.getMaxY() dann gleich 5 und A.getMinY() gleich 3? Nach meinem Verständnis wäre A.getMaxY() = 3 und A.getMinY() = 1…?
Hast du vielleicht die X- und die Y-Achse vertauscht?
Hier mal meine 1337-Paint-Sk1llz:
Sieht eher danach aus: Die y-Achse wächst nach unten, nicht nach oben, wie man es vielleicht gewohnt ist. Dementsprechend ist der Punkt mit der größten y-Koordinate der tiefste Punkt im Koordinatensystem.
Jetzt nochmal die Frage: Bei mir schlägt der 3. (und nur der 3 testcase!) immer fehl. Hat jemand ne ahnung warum? Oder ein tip worauf ich mal besonders achten sollte?
Mit welchem Ergebis schlägt er denn fehl? Ist dein errechneter Wert knapp daneben, oder kommt was völlig anderes raus? Im ersteren Fall musst du vielleicht nochmal prüfen, ob die Fläche, die du „beschießt“, auch tatsächlich die Fläche ist, die du später zur Berechnung aus den Hits und Misses hernimmst. Ganz grundsätzlich: Welche Fläche beschießt du überhaupt?
Im zweiteren Fall würde ich mir mal anschauen, wie die beiden Ellipsen im 3. Testfall im Raum zueinander liegen (ungefähr) und ob es da Abweichungen zu anderen TCs gibt (Also insbesondere die min- und max-Werte der beiden Ellipsen, falls du mit den Werten in irgendeiner Form rechnest).
Mich wundert das sowieso; bei mir hat immer entweder keiner oder gleich alle funktioniert…
Hmm er schlägt einfach vollkommen fehl…
java.lang.AssertionError: expected:<0.9645439> but was:<0.4824015516132174>
Den testcase hab ich mir auch schon angeschaut, ich sehe da nichts warum es nicht gehen sollte. Der Rahmen den ich um die Elipsen ziehe sollte auch funktionieren, funktioniert ja sonst auch immer. Ich bin zur Zeit echt ratlos =(
Demnach berechnest du für jedes Ellipsenpaar extra einen Rahmen? Schau dir vielleicht nochmal die für Ellipsen gegebenen Methoden an, du bräuchtest theoretisch gar keinen „eigenen“ Rahmen zu ziehen hint
hehe ne passt schon das mich ich glaub ich genauso wie du es gesagt hast, wusste nur nicht wie weit ich hier gehen darf mit dem Erklären der Aufgabe um nicht die Lösung zu verraten 
Zeitspanne Testcase
Hallo Leute!
Also für alle, die sich über die benötigte Zeit vom Testcase Gedanken machen: hab grad 3 Minuten gebraucht xD
Das soll jetzt kein Wettbewerb sein, aber ich glaube meine Implementierung ist ein wenig ineffizient.
Verwendest du irgendwo Math.random()? Das macht dir nämlich deine Parallelität ziemlich kaputt (siehe auch Vorgängerposts hier im Thread). Erzeuge lieber pro Thread ein eigenes Random-Objekt.
Teilst du denn die iterations einzeln auf die Threads auf? Auch das würde nämlich ziemlich lange dauern.
Bei mir dauert der Testcase insgesamt etwa 40 Sekunden.
Dito.
eigenes Random-Objekt? VERDAMMT xD danke!
Gut, hab die Random-Objekte eingefügt. TestIntersection 1-4 laufen jetzt in 40 sec.
Der Testcase mit testMultipleThreads dauert trotzdem noch ewig…
Wie gesagt, wie teilst du die Iterations auf die Threads auf bzw. woher weiß der Thread, welche Iterations „seine“ sind? wenn du alle 32 Milliarden und paar zerquetschte einzeln aufteilst, dauert das auch länger (Dass du das so machst, ist jetzt natürlich nur mal ins Blaue geraten).
Die Aufteilung ist meiner Meinung nach recht gleichmäßig. Jeder Thread muss einen Bruchteil der geforderten Punkte erzeugen. Habs auch so implementiert, dass alles ohne Rest schön aufgeht.
Hab heute die Implementierung von einer Freundin gesehn. Die lief auch auf den Uni-Rechnern 3-mal so schnell wie daheim.
Also denk ich mal wirds wohl doch der Leistung meines PCs geschuldet sein. (hoff ich zumindest)