[Algemeen] efficiënt sorteren / combineren

[Daggie]

Probleem komt hier op neer :

Je hebt een pot (vaste inhoud)
Je hebt grote en kleine knikkers

Hoe krijg je zo efficiënt mogelijk (zo veel mogelijk ruimte van de pot benutten) de pot vol met kleine en grote knikkers.

Lijkt mij een probleem dat waarschijnlijk wel vaak voorkomt bij proggen ...

--
Ik sorteer momenteel de knikkers op grootte van groot->klein

en dacht dan eerst de grootste in de pot te stoppen en dan sequentieel te kijken of de (grootste-1) er nog bij kon.


Op die manier geraakt de pot gevuld tot "Max_pot" (pot vol) maar moeten alle knikkers wel sequentieel doorlopen worden.

Zijn er hier snellere algorithmen voor ?


edit : misschien is het ook nuttig om 2 manieren naast elkaar te plaatsen, 1 voor combinaties grootste-2e grootste (die past) en 1 voor combinatie grootste-kleinste ...

[Alarmnummer]

Een oplossing die zeker werkt, maar die denk ik het langste duurt is backtracking (je zou eventueel wel optimalisaties kunnen toepassen binnen het algoritme). Als je niet weet wat het is moet je het ff opzoeken, maar dit kan je hier goed op toepassen. En je kan hiermee garanderen dat je de optimale combinatie gaat vinden.

[LordLarry]

Het oplossen van dit soort vraagstukken duurt enorm lang als je alle mogelijkheden wilt nalopen en de beste eruit wilt kiezen. Echt snellere methodes bestaan er bij mijn weten niet. Ook backtracking niet, IMHO, omdat je altijd alle combinties moet nagaan. Er is er geen 1 waarvan je weet dat die het beste is. Behalve als ie precies vol is, maar die kans is erg klein.

Er zijn wel algoritmes die een bepaalde tijdsduur nemen en dan de best mogelijke oplossing geven. Die zorgen er dan voor dat je wel vrij snel dicht in de buurt komt van een redelijk juiste oplossing. Het salesmen probleem valt hier ook onder. In welke volgorde moeten de steden aangedaan worden om de kortst mogelijke route te krijgen.

[Alarmnummer]

Je kan eventueel wel optimalisaties uit voeren op het backtracken. Je zou de knikkers per grote kunnen sorteren, en daardoor hoef je een groot aantal combinaties niet opnieuw te maken. Dit kan enorme besparingen opleveren.

[Pooh]

Heb je het hier over 3-dimensionale knikkers? Volgens mij valt daar echt met geen mogelijkheid aan te rekenen als ze niet gelijk van grootte zijn. 'k Heb ooit het wiskundig bewijs van de massiefste bolstapeling met bollen van gelijke grootte doorgewerkt, en dat is al een enorm rotwerk.

[Daggie]

backtracken is mij onbekend en ook MSDN maakt mij weinig wijzer ... maar ik zoek verder

de knikkers zijn momenteel reeds gesorteerd op grootte dus dat kan wel handig zijn

maar ik ga verder uitzoeken wat backtracking is

edit : het gaat eigenlijk niet over knikkers, maar is zo wel veel makkelijker uit te leggen, het gaat over lengtes combineren tot maxlengte bekomen is (vb 1 touw van 5 meter, 1 touw van 20 meter, beide zelfde diameter op een machine waar 30 meter touw kan op gemaakt worden). De bol-vorm zelf speelt dus iig geen rol.

[Verwijderd]

binary sort gaat sneller dan een 'gewone' sort

[Dash2in1]

Verwijderd schreef op 09 september 2002 @ 13:49:
binary sort gaat sneller dan een 'gewone' sort

Mjah, dat hangt er vanaf, over hoeveel knikkers gaat het..?

[Dash2in1]

Daggie schreef op 09 september 2002 @ 13:12:
backtracken is mij onbekend en ook MSDN maakt mij weinig wijzer ... maar ik zoek verder

de knikkers zijn momenteel reeds gesorteerd op grootte dus dat kan wel handig zijn

maar ik ga verder uitzoeken wat backtracking is

Misschien dat deze site je wat verder helpt .. m.b.t. backtracking
http://cbl.leeds.ac.uk/~tamsin/prologtutorial/search.html (google helpt best)

[Janoz]

