12.5.1 Optimeringsalternativ 1
Det ¨ar n stycken olika IDK:er som ska kontrolleras p˚a n stycken olika tid- punkter. Dessa tv˚a ger tidskomplexitet O(n2).
12.5.2 Optimeringsalternativ 2
Att kontrollera n stycken IDK en specifik tidpunkt tar O(n). Sedan kon- trolleras blockens slutpunkt vilket tar O(n). Dessa tv˚a upprepas sedan n g˚anger vilket totalt ger tidskomplexitet O(n3). Detta upprepas n g˚anger tills
alla block ¨ar placerade vilket ger slutliga tidkomplexiteten O(n4). 12.5.3 Optimeringsalternativ 3
Loopa alla IDK:er f¨or alla tidpunkter inom ¨onskat tidsintervall f¨or att veta antalet tidpunkter varje block anv¨ander. Addera de m¨ojliga kombinationer- nas anv¨anda tidpunkter. Loopa n IDK och n tidpunkter ger tidskomplexitet O(n2). Detta utf¨ors n g˚anger tills alla blocken ¨ar placerade. Vilket ger slutliga tidskomplexiteten O(n3).
13
Relaterat arbete
”Managing restaurant tables using constraints” [9] ¨ar en rapport som f¨ors¨oker att hantera samma problematik med restaurangers bordshantering. Som titeln s¨ager ¨ar utg˚angpunkten att l¨osa problemet med constraints metod. Constraints ¨ar en metod som utg˚ar fr˚an n˚agra krav som m˚aste uppfyllas f¨or att l¨osningen ska godk¨annas. I detta fall m˚aste borden accepteras som anv¨andbara. Det som mest skiljer sig fr˚an mina alternativ ¨ar att det inte p˚a f¨orhand finns n˚agra utr¨aknade l¨osningar. L¨osningarna r¨aknas ut utifr˚an de krav som st¨alls upp. Detta ¨ar effektivt utifr˚an att det inte kr¨avs n˚agot minne f¨or att spara olika l¨osningar.
14
Diskussion
Detta arbete har vid olika tillf¨allen st¨ott p˚a sv˚arl¨osta problem som lett till stora ¨andringar i struktur och ¨aven f¨ors¨amringar i det f¨orv¨antade resultatet. Grundl¨aggande beslut som togs i b¨orjan av arbetet visade sig l¨angre fram vara sv˚ara att hantera, men s˚a l˚angt in i arbete om¨ojliga att ¨andra. Detta ledde till f¨ors¨ok att r¨atta till, jobba runt, f¨orminska eller acceptera brister och fel som under tiden uppst˚att. Vid vissa tillf¨allen blev resultaten v¨aldigt lyckade och vid andra tillf¨allen fungerande men inte optimala.
En av de grundl¨aggande tankarna, som hela programmet bygger p˚a, visade sig bli ett av de stora problemen att hantera, iden att ha alla m¨ojliga bordskombinationer redan p˚a f¨orhand utr¨aknade. Tanken med detta var att spara tid n¨ar g¨aster eller anst¨allda anv¨ander systemet. Hur borden skulle v¨arderas utifr˚an restaurangens b¨asta skulle hovm¨astaren ha l˚ang tid p˚a sig att best¨amma och slippa beh¨ova ta stressade beslut n¨ar g¨aster redan st˚ar och v¨antar. Resultatet var t¨ankt att det alltid skulle finnas det optimala alter- nativet n¨armast och en egentlig s¨okning skulle inte vara n¨odv¨andig. Detta visade sig vara praktiskt v¨aldigt sv˚art pga. en f¨orbisedd parameter, att det ocks˚a m˚aste finnas en tidsaspekt i systemet. Det r¨acker inte att ha ett per- fekt system vid ett klockslag. Det m˚aste ¨aven fungera n¨asta timme, n¨asta dag och n¨asta m˚anad. Denna tidsaspekt gjorde att storleken p˚a program- met blev s˚a stort att det i praktiken inte skulle vara hanterbart. N¨ar detta uppdagades hade arbetet redan g˚att s˚a l˚angt att det var en b¨attre l¨osning att arbeta vidare med det som fanns i st¨allet f¨or att b¨orja om fr˚an grunden. Denna insikt ledde sedan fram till de tv˚a alternativ som presenteras i denna
rapport. B˚ada dessa alternativ bygger p˚a grundid´en att bordskombinationer redan fr˚an b¨orjan ¨ar best¨amda och prioriterade.
15
Framtida arbete
N˚agra punkter av intresse att fundera vidare p˚a vilket skulle kunna effek- tivisera programmet ytterligare ¨ar:
1. Kunna dela in restaurangen i zoner f¨or att p˚a detta s¨att kunna begr¨ansa vilka delar av lokalen man vill anv¨anda. Vid beg¨aran ska anv¨andaren kunna ¨oppna de olika zonerna i restaurangen. Detta resultaterar i att f¨arre IDK:er kommer beh¨ova hanteras vilket leder till ett ¨overlag snabbare program.
2. Bordstabellen skulle eventuellt kunna hanteras som en bitmask. Detta skulle spara mycket minne d˚a inte booleans skulle beh¨ova hanteras. En 32 bit int skulle kunna hantera 32 bord i st¨allet f¨or en boolean f¨or varje bord.
3. System alternativ 2 skulle kunna effektiviseras om man anv¨ander sig av parallell s¨okning eller eventuellt concurrency. Det g¨or ingen skillnad om systemet parallellt skulle s¨oka och presentera de 1, 5, 10 eller X antal alternativ samtidigt.
4. B¨attre block hantering n¨ar g¨aster anl¨ander f¨or tidigt. Dvs om ett s¨allskap ¨ar t¨ankta anl¨anda 18:00 men anl¨ander redan 17:30. Det g˚ar inte att automatisk placera g¨asterna vid ett block 17:30 d˚a detta kan leda till dubbelbokning. De t¨ankta g¨asterna kan komma klockan 17:35 och d˚a finns inte n˚agot ledigt bord. Exempelvis att om det finns m¨ojlighet flytta fram blocket 18:00 till 17:30. Detta skulle kunna hanteras b¨attre.
5. Den l¨osningen som diskuteras i punkten 7,5 ”L¨osningsf¨orslag p˚a brist i s¨ok” skulle ¨aven kunna omfatta kortare tidblock och olika start/slut tider. Denna skulle garanterat fylla mindre luckor i schemat men till priset av att det skulle ta l˚angtid f¨or varje s¨okning.
6. I rapporten anv¨ands int som data typ f¨or IDK:ers prioritet. Detta v¨arde skulle kunna hanteras med short eller mindre data typ. Detta med
n˚agon variant av bitmask d¨ar b˚ade grupptillh¨orighet och dess prioritet presenteras i samma data typ. De f¨orsta bit skulle representera antal sittplatser och de ¨ovriga IDK:n prioritet i denna grupp.
Exempel med short (16 bit):
• 5 IDK(10) = 000101 0000001010 • 10 IDK(45) = 001010 0000101101 • 60 IDK(456) = 111100 0111001000
Detta exempel skulle ge 64 grupper med olika antal sittplatser och dessa skulle kunna ha 1024 olika prioriteter inom dessa grupper. Skulle man vilja ha fler grupper med olika sittplatser kan man ta en bit fr˚an prioriteterna och i st¨allet ¨agna den till sittplatserna. Detta skulle ge 128 grupper med olika antal sittplatser och dessa skulle var och en kunna ha 512 olika prioriteringar. Detta skulle minska minnesanv¨andningen. 7. Vid optimering ¨ar det f¨orbisett att endast de block som m¨ojligtvis
p˚averkas som borde kontrolleras och eventuellt flyttas. Men i systemet finns inga s˚adana avgr¨ansningar. Detta borde det absolut finnas f¨or att inte systemet ska kolla varenda reservation potentiellt flera m˚anader fram˚at.
8. L¨agga in ett f¨ordelningssystem f¨or hur borden ska f¨ordelas i restau- rangen. Om det exempelvis ¨ar fem bord reserverade i ena ¨anden av restaurangen men inget i andra ¨anden s˚a m˚aste n¨asta reservation hamna p˚a den andra sidan. Detta f¨or att h˚alla j¨amnare tryck ¨over hela restaurangen.
References
[1] Patrik Jungmarker. Intervju. Anst¨alld Caspeco AB, September 2018. [2] Johannes Walleboom. Intervju. Anst¨alld Caspeco AB, September 2018. [3] Torbj¨orn Josefsson. Intervju. Anst¨alld Caspeco AB, September 2018. [4] David Wasowski. Intervju. Restaurang chef, September 2018.
[5] Ronald Rivest Clifford Stein Thomas Cormen, Charles Leiserson. Intro- duction to Algorithms., volume 3rd ed. MIT Press., 2009. pp. 308–309. ISBN 978-0-262-03384-8.
[6] Peter Sanders Kurt Mehlhorn. Algorithms and Data Structures: The Basic Toolbox. Springer, Berlin/Heidelberg., 2008. pp. 154–165. ISBN 978-3-540-77977-3.
[7] Fog Agner. Calling conventions for different C++ compilers and operat- ing systems. Februari 2010. Chapter 3, Data Representation.
[8] Anonym. Intervju. Restaurang chef, Oktober 2018.
[9] J. Christopher Beck Alfio Vidotto, Kenneth N.Brown. Managing restau- rant tables using constraints. Technical report, University College Corc, University of Toronto, November 2006.