PNG32 PNG32 PNG32 PNG32
PNG32
Forum Excel, VBA, VSTO, Exceltips, Excelhj�lp PNG32 drivs av Excelspecialisten    Logga in     English
PNG32
PNG32 PNG32
PNG32

Logga in

PNG32

Du är inte inloggad. Logga in eller registrera dig för att skriva inlägg eller svara på inlägg.

För frågor om forumet, kontakta oss på webmaster@excelforum.se

PNG32 PNG32
PNG32 PNG32
PNG32

Excelforum

PNG32

 
ForumForumDiskussionerDiskussionerExcelExcelhitta 50 / 50 enkelthitta 50 / 50 enkelt
Föregående Föregående
 
Nästa Nästa
Nytt inlägg
 2023-04-30 05:24
 

 Hej Gondi

Ser fram emot detta, får du igång den gamla elefanten att klara det så klarar ju 64-bitars det också :)

Väntar med spänning.

Nytt inlägg
 2023-05-07 18:57
 
 Ändrad av Gondi  på 2023-05-07 19:52:43

Hej på er igen!

 
Jag bad om "lite tid" för att ta fram en lösning...
 
Nu har jag fått en veckas tid och spenderat - utan överdrift - minst 100 timmar på denna utmaning. Det är i särklass den absolut svåraste Excelutmaningen jag försökt att lösa under mina 25+ år med Excel.
 
Eftersom utmaningen gick ut på att lösa detta med (32-bitars, max 2GB RAM) Excel 2007 på min gamla Acer AMD Athlon (Dual Core, 1.2GHz 4GB RAM) från 2009 så stötte jag minst sagt på "patrull".
 
Även om Excel 2007 stödjer det som kallas för "Big Data" (1024K x 16K rader och kolumner) så är det mycket svårt att få hårdvara från den tiden att prestera med den storleken på Excelark.
 
För att sammanfatta det hela så var den största utmaningen inte att skriva formlerna utan att hantera hård- och mjukvaruresurserna jag hade tillgängliga.
 
Det finns utmaningar inom följande områden.
  • Filstorlek (filerna blev snabbt större än 100MB)
  • Inläsningstider (det kan ta 20+ minuter att öppna ett Excelark)
  • Minnesåtgång (efter ~1750GB RAM användning av Excel 32-bit så krashar Excel 2007)
  • Beräkningskapacitet (Med enbart en Dual Core 1.2Ghz processor har man inte kapacitet nog att hantera alla beräkningar) 
Till att börja med "hackade jag på" med mina vanliga formler för att lösa utmaningen rent funktionellt. På en modern dator med 64-bitars Excel är det oftast inte så viktigt hur man skriver sina formler eftersom en processor på ~3.8Ghz med 12+ Cores utan problem kan utföra beräkningarna man skriver nästan i realtid. Så är dock inte fallet med en Dual Core AMD Athlon på 1.2GHz från 2009...
 
Det fanns ett problem jag inte kunde lösa med Excel 2007 och det var sorteringen. Om man har 3^12 (531441) rader och ska söka igenom dem med en en Excelfunktion för att rangordna dem (STÖRSTA (), MINSTA(), RANG(), etc.) tar det matematiskt 3^12 * 3^12 = 3^24 itterationer. Detta är mer än man kan klara av med med till och med modern hårdvara. Man måste använda snabbare algorithmer för ändamålet. Exempelvis Quicksort från 1961 är en mycket snabb sorteringsalogorithm som också används av Excels inbyggda sorteringsfunktion, även om det är en proprietär "Microsoftvariant" av Quicksort.
 
Så här ser mitt resultat ut. Arket tar cirka 3 minuter att läsa in efter optimering och en full beräkningscykel tar cirka 30 sekunder på min gamla Dual Core AMD Athlon 1.2Ghz.
 
 
Du får gärna höra av dig Joker om du är intresserad av den tekniska lösningen och formlerna.
Nytt inlägg
 2023-05-08 06:03
 

Wow Gondi :)

Det ser riktigt proffsigt ut, jag vill absolut testa det där, det skulle vara mycket tacksamt om jag kunde få till det.

Jag har googlat en del på pareto-principen men verkar inte finnas något där heller, det är ju annars lite av det jag söker förutom att kunna sätta egna %.

Jättetacksam så länge, ha det bra så länge :)

Nytt inlägg
 2023-05-08 18:43
 

God kväll,

 

För att det här ska bli förståeligt måste vi börja från grunden.

 