backtracking is niet 1 of andere methode in 1 of andere api. Waarschijnlijk heb je dus meer geluk waneer je bij google zoekt. Besef wel dat dit niet een simpel probleem is, en het komt ook niet 'vaak voor bij het proggen'. Waar je dit soort problemen wel tegenkomt (maar dan vqaak in versimpelde vorm) is tijdens een informatica opleiding ..

Ik denk trouwens niet dat het sorteren van de knikkers veel uitmaakt. Er is niet een bepaalde volgorde van omvang die er voor zorgt dat je een ideale oplossing krijgt.

[bluewarlord]

Er is ook nog een stapel probleem met je probleem, een bepaalde stapeling van knikkers kan ruimte besparen omdat ze rond zijn ...... en dan kom je al snel op een heerlijk wiskundig probleempje ... (waar tot op heden nog geen echte universele oplossingen voor zijn)

[bluewarlord]

Als je niet precies de meest optimale oplossing hoeft te hebben en aannemende dat je geen stapelprobleem hebt (m.a.w. kubus achtige knikkers), dan kun je ook een genetisch algoritme proberen, die zijn over het algemeen het snelst met dit soort zaken. Maar er is GEEN garantie dat je de meest optimale vindt

[Verwijderd]

Mjah, dat hangt er vanaf, over hoeveel knikkers gaat het..?

volgens mij niet . . .binary sort heeft domweg minder vergelijkingen nodig . . dan een 'gewone' sort

[Verwijderd]

Doe een google op knapsack problem en zie waarom dat er geen optimale oplossing voor dit probleem bestaat (het is NP-Compleet).

[Janoz]

Verwijderd schreef op 09 september 2002 @ 14:11:
[...]


volgens mij niet . . .binary sort heeft domweg minder vergelijkingen nodig . . dan een 'gewone' sort

Dat ligt er helemaal aan wat jij onder een 'normale' sort verstaat

[Pooh]

Daggie schreef op 09 september 2002 @ 13:12:
backtracken is mij onbekend en ook MSDN maakt mij weinig wijzer ... maar ik zoek verder

de knikkers zijn momenteel reeds gesorteerd op grootte dus dat kan wel handig zijn

maar ik ga verder uitzoeken wat backtracking is

edit : het gaat eigenlijk niet over knikkers, maar is zo wel veel makkelijker uit te leggen, het gaat over lengtes combineren tot maxlengte bekomen is (vb 1 touw van 5 meter, 1 touw van 20 meter, beide zelfde diameter op een machine waar 30 meter touw kan op gemaakt worden). De bol-vorm zelf speelt dus iig geen rol.

Ow, gelukkig. 3d-stapelingen wil je echt niet met de computer optimaliseren: ja pleurt gewoon een stel knikkers in een bak, schudt ze een half dagje en je zit aardig aan 't optimum.

Vouw probleem heb ik eerder gezien. 'k Zal eens zoeken... maar volgens mij is 't zuiver NP, en kom je er dus nooit echt uit.

[Verwijderd]

Poohbear schreef op 09 september 2002 @ 14:34:
Vouw probleem heb ik eerder gezien. 'k Zal eens zoeken... maar volgens mij is 't zuiver NP, en kom je er dus nooit echt uit.

/me zucht: waarom post ik eigenlijk nog?

Het probleem heet het knapsack problem en het is zelfs NPC.

[dusty]

Janoz schreef op 09 september 2002 @ 14:20:
[nohtml]
[...]
[/nohtml]
Dat ligt er helemaal aan wat jij onder een 'normale' sort verstaat

En wat je aan het sorteren bent

[Pooh]

Verwijderd schreef op 09 september 2002 @ 14:37:
[...]


/me zucht: waarom post ik eigenlijk nog?

Het probleem heet het knapsack problem en het is zelfs NPC.

Sorry... Had reactie al hele tijd geleden getyped, maar toen hield GoT er zomaar mee op... Daarna weggelopen, teruggelopen en op 'send' geduwd... mijn nederige excuses voor het feit dat ik niet eerst gerefreshed heb, en dus de reacties die voor mij geplaatst waren niet gelezen heb.

[xoror]

wij hebben voor ganz spel ook een soortgelijk probeem opgelost.

Je kunt het indelen van die kleine en grote knikkers vergelijken met plannen van roosters. De meest optimale rooster zoeken kost veel tijd. Wij hebben gebruik gemaakt van B&B.

