Tool zum Matchen von Zahlen, um auf Zielwert zu kommen

Gehts hier noch weiter? Verfolge das Thema mit Spannung.

Miuwa schrieb:

So, hier der Code - der Übersichtlichkeit halber hab ich die negativen Zahlen rausgenommen, aber die waren bei den gefundenen Lösungen eh nicht dabei.

Zum Vergrößern anklicken....

Also ich finde auch Lösungen mit negativen Werten, z.B.:

@S.Kara: Ich wollte damit auch garnicht sagen, dass es keine Lösung mit negativen Zahlen gibt. Meine Aussage hat sich nur auf die von mir geposteten Lösungen bezogen.
Mein Algorithmus klopft halt erstmal die ohne ab und ich hab ihn nie lang genug rechnen lassen um bis zu den Lösungen mit negativen Zahlen zu kommen.
Davon abgesehen sind wir inzwischen so weit, dass keine Werte doppelt genutzt werden sollen.

Achso ok, dann habe ich dich falsch verstanden gehabt.
Das mit den doppelten Werten stimmt, war jetzt aber auch nicht so tragisch. Wollte ja nur zeigen, dass es auch Lösungen mit negativen Werten gibt.

SaxnPaule schrieb:

Gehts hier noch weiter? Verfolge das Thema mit Spannung.

Zum Vergrößern anklicken....

Finde im Moment leider keine Zeit dazu, melde mich aber auf jeden Fall, wenn ich es probiert habe!

Ich habe mir jetzt den letzten Teil nicht durchgelesen.
Subset sum ist schwach np vollständig
Alle Lösungen dessen auf zu zählen, besser deren Mächtigkeit zu berechnen liegt in #P.

Aufgrund der hier schon erläuterten Situation, dass das Universium dazu sehr groß ist, würde ich (um das Zählproblem zu lösen) randomisert vorgehen.

Vielleicht sollten wir nochmal darüber reden was wirklich benötigt wird.
Ich glaube nicht dass man bei einem Input wie aus Post #23 wirklich alle Kombinationen ausgegeben haben will.
Selbst wenn man dort nur die 93 eindeutigen Werte nimmt, gibt es immer noch milliarden von gütligen Kombinationen, der nötige Speicherplatz dafür liegt im TB-Bereich.

S.Kara schrieb:

Selbst wenn man dort nur die 93 eindeutigen Werte nimmt, gibt es immer noch milliarden von gütligen Kombinationen, der nötige Speicherplatz dafür liegt im TB-Bereich.

Zum Vergrößern anklicken....

Na ja, alle Kombinationen als Summe sind dann "ungefähr" 2^93 (etwas weniger) Kombinationen, die Du testen mußt. Kurzer Überschlag: mit 10 "TeraAdds" (10000 Milliarden ausgeführte komplette Additionen pro Sekunde) Rechenleistung für Vergleiche brauchst Du dann "nur" noch ~32 Millionen Jahre (wenn ich richtig geschätz habe ...). Aber nur, wenn die Daten augenblicklich im Prozessor zur Verfügung stehen

Da gibt es schon einige Optimierungen die man vornehmen kann, wie z.B. Teilsummen bilden wie im geposteten Code von Miuwa. Aber ja, 93 Werte sind einfach zu viel.

andy_m4 schrieb:

Was halt oft im Forum passiert ist, das jemand irgendwie ne Frage hinklatscht ohne sich vorher Gedanken darum zu machen die Frage möglichst präzise zu stellen und die Antworter sollen sehen, wie sie damit klar kommen.
Das ist sicherlich auch der Grund für eine "Grundgenervtheit". Und wenn da irgendwie unpräzise Fragestellungen kommen, dann kann die sich auch mal entladen.

Zum Vergrößern anklicken....

Der Grund ist eher das Mindset eines Programmierers. Wir nehmen ein definiertes Problem, zerlegen es in Teilprobleme und lösen es. Ohne definiertes Problem funktioniert das nicht, da fängt ein normaler Entwickler nicht mal an nachzudenken. Davon ab weiß jeder mit ein bisschen Kundenkontakt, wie es endet wenn man auf so einer Basis anfängt zu arbeiten: am Ende hat man eine grandios geile Lösung, nur leider nicht für das Problem des Kunden. Wer sich mit so etwas schon mal konfrontiert gesehen hat, weiß es besser als ein schwammiges Problem anzugehen. Da muss man halt bohren und bohren bis das Problem an sich klar ist, das gehört schlicht zum Entwicklungsprozess.

Das Problem des TEs ist abstrakt ausgedrückt und unklar definiert. Um das zu beheben, gibt es zwei Möglichkeiten: entweder man fragt bis es klar definiert ist, oder man ent-abstrahiert es wieder (zb 'ich habe eine Liste mit Zahlungen für Teile und einen Überweisungsbetrag ohne Verwendungszweck, ich will rausfinden welche Teile mit dem bezahlt worden sein könnten' - daraus kann man das Problem genau ableiten, weiß das Dopplungen erlaubt sind und nicht weggekürzt werden usw). Als dritte Möglichkeit gibts hier im Forum noch die Chaosvariante: jeder wirft eine Lösung hin und der TE sucht sich eine, die seinem Problem entspricht. Das ist natürlich ein enormer Overhead für ein (vielleicht) ganz simples Problem.

Ein Entwickler denkt sich nicht seinen Teil oder trifft Annahmen zu einem Problem um Unklarheiten auszubügeln, wer das schonmal gemacht hat ist ziemlich sicher auch hart damit gelandet und macht es nicht wieder. Das Mindset kommt mit dem Job, und wenn man es am Anfang noch nicht hatte wird es einem nach ein oder zwei Desastern ziemlich sicher vom Job aufgedrückt.

Aber genug offtopic

@mambokurt
Das liegt jetzt nicht unbedingt an den Entwicklern. Einfach in jedem Job, bei dem man klare Anforderungen hat, ist es hilreich, wenn einem jemand diese Anforderungen auch mitteilt.
Erzähl mal einem Architekt: "ich hätte gern irgendwie ein Haus und hab auch eine ganz genaue Vorstellung davon. Jetzt mach mal irgendwas mit Holz und Glas!" Wer sich da nicht veräppellt fühlt ist und sein Glück versucht ist selber schuld ^^

Die zwei Alternativen sind da wie folgt:
1. Es einfach sein lassen oder
2. So lange nachfragen, bis der TE selbst keine Lust mehr hat oder endlich damit rausrückt, was er haben will.

Das Schema solcher Threads ist einfach fast immer gleich und endet fast immer damit, dass hilfsbereite Menschen Arbeit reinstecken, die dann aber umsonst war. In der Regel kommt man dann noch nicht einmal ein Danke oder Ähnliches.
Ich würde mir ja auch gerne Gedanken über das Problem machen (macht manchmal ja auch Spaß), aber bisher kenne ich einfach das Problem noch nicht.