Den absolut största utmaningen med att arbeta med "Big Data" i Excel är att filerna snabbt blir enormt stora. Ju större filerna blir desto längre tid tar det att öppna dem med Excel och desto mer minne krävs. Eftersom jag i detta fall var begränsad till 32-bitars Excel 2007 så kunde jag inte tillåta att filerna blev hur stora som helst - därför blev jag tvungen att både optimera och suboptimera denna arbetsbok.

 

Det är primärt fem parametrar som mina tester visat styr över hur stora Exceldokument blir.

  • Filformatet man använder, xlsx (XML) eller xlsb (BIFF)
  • Antal använda celler (Ctrl+End)
  • Antal tecken i cellerna/formlerna
  • Cellformatering (färger, kantlinjer, etc.)
  • Om man använder tabellformat eller vanliga dataområden

Filformat (xlsx vs. xlsb)

 

Om man sparar stora Exceldokument i det binära filformatet xlsb så sparar man inte bara enorma mängder diskutrymme utan man snabbar även upp inläsningen av dokumenten avsevärt. Det binära filformatet xlsb gör dokumenten ända upp till 90% mindre än xlsx. På riktigt stora filer kan man även snabba upp inläsningen fem-sex gånger jämfört med samma dokument sparat i xlsx-format. Detta beror antagligen på att det binära filformatet xlsb inte behöver "översättas" till binärer av Excel vid inläsning utan filen kan skrivs direkt till minnet. 

I en av mina tester hade jag samma dokument sparat som xlsx (122 MB) och som xlsb (89MB). Filen i xlsx-format tog 21 minuter att öppna på min gamla laptop. Samma fil i xlsb-format tog endast 4 minuter att öppna. 

 

Antal använda celler

 

Det var givet att vi skulle arbeta med ett tipssystem med 12 matcher plus den match vi ska analysera. 3^12 = 531'441, totalt alltså 531'441 * 12 = 6'377'292 celler för själva systemet. Sen behöver vi hjälpkolumner också för att underlätta och snabba upp beräkningarna. I min lösning använder jag tre hjälpkolumner à 531'441 rader, dvs. 1'594'323 celler till. Totalt blir det alltså nästan 8 miljoner celler som kommer användas. 

 

Antal tecken per cell/formel

 

Om man betänker att ett tecken motsvarar en byte så förstår man snabbt att detta kommer bli ett megadokument rent storleksmässigt och detta måste man adressera på något vis om man vill få det att fungera överhuvudtaget. Från början såg formeln som bygger hela systemet ut så här;

 

