Optimierung von float - Maximale Nutzung

excelite

Mitglied
Hallo erstmal,
ich habe ein recht komplexes Problem zu lösen. Es geht um folgendes:

Ich habe verschiedene Zahlen - alle zwischen 0,0 und 100,0. Die Menge ist beliebig. Nun möchte ich gerne einen Algorithmus entwerfen, der mir diese Zahlen so gut wie möglich zusammensetzt um so nah wie möglich an 100 zu gelangen.

Zur Erklärung ein Beispiel:

40,2 - 22,4 - 4,6 - 19,65 - 53,33 - 12,22 - 19, 56 - .......

Hier würden nun folgende Werte genommen:
40,2 + 22,4 + 4,6 + 19,65 + 12,22 = 99,07

Das ist schon sehr nahe an 100. Die restlichen Zahlen ( sind natürlich noch mehr ) werden weiter verwurstet bis nachher nur noch ein kleiner Rest übrig ist. Bis also so viele 100er Pakete "voll" sind wie möglich.

Meine Idee war folgende:
Sämtliche Zahlen werde in eine Linear verkettete Liste eingetragen mit 2 Variablen. Einmal float ( dem Inhalt ) und bool ( ob die Zahl schon verwendet wurde ). Ich würde dann zuerst die größte Zahl suchen und mit einem Zufallsgenerator viele verschiedene Möglichkeiten durchprobieren. Nach dem Prinzip Try & Error. Wenn ich also auf ~3% an 100 rankomme den Generator zu stoppen und das nächste Paket zu starten.

Ich bin mir aber nicht sicher, ob das die cleverste Lösung ist und ob ich vllt. einen Denkfehler habe, oder ob ich die Sache komplett falsch anpacke. Wenn jemand einen Denkansatz für mich hat, wäre ich sehr dankbar.

Ich hoffe genug Informationen gegeben zu haben. Das ganze hat natürlich einen technischen Hintergrund, der hier aber nicht weiter von Bedeutung ist.

Grüße,
excelite
 
Zuletzt bearbeitet:
Wenn die Laufzeit keine Rolle spielt, dann ist es am sichersten, wirklich ALLE möglichen Kombinationen auszuprobieren und Dir die Kombination zu merken, die am nächsten an 100 herankommt. Es ist einfacher, wenn Du die Liste vorher aufsteigend sortierst (kleinste zuerst).
 
moin


Ich würde dann zuerst die größte Zahl suchen und mit einem Zufallsgenerator viele verschiedene Möglichkeiten durchprobieren. Nach dem Prinzip Try & Error.

Das würde ich in keinem Fall machen, da Zahlen die eigentlich Perfekt passen würden, möglicherweise nicht gefunden werden.

Aber mit der ersten anzufangen, ist glaub ich garnciht verkehrt.

Wenn ich also auf ~3% an 100 rankomme den Generator zu stoppen und das nächste Paket zu starten.
Das würde ich auch cniht machen, vielleicht ist noch irgenwo eine 3, die du dann verpasst.


mfg
umbrasaxum
 
Zuletzt bearbeitet:
Vielen Dank für die Antworten.

@ Tom
Ich bin leider der Visual Basic Sprache bzw. der Micorsoft Makro Sprache nicht mächtig. Hast du zufällig noch einen Link wo das ganze in C++ bzw. allgemein erklärt wird in peto ?


Ich weiss zwar noch nicht wie, aber am liebsten wäre es mir, ich könnte das Problem irgendwie mathematisch lösen und habe so eine ziemlich sichere Sache. Das es "perfekt" wird denke ich zwar nicht. Aber das es einen besseren Ansatz als Try & Error gibt bin ich überzeugt.

Gruß excelite
 
moin


Ohne "Try & Error" also Versuchen/Probieren, wird das nciht gehen.
Aber ich denke das sollte nciht allzu aufwendig werden, und die Laufzeit sollte sich auch in Grenzen halten.

Wieviele Werte sollen das eigentlich sein, die immer immer zu 100er Blöcken zusammengefasst werden sollen?


mfg
umbrasaxum
 
Hmm.. sagen wir so 3-10. Mehr wird es denke ich nicht. Ok, wenn die Sache nicht mathematisch lösbar ist, frage ich mal meinen Matheprofessor bzw. Informatikprofressor, ob die da evtl. eine Lösung haben.

Gruß excelite
 
moin


Also bei 10 Werten sollte es nciht allzuviele Möglichkeiten geben, ist natürlich von der größe der einzelnen Werte abhängig.


mfg
umbrasaxum
 
Bin an der Sache ein wenig weiter gekommen.

Mir ist gestern eine Idee gekommen und zwar war meine Überlegung, dass ich zuerst die max Zahl ermittle. Die von meiner Endsumme abziehe und dann suche welches am nächsten zur Differenz die noch übrig bleibt zu finden ist bei den verbleibenden Zahlen. Das wird solange gemacht, bis keine Zahl mehr verfügbar ist.

Bsp:

Summe: 6000
Größste Zahl: 4200
=> Differenz: 1800
Suche in DB: 1500 gefunden
=> Differenz 300
Suche in DB: 250 gefunden
=> Differenz 50
Suche in DB erfolglos
=> nächstes Paket

Damit habe ich bis jetzt relativ gute Erfolge erzielt. Allerdings bin ich der Meinung, dass es durchaus Problemstellen gibt bei der dann die "flaschen" Summanden zusammen gesetzt werden und somit eine "perfekte" Lösung verloren geht.

Hier ein Beispiel bei einem Versuch:
[ 982 ] [ 650 ] [ 4250 ] - Summe: 5882 - Reststück: 118 - Reststück in Prozent: 1.9666666666667 %
[ 982 ] [ 650 ] [ 4250 ] - Summe: 5882 - Reststück: 118 - Reststück in Prozent: 1.9666666666667 %
[ 982 ] [ 4250 ] [ 650 ] - Summe: 5882 - Reststück: 118 - Reststück in Prozent: 1.9666666666667 %
[ 4239 ] [ 982 ] [ 650 ] - Summe: 5871 - Reststück: 129 - Reststück in Prozent: 2.15 %
[ 4239 ] [ 982 ] [ 650 ] - Summe: 5871 - Reststück: 129 - Reststück in Prozent: 2.15 %
[ 4239 ] [ 982 ] [ 550 ] - Summe: 5771 - Reststück: 229 - Reststück in Prozent: 3.8166666666667 %
[ 920 ] [ 2521 ] [ 2521 ] - Summe: 5962 - Reststück: 38 - Reststück in Prozent: 0.63333333333333 %
[ 982 ] [ 229 ] [ 2521 ] [ 2250 ] - Summe: 5982 - Reststück: 18 - Reststück in Prozent: 0.3 %
[ 982 ] [ 2250 ] [ 2250 ] [ 350 ] - Summe: 5832 - Reststück: 168 - Reststück in Prozent: 2.8 %
[ 982 ] [ 2244 ] [ 2244 ] [ 350 ] - Summe: 5820 - Reststück: 180 - Reststück in Prozent: 3 %
[ 982 ] [ 2244 ] [ 2150 ] [ 550 ] - Summe: 5926 - Reststück: 74 - Reststück in Prozent: 1.2333333333333 %
[ 982 ] [ 2150 ] [ 2150 ] [ 550 ] - Summe: 5832 - Reststück: 168 - Reststück in Prozent: 2.8 %
[ 982 ] [ 2150 ] [ 2150 ] [ 250 ] [ 350 ] - Summe: 5882 - Reststück: 118 - Reststück in Prozent: 1.9666666666667 %
[ 982 ] [ 2150 ] [ 2150 ] [ 250 ] [ 250 ] - Summe: 5782 - Reststück: 218 - Reststück in Prozent: 3.6333333333333 %
[ 982 ] [ 2150 ] [ 2150 ] [ 250 ] [ 250 ] - Summe: 5782 - Reststück: 218 - Reststück in Prozent: 3.6333333333333 %
[ 982 ] [ 229 ] [ 229 ] [ 2150 ] [ 2150 ] [ 250 ] - Summe: 5990 - Reststück: 10 - Reststück in Prozent: 0.16666666666667 %
[ 2150 ] [ 2150 ] - Summe: 4300 - Reststück: 1700 - Reststück in Prozent: 28.333333333333 %
[ 2150 ] [ 2150 ] - Summe: 4300 - Reststück: 1700 - Reststück in Prozent: 28.333333333333 %
[ 2150 ] [ 2150 ] - Summe: 4300 - Reststück: 1700 - Reststück in Prozent: 28.333333333333 %
[ 2150 ] [ 2150 ] - Summe: 4300 - Reststück: 1700 - Reststück in Prozent: 28.333333333333 %
[ 2150 ] [ 2150 ] - Summe: 4300 - Reststück: 1700 - Reststück in Prozent: 28.333333333333 %
[ 2129 ] [ 2150 ] - Summe: 4279 - Reststück: 1721 - Reststück in Prozent: 28.683333333333 %
[ 2129 ] [ 2129 ] - Summe: 4258 - Reststück: 1742 - Reststück in Prozent: 29.033333333333 %


Wie gesagt, relativ gute Erfolge jedoch zum Ende hin ~30% Abfall. Das ist denke ich durch andere Anordnung besser lösbar. Aber noch nicht optimal. Falls noch jemand eine Idee für die Verfeinerung hat wäre ich sehr dankbar !

Grüße excelite
 
Hallo!

Wäre die Optimale Lösung für das erste Beispiel nicht:
40,2 - 22,4 - 4,6 - 19,65 - 53,33 - 12,22 - 19, 56 - ....... -> 100

22.4 + 4.6 + 19.65 + 53.33 = 99.98 ?

Hast du vielleicht noch ein größeres "offizielles" Beispiel parat mit dem man eine "eventuell" *g* vorhandene Lösung verifizieren könnte?

Gruß Tom
 
Zurück