We hebben voorbeeld source code op het web staan + documentatie.
ik denk dat je er wel wat aan heb : check http://wwwhome.cs.utwente.nl/~knoppel/ultrakoeien/
en klik op programmers allocation.

offtopic:
wie weet waar die oplichters van ganz.nl heen zijn gegaan

[Verwijderd]

pooh>> sorry dat ik een beetje uit de slof schoot, was niet zo bedoeld. Wat me wel benieuwt is hoe mensen dit met sorteren willen oplossen

[Daggie]

Knapsack-probleem dus

Had ik nog nooit van gehoord, maar dat is inderdaad het probleem
maw een meest optimale bezetting van de machine (de pot of de rugzak) is onmogelijk ...

In dat geval ga ik eerst mijn opdrachtgever contacteren. Momenteel werd dit manueel uitgerekend, maar ik weet niet of "in de buurt van optimaal" goed genoeg is.

Dit lijkt mij overigens wel heel interessant probleem om van naderbij te bekijken.

edit = xoror : HEEL erg bedankt voor die link !

[Pooh]

Verwijderd schreef op 09 september 2002 @ 14:51:
pooh>> sorry dat ik een beetje uit de slof schoot, was niet zo bedoeld. Wat me wel benieuwt is hoe mensen dit met sorteren willen oplossen

Bij 1 knapsack werkt sorteren niet, maar bij "oneindig" veel zooi in "oneindig" veel knapsacks is sorteren niet eens zo'n slechte oplossing. (Zeker geen optimale, maar wel snel, en zeker een oplossing opleverend binnen een bepaalde tijd)

[xoror]

Daggie schreef op 09 september 2002 @ 14:54:
Knapsack-probleem dus

Had ik nog nooit van gehoord, maar dat is inderdaad het probleem
maw een meest optimale bezetting van de machine (de pot of de rugzak) is onmogelijk ...

In dat geval ga ik eerst mijn opdrachtgever contacteren. Momenteel werd dit manueel uitgerekend, maar ik weet niet of "in de buurt van optimaal" goed genoeg is.

Dit lijkt mij overigens wel heel interessant probleem om van naderbij te bekijken.

check mijn message. Een oplossing zoeken die optimaal is duurt heel lang (bij een beetje dataset). maar er zijn veel algos om een 'redelijke verdeling binnen een redelijke tijd' te krijgen

[LordLarry]

Verwijderd schreef op 09 september 2002 @ 14:37:
[...]


/me zucht: waarom post ik eigenlijk nog?

Het probleem heet het knapsack problem en het is zelfs NPC.

Dat zei ik dus al in post 2

[Verwijderd]

LordLarry schreef op 09 september 2002 @ 15:01:
Dat zei ik dus al in post 2

Hehehe Alle NPC problemen zijn in wezen één probleem, want als je één NPC probleem oplost heb je essentieel de oplossing voor ze allemaal. Toch worden de NPC problemen apart benoemd en daarom is dit geen TSP (travelling salesman problem) maar wel degelijk een knapsack problem.

[Daggie]

xoror (of iemand anders) : zou je hierover mij kunnen persoonlijk info geven, want ik vrees dat dit (met mijn kennis momenteel,2e jaar toegepaste info) te hoog gegrepen is ... Ik heb je toelichting bekeken en voelde mij met de regel kleiner worden ...

[Soultaker]

Een typisch geval van een lineair optimalisatieprobleem. Ik weet niet precies welke eisen er aan de oplossing gesteld worden, maar evnetueel zou je eens een programmeertaa/executieomgeving als LINDO/LINGO kunnen kijken, dan krijg je alle algoritmen voor het oplossen naar gehele waarden (door middel van branch-and-bound bijvoorbeeld) al kado. Eventueel zou je ook zelf een algoritme op basis van branch-and-bound kunnen schrijven, maar dat vereist wel wat research.

Dit is trouwens een vrij 'simpele' variant op 't algemene knapsack probleem (de waarde van de knikker is gelijk aan zijn 'gewicht') dus het zou me niets verbazen als er een veel simpelere oplossing is. Het vervelende van het probleem lineair benaderen en vervolgens met branch-en-bound de 'gehele' oplossing vinden, is dat de executieduur per geval sterk kan verschillen.

[Daggie]

http://magma.maths.usyd.edu.au/magma/Examples/node7.html

Dit lijkt mij een eenvoudige oplossing

http://www.diku.dk/~pisinger/codes