=OM(RAD()-RAD(tbSystem[#Rubriker])<=Rader/3;INDEX(D$7:D$9;REST(AVRUNDA.UPPÅT(((RAD()-RAD(tbSystem[#Rubriker]))/3^(12-(KOLUMN(tbSystem[1])-KOLUMN(tbSystem[[1]:[1]])+1)));0)-1;3)+1);"") 

 

Tänk er då att vi multiplicerar ovan formel med de 6'377'292 celler som systemet använder. Då förstår man snabbt att filen blir enormt stor och att minnet tar slut för stackars 32-bitars Excel 2007.

 

Cellformatering

 

Cellformatering är inte den viktigaste av parametrarna utan utgör endast en marginell skillnad på filstorleken, men någon procents skillnad kan man utläsa från skillnaden i filstorlek. Störst skillnad märker man att det gör när man jämför ett stort dataområde formaterat som tabell eller som dataområde. Ett dataområde formaterat med exempelvis enbart bakgrundsfärg - även om cellerna är tomma - "käkar diskutrymme". I en av mina tester hade jag de tolv kolumnerna formaterade enbart med bakgrundsfärg. Detta dokument blev 21MB att jämföra med 2MB när cellerna var oformaterade.

 

Tabellformat vs. dataområde

 

Alla mina tester och dokument har entydigt påvisat att Excels tabellformat är överlägset ett vanligt dataområde på i stort sett alla vis. Ju större tabellen är desto mer sparar man både i filstorlek och inläsningstid. Storleksskillnaden märks mest när man använder filformatet xlsb, men även xlsx-filer blir mindre i storlek och läses in fortare om man använder Excels tabellformat istället för vanliga dataområden. Jag antar att det mest hänger ihop med cellformateringen. I en tabell behöver Excel bara spara formatet en gång för hela tabellen medans i ett vanligt dataområde sparas formateringen per cell.

 

Nu börjar det här inlägget bli alldeles för långt så jag tror att jag avslutar här nu när vi har gått genom grunderna för Excel i sammanhanget "Big Data". I morgon kommer jag förklara hur jag gick till väga för att lösa alla problem beskrivna ovan med Excel 2007.

Nytt inlägg
 2023-05-09 17:59
 

 Tack, mycket intressant läsning, nog vet jag allt att excel filer kan bli stora och det är ju alltid hopplöst om man råkar spara av misstag då det inte är helt säkert att filen går att öppna igen, jag tror största fil jag har sparat är på över 320Mb, och det går ju inte.

En irriterande sak i excel eller så är det bara jag som inte vet vad skillnaden är, att välja beräkningsalternativ till manuell hjälper inte, den beräknar ändå när jag lägger in nya siffror eller formler, manuell tänker då jag att det ska krävas t.ex. F9 men så funkar det inte hos mig.

Nåväl, jag sitter och laborerar med mina formler och siffror, tycker fortfarande att det är märkligt att t.ex. Pareto-principen finns på ett enkelt sätt, det enda som microsoft skriver är ju hur man gör ett pareto-diagram, visst man ser ju skärningspunkten men det är ju inte riktigt vad jag är ute efter men principen som pareto gör är ju vad jag är ute efter, dock som en justerbar 80/20 regel som jag då t.ex. vill få fram 50/50.

Hur som helst är jag väldigt tacksam att du hjälper mig med detta, ser fram emot fortsättningen :)

Nytt inlägg
 2023-05-10 18:31
 
 Ändrad av Gondi  på 2023-05-11 05:10:52

Hej igen Jokern,

Här kommer nu del 2 av ”Joker-utmaningen” på Excel 2007.

Utmaning

Hitta positionen i en lång serie med värden, där summan av de största värdena - efter sortering från högsta till lägsta - är lika stor som summan av övriga, dvs. jämviktspunkten.

Frågeställningen grundar sig på ett tipssystem där det finns tre möjliga utfall i 13 matcher. Eftersom den matchen man ska analysera inte behöver ingå i systemet blir antalet 3^12 =531’441 möjliga kombinationer, multiplicerat med 12 kolumner = 6’377’292 celler.

Med hjälpkolumner - för att snabba upp beräkningarna - och annat så kommer lösningen kräva att man använder sig av cirka 8 miljoner celler.

Initialt var det mycket svårt att få minnet att räcka till eftersom Excel 2007 (finns bara 32-bitars) kan i teorin använda max 2GB RAM. I praktiken ”krashar” dock Excel redan någonstans runt 1750MB minnesutnyttjande. Då får man antingen en varning om att resurserna är slut, eller så får man ”spinning wheel of death”, eller så kan man spara filen, men den går inte att öppna igen eftersom Excel måste tillfälligt allokera buffertminne och annat när filer öppnas.

”Joker-projektet” började precis där, med minnesproblematiken för en dryg vecka sen. Den första ”fungerande” version jag fick till blev den nedan. Som man kan utläsa av filnamnet tog det 20 min och 13 sek att öppna filen i Excel och minnesåtgången var 1513MB.

Jag övergick till att börja använda Excels binära filformat xlsb. Med xlsb-formatet blev filerna väsentligt mindre - och gick betydligt snabbare att öppna – men minnesåtgången förblev densamma, vilket också var väntat.

Jag analyserade ett antal olika scenario för att förstå hur Excels minnesåtgång påverkas. Min slutsats blev entydig. Det är primärt antalet använda celler samt storleken på formlerna som påverkar filstorleken samt minnesåtgången. Eftersom systemet kräver runt 8 miljoner celler blev jag tvungen att hitta en lösning för att minska storleken på formlerna i varje enskild cell i Excel.

Det var då jag kom på det!

Vi har ju inte tillgång till LAMBDA() i Excel 2007, men vi har något som är nästan lika kraftfullt, nämligen Namnhanteraren!

Namnhanteraren kan inte bara skapa ”genvägar” till celler och cellområden utan den kan även skapa alias för formler.

När jag hade kommit på det ”tricket” så minskade filstorlekarna, inläsningstiderna samt minnesåtgången ordentligt, till följande för xlsx-formatet.

Och för xlsb-formatet.

Jag tyckte fortfarande att filerna var lite väl stora och ”sega” att läsa in så jag bestämde mig för att subotimera lösningen.

Eftersom alla formler finns definierade i Namnhanteraren behöver man inte spara dem i varje enskild cell. Således skapade jag en mall där allting finns skapat, men utan att varje cell har någon formel.

En ”tom” lösning är helt optimal. Den går supersnabbt att öppna och eftersom man ändå varje gång man öppnar arket antagligen vill mata in nya procentsatser, gränsvärden och välja match att analysera blir det mycket smidigare att börja med en tom mall. Med mallen klar så krympte filerna riktigt drastiskt till följande.

Och för xlsb-formatet.

Nu börjar det likna något!

Under en minut för att öppna Exceldokumenten på min gamla Acer med endast 4GB RAM och en Dual Core 1.2GHz från 2009.

Så här ser mallen ut när man läser in den på 30 sekunder med xlsb-formatet.

Konstruera ovan struktur i Excel och använd sen namnhanteraren för att skapa följande.

Nu börjar det här inlägget också bli för långt, så när ovan är klart kan du höra av dig Jokern, så ska vi ta del 3 av ”Joker-utmaningen”. ;-)

Trevlig kväll!

 

Nytt inlägg
 2023-05-11 19:22
 

 Oj, vilken skillnad i tid, men hur ska jag lyckas få till det där, det ser ju allt annat än enkelt ut, 1748 / 121747 = 1,4%, 98,6% mindre, det är ju en enorm skillnad i storlek på fil, är det verkligen utan att tappa en massa innehåll, fantastiskt isf.

Fråga 1, är mallen så där knepigt utformad som tabellen var förut ?

Det lär jag väl kanske märka när jag någon gång knappat in allt som ska vara i namnhanteraren om det inte fungerar.

Det jobbiga är ju att jag redan har tänkt ut hur jag vill kunna använda detta i steg 2, men det kanske ger sig till slut om den tanken ens är möjligt, det är iaf. redan uträknat och klart i min skalle och därför hade det varit enklare om det rent matematiskt gick att räkna ut med formler, hur som helst så hoppas jag få tid att lägga in allt i namnhanteraren i helgen trots att jag jobbar då men några timmar ska jag väl få över, det är ju 13 millar i jackpot på lördag och då hade man ju velat vara med och sedan inte ha någon tidsbrist när man håvar i den raden :)

