Dann kommt das hier raus:
GoldenSearch 0: solutionSequential: -1.0 result: 0.0und das assert bricht ab
Mein Code funktioniert, trotzdem eine Nachfrage zu einem Aspekt beim ThreadedGoldenSearch:
Die ursprüngliche Idee war, den Threads eine Referenz auf ein Double-Array mitzugeben, wo sie dann die Lösung eintragen sollen.
Allerdings könnte diese Eintragung für den Hauptthread unsichtbar bleiben, richtig?
Es reicht auch nicht, das Array volatile zu machen, weil dadurch ja nicht die einzelne Double-Werte volatile werden, richtig?
Also muss man hier eine kreativere Lösung finden (es gibt ja kein AtomicDoubleArray), richtig?
Oder mache ich mir hier unnötig Sorgen?
Dann ist in deinem Code noch ein anderer Fehler. Geh doch mal in eine Rechnerübung, da sollte dir geholfen werden.
Ach ja: b kann nur für die erste Iteration als Mitte zwischen left und right gewählt werden, danach wird es vom Wikipedia-Code ja als Teilung im Goldenen Schnitt berechnet.
join() sorgt für Sichtbarkeits- und Datensynchronisation.
Ein join würde das mit der Sichtbarkeit im Hauptthread erledigen ;).
okay, danke!
Eigentlich kann es 1-n Threads geben ;), je nachdem was der Funktion übergeben wird.
Ich mach mal ein paar gültige Aufteilungen (gibt da auch mehr Möglichkeiten ;)):
Bei 4 Threads und 6 Funktionen bearbeiten Thread-0 und Thread-1 jeweils 2 Funktionen und Thread-2 und Thread-3 jeweils eine Funktion.
Bei 4 Threads und 15 Funktionen bearbeiten Thread-0, Thread-1, Thread-2 jeweils 3 Funktionen, Thread-3 bearbeitet 6 Funktionen.
Bei 4 Threads und 15 Funktionen bearbeiten Thread-0, Thread-1, Thread-2 jeweils 4 Funktionen, Thread-3 bearbeitet 3 Funktionen.
Bei 4 Threads und 17 Funktionen bearbeiten Thread-0, Thread-1, Thread-2 jeweils 4 Funktionen, Thread-3 bearbeitet 5 Funktionen.
Bei 8 Threads und 6 Funktionen bearbeiten Thread-0, Thread-1…Thread-5 jeweils eine Funktion, Thread-6 und Thread-7 gar keine Funktion.
edit:
Generell macht ein Thread höchstens „Threadanzahl-1“ mehr als der Rest, aber mindestens eine Funktion so lange welche vorhanden sind.
Man kann das auch besser aufteilen ;).
das wäre jetzt meine ausgabe:
GoldenSearch 0: solutionSequential: -1.0 result: -0.9999999999534882
GoldenSearch 1: solutionSequential: 0.0 result: 0.0
GoldenSearch 2: solutionSequential: 1.0 result: 0.9999999950000524
GoldenSearch 3: solutionSequential: 2.0 result: 1.9999999992771589
GoldenSearch 4: solutionSequential: 2.0 result: 1.9999999952463003
GoldenSearch 5: solutionSequential: -5.0 result: -5.000000024953371bin mir nicht sicher ob das nun richtig oder falsch ist.
die ergebnisse liegen offensichtlich im faktor EPSILON, aber muss nich das exakte solutionSequential rauskommen?
Da kann gar nicht das exakte Ergebnis rauskommen, da du dich nur an das exakte Ergebnis annaeherst. Das kannst du dir so vorstellen, wie wenn du vor einer Wand stehst und du mit jedem Schritt die Entfernung zur Wand halbierst. Du wirst beliebig nah an die Wand herankommen, sie aber nie beruehren (solange du deinen Arm nicht austreckst).
jo das hab ich mir auch gedacht, dachte nur vlt. dass solutionSequential schon das angenäherte Ergebnis ist;)
Kann gar nicht?
Und wenn ich stolpere und mir die Nase quetsche? „Nur annähern“ kann durch Rundungsfehler im Allgemeinen auch exakte Ergebnisse liefern, solange diese Zahlen als Gleitkomma/Dezimalcodierung/Integer/WelcherDatenTypAuchImmer exakt dargestellt werden können. Genauso kann „nur annähern“ im Allgemeinen über das Ergebnis drüber springen.
Gut, daran habe ich nicht gedacht…
Duerfen wir einen ExecutorPool verwenden? Aehnlich wie in der FibonacciService damals. Oder gibts da Probleme?
edit: Derp, haette ich mal weiter als zur b) gelesen… d.h. explizite Threads bei b), ExecutorPool bei c). Macht Sinn.
Hallo 
wie waere es, wenn die #threads/laenge des arrays nicht teilbar ist? soll die letzte Bearbeitung sequentiell bearbeitet?
Habe die c) so verstanden, dass ich für jede funktion ein eigenes Callable Object brauche,
dabei fliegt mir die testGoldenTaskedLarge um die Ohren, mit folgendem Fehler:
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:713)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:132)
at TaskedGoldenSearch.findMinimum(TaskedGoldenSearch.java:11)
at GoldenSearchTest.testGoldenTaskedLarge(GoldenSearchTest.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)habe das ganze allerdings nicht im cip laufen lassen, ist das ein Fehler im programm oder fehlt mir einfach der speicher?
Ein eigenes Callable ist schon richtig. Der Fehler scheint aber eher auszusagen, dann du versuchst für jede Funktion auch einen eigenen Thread zu starten. Das solltest du vermeiden 
Dann bearbeitet eben nicht jeder Thread gleich viele Funktionen, sondern beispielsweise der letzte Thread ein paar mehr. Sollten es mehr Threads als Funktionen sein, solltest du die Threadanzahl auf die Anzahl der Funktionen reduzieren. Leerlaufende Threads werden nicht benötigt.
Bezieht sich der Satz [quote]Hinweis: Die Default-Konstruktoren der implementierten Klassen sollten keine Parameter benötigen.[/quote] auch auf innere Klassen (für die Threads z.B.)?
Nein das bedeutet nur, dass die öffentlichen Klassen, die auch durch den Tescase getestet werden ohne Paramter erstellt werden können sollten. Wie viele Parameter deine inneren Klassen haben, ist egal. Gerade die Threads brauchen ja oftmals einige Paramter.
Sagt mal, wie schnell ist denn bei euch der testGoldenTaskedLarge() im Vergleich zu den anderen? Bei mir braucht der 18 mal so lang wie der testGoldenThreadedLarge().
Oder sollen wir das dabei lernen?
Im Schnitt braucht testGoldenTaskedLarge() 1,5-2 Mal so lange wie testGoldenThreadedLarge() bei mir.
Ist aber wahrscheinlich nicht wirklich aussagekräftig, da so viele Faktoren mit reinspielen.
Gerade bei mir getestet:
.296s insgesamt, davon .115s testGoldenThreadedLarge und .171s testGoldenTaskedLarge, der Rest zwischen .004 und .000s. Wäre also ein Faktor von 40+.
(Edit) Oh, verlesen, dachte du meintest verglichen mit den restlichen Methoden. Wäre dann bei mir auch grob ein Faktor 1.5.