staan meerdere oplossingen

Het gaat vooral over een beperkt aantal "knikkers", dus de executieduur zal normaal gezien niet "te" lang worden. Ik denk dat ik optie #1 eens ga proberen implementeren en zien hoe ver dat mij brengt.

[MisterE]

Dit is dus eigenlijk een beetje hetzelfde probleem van een programma dat moet proberen de cd zo vol mogelijk moet zie te maken?
Daarbij kan je ook niet zeggen van neem eerst alle grote bestanden, en als die niet meer passen dan neem een kleiner bestand.

Lijkt me idd vrij lastig voor sooftware om de idd files bij elkaar te vinden

[Juup]

[b][message=15082129,noline]Daggie schreef op 09 september 2002 @ het gaat eigenlijk niet over knikkers, maar is zo wel veel makkelijker uit te leggen, het gaat over lengtes combineren tot maxlengte bekomen is (vb 1 touw van 5 meter, 1 touw van 20 meter, beide zelfde diameter op een machine waar 30 meter touw kan op gemaakt worden).

Kun je het probleem nog een keer (volledig) uitleggen? Heb je 1 'machine' of meerdere? En wat is het DOEL?

[Zoijar]

Een redelijk en veel gebruikt algrotime is om eerst de grootste te fitten, en dan de kleintjes. Vergelijk het idd met een pot knikkers, door er een aantal groten in the doen hou je veel kleine gaten over, die je dan met kleintjes op kan vullen.

En wie zegt dat NPC problemen niet redelijk snel (optimaal) opgelost kunnen worden? Geen enkel bewijs voor die stelling hoor hehehe

[Ericston]

xoror schreef op 09 september 2002 @ 14:50:
[...]

offtopic:
wie weet waar die oplichters van ganz.nl heen zijn gegaan

offtopic:
Ik weet dat een zekere eend altijd naar Timboektoe of Verweggistan vertrekt, maarja, bij biologie leerde ik dat ganzen in de zomer altijd naar het noorden gaan...

Klinkt meer als een zaak voor Breekijzer. ( Of Opsporing Verzocht. )

[Knutselsmurf]

Zoijar schreef op 09 september 2002 @ 22:08:
Een redelijk en veel gebruikt algrotime is om eerst de grootste te fitten, en dan de kleintjes. Vergelijk het idd met een pot knikkers, door er een aantal groten in the doen hou je veel kleine gaten over, die je dan met kleintjes op kan vullen.

En wie zegt dat NPC problemen niet redelijk snel (optimaal) opgelost kunnen worden? Geen enkel bewijs voor die stelling hoor hehehe

Als jij het omgekeerde kan bewijzen wordt je rijk en beroemd...

[Zoijar]

Ik zou ook beroemd worden als ik deze stelling kan bewijzen. Misschien iets minder rijk omdat ik niet meteen alle banken en credit cards ed. op de hele wereld kan kraken. Jammer dat er geen nobel prijs voor de wiskunde is Maar met het bewijs van de eeuw op m'n naam zou je toch een leuke baan moeten kunnen vinden hehe

[Daggie]

@ Jaaap

er zijn meerdere machines, maar het probleem moet per machine worden apart gebruikt, dus 1 machine tegelijk

klant 1 geeft vandaag order voor 100 meter touw 48 mm
klant 2 geeft morgen order voor 200 meter touw 48 mm

aangezien de diameter dezelfde is, kan het in 1 "trek" worden gemaakt (zonder dat de machine instellingen moeten aangepast worden, dit is nl. heel tijdrovend werk)

het programma moet uitrekenen hoe de verschillende orders best kunnen gecombinerd worden, de machine kan een max_lengte maken die niet mag overschreden worden

-----------

Zou de solver van excell oplossing kunnen bieden (macro maken) ?

[RickN]

Ik sta nu op het punt om mijn informatica opleiding af te ronden en heb altijd een bovengemiddelde intresse gehad in algoritmeleer en datastructuren, maar WTF is in godsnaam een "binary sort"

[Pooh]

RickN schreef op 10 september 2002 @ 10:15:
Ik sta nu op het punt om mijn informatica opleiding af te ronden en heb altijd een bovengemiddelde intresse gehad in algoritmeleer en datastructuren, maar WTF is in godsnaam een "binary sort"

Gewoon een soort insertion sort waarbij een binary-search wordt gebruikt dacht ik.