Hade ju varit fint om man hade hunnit klart, annars får man väl göra som vanligt, sitta frustrerad och se hur lätt raden ändå är, bara man kunde få ner radantalet.

Nu först middag och sedan läggdags och upp och jobba imorgon igen

Nytt inlägg
 2023-05-11 23:25
 
 Ändrad av Gondi  på 2023-05-12 04:50:53

Hej igen Jokern,

Nu är vi tillbaka på "ruta ett" igen med frågeställningen... :-)

Som jag förklarade tidigare i den här tråden finns det (mig veterligen) bara två sätt att lösa det på matematiskt.

  1. Man kan beskriva steglängden som en matematisk funktion. Det behöver inte vara en linjär funktion, men den måste gå att beskriva med en funktion.
  2. Man kan plotta in värdena i en graf och därigenom med hjälp av approximering skapa en matematisk funktion som ligger "nära" svaret.

Problem med punkt 1 ovan är att det finns 3^12 kombinationer. Dvs. steglängden går inte att beskriva med en funktion.

Problem med punkt 2 ovan är samma sak. För varje ny uppsättning med procentsatser kommer grafen och därmed den matematiska funktionen ändras.

Tänk så här;

Om samtliga matcher varit streckade exakt lika mycket (33,3333333...%) så har man en konstant steglängd (en linjär funktion) och det går då att räkna ut var jämviktspunkten uppstår eftersom man kan räkna fram nästa värde i talserien.

I det här fallet kan vi inte beräkna storleken på nästa värde eftersom steglängden skiftar 3^12 gånger. Ibland är t.o.m. nästkommande värde i serien lika stort som föregående (steglängd noll) eftersom rent matematiskt blir 2 * 3 * 4 samma sak som 4 * 3 * 2.

Det är ungefär som att ställa frågan hur många gånger man måste slå en tärning för att uppnå summan 100?

Rent matematiskt blir svaret 29 gånger. Men det är inte ett exakt svar. Svaret kan variera från 17 till 100 gånger beroende på vad steglängden (det man slår) blir varje slag.

Det enda sätt jag känner till att beräkna svaret på blir att använda "brute-force", dvs. man får beräkna alla möjliga kombinationer.

Nytt inlägg
 2023-05-12 06:02
 

