Fix om värstafallstid

[rfyuz]

Det framgår av uppgiftsbeskrivningen för betyg VG att linjär värstfallstid är "svårt men inte omöjligt", implicit för både uppgift 3.2 och 3.3. Men, enligt https://stackoverflow.com/questions/4168622/computing-the-mode-most-frequent-element-of-a-set-in-linear-time och satser på Wikipedia (Element distinctness problem), bl.a. så finns det ingen lösning som ger värstafallstidskomplexitet O(n).

Den tidigare formuleringen var missvisande, och kan leda till att mycket onödig tid läggs på att försöka hitta en sådan lösning för 3.2. Jag la mycket onödig tid på detta, t.ex. ;P

[rfyuz]

Tror faktiskt att det här gäller? Mvh

[korthaj]

Hej Eskil!

På nästa föreläsning kommer det lite mer om sortering och undre gränser. Då tror jag att det här mysteriet kommer att klarna. :)

[rfyuz]

Tack för svar på föreläsningen :)

Jag förstår det som att man ska använda en lista av oinitialiserade pekare med bookkeeping för att se vilka som innehåller skräpdata och vilka som är okej / har initialiserats. I bookkeepingstrukturen kan man senare hålla koll på antal m.m.

Dock förstår jag det som att
i) Detta endast funkar för datatyper där det finns ett begränsat antal möjliga data som får plats på datorns RAM-minne, t.ex. uint16
ii) Lösningen är inte nödvändigtvis minnessäker i Go, ty en oinitialiserad array av pekare kan överskrivas av andra program som körs i samma Runtime. Man kan lösa det genom att säkerställa att inget / inte mycket nytt minne används när programmet körs, men det löser inte fall med flera processorer t.ex. Känns inte som en säker lösning.

Är detta den tänkta linjära lösningen eller finns det något jag har missat?

Tack för alla hints hittills ivf!
Mvh,
Eskil