Hmm... wat zoekwerk levert zowel bovenstaande op, als een database-achtige "binary sort", waarmee bedoeld wordt dat de data niet alphanumeriek, maar gewoon binair gesorteerd wordt. (snelheidswinst).

[RickN]

Poohbear schreef op 10 september 2002 @ 10:18:
[...]


Gewoon een soort insertion sort waarbij een binary-search wordt gebruikt dacht ik.

Hmm... wat zoekwerk levert zowel bovenstaande op, als een database-achtige "binary sort", waarmee bedoeld wordt dat de data niet alphanumeriek, maar gewoon binair gesorteerd wordt. (snelheidswinst).

Ja, ik had ook al gezocht en ook die twee resultaten gevonden. Maar goed, alphanumeriek vs binair is natuurlijk geen sorteer methode, maar gewoon een implementatie keuze. En die binary insertion sort is een variant op insertion sort die absoluut geen eigen naam heeft (anders dan binary insertion sort) of verdient. Kortom, "binary sort" bestaat gewoon niet. Ik vond het gewoon grappig om te zien dat niemand daar nog over was gevallen.

[curry684]

Daggie schreef op 09 september 2002 @ 14:54:
In dat geval ga ik eerst mijn opdrachtgever contacteren. Momenteel werd dit manueel uitgerekend, maar ik weet niet of "in de buurt van optimaal" goed genoeg is.

Ik weet niet in welke orde van grootte je dataset is die je op deze manier moet behandelen, maar als ie normaliter door een mens handmatig wordt gedaan kan een hedendaagse CPU nog steeds binnen een paar seconden op basis van brute force alle mogelijkheden proberen.

Dit zou ik trouwens niet met backtracking aanpakken maar met 'survival of the fittest' denk ik... dan genereer je bruut 100 verschillende legale combinaties, en uit de 50 beste combineer je 50 nieuwe, waarna je weer uit de beste 50 van de 100 gaat combineren etc. etc. etc. totdat je a) een ultieme oplossing bereikt of b) een vooraf gedefinieerd aantal stappen hebt bereikt. Overigens is dit afhankelijk van je dataset...

[Verwijderd]

Poohbear schreef op 09 september 2002 @ 14:34:
[...]


Ow, gelukkig. 3d-stapelingen wil je echt niet met de computer optimaliseren: ja pleurt gewoon een stel knikkers in een bak, schudt ze een half dagje en je zit aardig aan 't optimum.

Vouw probleem heb ik eerder gezien. 'k Zal eens zoeken... maar volgens mij is 't zuiver NP, en kom je er dus nooit echt uit.

Als dat zou zijn dan kun je vrolijk beginnen te sorteren met de kleinste knikkers onderaan want daar heb ik ooit eens onderzoek naar gedaan bij theoretische natuurkunde. Kleine ballen hebben de neiging om bij schudden een neerwaartse stroom te veroorzaken. Na een tijd zullen alle kleine ballen onderin de bak zijn. Schud je daarna echter nog een tijd door dan zie je dat de kleine ballen via de buitenrand weer omhoog komen en zich bovenaan naar het midden bewegen.

Welke situatie je als optimum kunt zien is uit deze 'flow' niet af te leiden. De beweging van de kleinste ballen komt puur door het feite dat deze zich makkelijker door kleine ruimtes kunnen bewegen.

[Daggie]

Net gesprek gehad met opdrachtgever

Hij zei dat er in praktijk max 5 orders kunnen gecombineerd worden, dus max 5 knikkers en van alle combinaties de som nemen

Ik denk dat ik dus simpel weg, alle mogelijke combinatie van die van die 5 ga nemen (2^5) en hieruit dan degene dichtst bij max_lengte "kiezen"

Ik had volgend stuk code geïmplementeerd in VB6, maar hij neemt de som van alle elementen van de array ...

code:

Option Base 1


    Sub main()
    thearray = Array(200, 220, 150, 100, 50)
    lngDesiredTotal = 500        'or whatever
    ctElements = UBound(thearray)
    For xCombination = 1 To (2 ^ (ctElements + 1) - 1)
        lngRunningSum = 0        'reset the running sum
        For xDigit = 1 To ctElements  'each element correspondsto a binary digit
            If xCombination And 2 ^ xDigit > 0 Then
                'this element is in the combination
                lngRunningSum = lngRunningSum + thearray(xDigit)
            End If
        Next
        If lngRunningSum = lngDesiredTotal Then
            'we have found a matching combination
        End If
    Next