Hej igen Gondi

Jag har börjat lägga in alla dessa i namnhanteraren men blir bara mer tveksam till om jag kommer att få det att fungera.

Jag tror att jag förstår din senaste förklaring så jag har funderat på en sak som man kanske skulle spinna vidare på.

Dessa 1594323 alla raders produkt i sorterad form där mest streckade kommer högst upp, högsta sannolikhet att den inträffar och sedan i fallande ordning där raden längst ner har lägsta sannolikheten att inträffa, MEDEL för alla dessa rader är alltid detsamma, nämligen enligt denna formel =UPPHÖJT.TILL(MEDEL(A1:M3);13)/1E+24 om streckprocenten ligger i A1:M3, problemet är ju att antalet värden / rader ner till medel varierar MEN det man alltid vet är summan är ju alltid långt över 50 när man summerar ner till medel, jag har aldrig sett summa under 75 och bara någon enstaka gång har det varit över 300 tusen rader, generellt skulle man kunna säga att det är en ungefärlig pareto om man säger att rader vars produkt är över medel ger summan enligt pareto 80% men bara 20% av raderna och tvärtom, raderna vars produkt är under medel är 80% av raderna men summan bara 20%.

Detta innebär således att av alla tänkbara rader så är det bara rader vars produkt över medel är de intressanta, problemet är ju när man vill få ut detsamma per tipstecken, även om samma "pareto-tanke" även fungerar där, dock är det ju de lågt streckade som ställer till det och de inte inträffar så ofta i början så krävs det att man kommer långt ner för att uppnå deras egna medelvärde MEN antalet rader ner till RAnk 3 medel är detsamma som antalet rader ner till Rank 1 i samma match.

Om du räknar ut MEDEL för alla rader och byter ut vilken valfri mest streckad i varje match så ser du att du alltid får ett högre MEDEL för varje mest streckad, alltså skulle man "bara" behöva laborera med alla de rader som har en produkt som överstiger medel och endast ta reda på Rank 1 antal ner till medel för att få reda på resterande tipsteckens antal då det är samma för att uppnå samma procent.

Det var en intressant upptäckt om du frågar mig, om det skulle räcka med att "bara" använda sig av 20% av raderna och "bara" 1 av 3 tipstecken, kruxet är ju att man behöver få reda på hur de olika raderna ser ut för de övriga, det man vet med säkerhet är att på samma radantal så skiljer det endast 1 tipstecken så även där hänger de ihop hela vägen ner.

Nu är det dags för jobb igen.

Ha en bra dag så länge. 

Nytt inlägg
 2023-05-12 19:17
 
 Ändrad av Gondi  på 2023-05-12 18:31:37

God kväll Jokern!

Jag förstår hur du "tänker", men det finns en utmaning. För att kunna analysera enbart "Top 20%" av raderna måste man veta vilka rader som är Top 20. Man måste fortfarande beräkna samtliga produkter för att kunna rangordna dem eftersom vilka som är "Top 20" beror ju på i vilken ordning man beräknar kombinationerna = "hönan eller ägget".

Den ultimata lösningen på frågeställningen är att ta fram en algoritm som kan rangordna relationen mellan procentsatserna, utan att behöva beräkna dem. En sån algoritm har dessutom fördelen att man inte behöver sortera produkterna innan man analyserar resultatet. Sen kan man med denna algoritm beräkna exakt var jämviktspunkten kommer inträffa, utan att på förhand behöva beräkna alla kombinationer.

Jag har tittat på hur en sån algoritm kan tas fram, men inte "knäckt" koden ännu.

I väntan på mina framsteg med algoritmen så är det "näst bästa" att använda VBA som är mycket snabbare än Excel. Och om man inte gillar VBA så får man falla tillbaka på min mall med formler i Namnhanteraren.

När du är klar med namnhanteraren så fortsätter vi med "Del 3" av utmaningen.

Föregående Föregående
 
Nästa Nästa
ForumForumDiskussionerDiskussionerExcelExcelhitta 50 / 50 enkelthitta 50 / 50 enkelt

PNG32 PNG32
Excelforum drivs av Excelspecialisten som bedriver utbildning i Excel och VBA, tillhandahåller support och hjälp med Excel, utvecklar program i Excel. Är ni i behov av en konsult inom Excel, VBA eller VSTO, eller söker en excelkurs, kontakta oss.
Copyright 2013 ExcelSpecialisten XLS AB   Användarvillkor  Personliga uppgifter