End Sub

[Verwijderd]

Dit soort problemen zijn zeer complex en vrijwel on oplosbaar. Jouw probleem is vergelijkbaar met een algoritme om te bereken hoe een vrachtwagen op de meest efficiente manier gevuld kan worden met verschillende formaten dozen.

Geloof mij, als je de oplossing zou kunnen vinden voor een dergelijk probleem ben je in 1 klap stinkend rijk.

Je kunt er voor kiezen om benaderingen uit te kiezen. (Genoegen nemen met een redelijke oplossing). Ik geloof dat ze dit probleem in de Nederlandse wiskunde ook wel het 'tegeltjes probleem' noemen...

Ik heb nog wel een algoritme liggen voor het zo (bij benadering) zo efficient mogelijk vullen van een 2d ruimte met vlakken (ook 2d). Als je daar in geinterresseerd bent kun je me eventueel mailen... (zie profile).

[Daggie]

razor_harm : had ik heel graag gehad, maar je adres in profile is fout (beweerd eudora), ik heb je toegevoegd op ICQ ook, dus ik hoor je wel als je online komt. Alvast bedankt voor de moeite !

[Pooh]

Verwijderd schreef op 11 september 2002 @ 13:15:
Dit soort problemen zijn zeer complex en vrijwel on oplosbaar. Jouw probleem is vergelijkbaar met een algoritme om te bereken hoe een vrachtwagen op de meest efficiente manier gevuld kan worden met verschillende formaten dozen.

Geloof mij, als je de oplossing zou kunnen vinden voor een dergelijk probleem ben je in 1 klap stinkend rijk.

Je kunt er voor kiezen om benaderingen uit te kiezen. (Genoegen nemen met een redelijke oplossing). Ik geloof dat ze dit probleem in de Nederlandse wiskunde ook wel het 'tegeltjes probleem' noemen...

Ik heb nog wel een algoritme liggen voor het zo (bij benadering) zo efficient mogelijk vullen van een 2d ruimte met vlakken (ook 2d). Als je daar in geinterresseerd bent kun je me eventueel mailen... (zie profile).

Je zou ook eerst de draad kunnen lezen.

[Verwijderd]

Poohbear schreef op 11 september 2002 @ 14:02:
[...]


Je zou ook eerst de draad kunnen lezen.

Verklaar u nader?

[Pooh]

Verwijderd schreef op 12 september 2002 @ 11:44:
[...]

Verklaar u nader?

Niets van wat je zegt (behalve je benamingen en het aanbod voor een algoritme) is niet al eerder in de draad genoemd. Bovendien is het probleem van de topicstarter wel op te lossen, namelijk door brute-forcen.

[Verwijderd]

Poohbear schreef op 12 september 2002 @ 12:28:
[...]


Niets van wat je zegt (behalve je benamingen en het aanbod voor een algoritme) is niet al eerder in de draad genoemd. Bovendien is het probleem van de topicstarter wel op te lossen, namelijk door brute-forcen.

Okay dan... Sorry voor mijn misplaatste en lompe posting...!

[Daggie]

razor_harm : je mag agloritme wel nog altijd mailen naar [e-mail]

poohbear : brute forcen ?

[Pooh]

Daggie schreef op 13 september 2002 @ 11:40:
razor_harm : je mag agloritme wel nog altijd mailen naar [e-mail]

poohbear : brute forcen ?

Ik denk dat ik dus simpel weg, alle mogelijke combinatie van die van die 5 ga nemen (2^5) en hieruit dan degene dichtst bij max_lengte "kiezen"

Dat stelt toch niks voor? 2^5 = 32...

[curry684]

Poohbear schreef op 13 september 2002 @ 11:55:
Dat stelt toch niks voor? 2^5 = 32...

Brute force gaat hier wel op faculteit overigens, dus 5*4*3*2*1 = 120 mogelijkheden. Nog steeds peanuts voor een beetje processor

[Daggie]

I see

maar hoe neem ik van een array met 5 elementen dan alle mogelijke combinaties en stokeer ik deze in een nieuwe array (met 120 elementen dan) ?

Dat was ik aan het proberen eigenlijk, maar het lukt me niet ...
De array met 120 elementen vergelijken met de max_lengte is niet moeilijk, maar ik slaag er dus echt niet in om die 120 combinaties (de som van de combos) te bepalen ...