Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  4 675
Heisann

Jeg har et kinkig problem i to dimensjoner. Jeg har klart å dele det opp i et delproblem i en dimensjon som (forhåpentligvis) vil hjelpe meg å løse hovedproblemet. Dette mindre problemet er dessuten interessant også på generell basis. Så jeg spør her etter løsningsforslag og diskusjon om delproblemet. Det jeg skal implementere er en abstrakt datatype som jeg skal beskrive her:

ADT Table
Get(y): Return pointer to element y if y exists in the table
Create(y): Return pointer to element y. If y doesn't exist, create it.
Delete(y): Delete element y from the table.
InsertRows(beforeY, count): Insert a number of rows, or empty elements, before element y

Presiseringer:
1. Elementer aksesseres by position (y). Noe som impliserer at hvis man setter inn to rader/elementer mellom element 2 og 3 vil det som før var element 5 nå bli element 7.
2. Det vil være store mengder elementer som ikke er laget og (flesteparten av) disse skal ikke lagres i strukturen ("sparse data structure").

Ytelse:
3. Get(), Create() skal skalere godt.
4. InsertRows() skal skalere godt.
5. (Bonus hvis Delete() også er rimelig skalerbar.)

De fleste punktene er helt greie krav hver for seg. Man kan løse punkt 1 og 2 med en linked list. Men dette ødelegger ytelsen til Get(). Man kan få en god ytelse på Get() ved å bruke en trestruktur eller hashtable med y som nøkkel. Men bruken av nøkler ødelegger ytelsen til InsertRows(). Kombinasjonen av flere krav samtidig gjør altså dette til et mer utfordrende problem.

Noen ideer eller synspunkter?

Sitat av Hovedproblemet
Til slutt tar jeg med hovedproblemet, som dere godt kan hoppe over. Det er en datastruktur med rader og kolonner som ser slik ut:
Get(x, y): Return pointer to element (x, y) if it exists in the table
Create(x, y): Return pointer to element (x, y). If it doesn't exist, create it.
Delete(x, y): Delete element (x, y) from the table.
InsertRows(beforeY, count): Insert a number of rows (with empty elements) before row Y
InsertCols(beforeX, count): Insert a number of columns (with empty elements) before column X
Vis hele sitatet...
med fruktkjøtt.
Tias's Avatar
Crew
Dette er jo egentlig bare en prioritetskø, og kan som du sier implementeres som en trestruktur i form av en heap. En vanlig binærheap vil gi deg kjøretiden O(1) på søk, og O(log n) på innsetting og sletting. Mer spesialiserte heaper som fibonacci heapen kan gi deg kjøretid helt ned i O(1) på alt bortsett fra sletting, hvor beste kjøretid er O(log n).

En god hashtabell kan også gi deg veldig god kjøretid, men kan aldri garantere O(1) på noen operasjoner. I praksis er ofte hashtabeller raskere enn en heap, men en prioritetskø har fordelen at den alltid er sortert.
Du nevner noen datastrukturer som gir god kjøretid på lookup (Get()), innsetting (Create()) og sletting (Delete()). Men du glemmer helt InsertRows(), som skal sette inn tomme elementer.

La meg vise InsertRows() på problemet implementert som en hashtable:

Kode

; Sånn ser den ut først
Tabell("0") = "Rør"
Tabell("1") = "Tuba"
Tabell("2") = "Bilhorn"
Tabell("3") = "Ostehorn"
Tabell("4") = "Bagels"
Tabell("5") = "Kake"

; Så kjører vi InsertRows
InsertRows(2, 150)

; Sånn skal den se ut etterpå
Tabell("0") = "Rør"
Tabell("1") = "Tuba"
Tabell("153") = "Bilhorn"
Tabell("154") = "Ostehorn"
Tabell("155") = "Bagels"
Tabell("156") = "Kake"
Om jeg har 500000 elementer og skal sette inn ett element mellom nr. 1 og 2 må jeg rehashe 500000 elementer. Dette er jo en aldeles horribel ytelse som ikke ligner grisen. Den samme problemet oppstår med en trestruktur der Y er nøkkelen.

Edit: Hvorfor får svar som ikke svarer på problemet kvalitetspoeng? Les nøyere! Legg merke til:
[COLOR="Red"]1. Elementer aksesseres by position (y). Noe som impliserer at hvis man setter inn to rader/elementer mellom element 2 og 3 vil det som før var element 5 nå bli element 7.[/COLOR]

Tillegg: Jeg ser at det vesentlige i oppgaven overses. Altså:

[COLOR="Red"]1. Elementer aksesseres by position (y). Noe som impliserer at hvis man v.h.a InsertRow() setter inn to rader/elementer mellom element y=2 og y=3 vil det som før var element y=5 nå bli element y=7.[/COLOR]

Se for øvrig denne posten: http://freak.no/forum/showpost.php?p...48&postcount=3

Arrg, tillegget kom i denne posten istedenfor førsteposten.

Tillegg: Jeg ser at det vesentlige i oppgaven overses. Altså:
[COLOR="Red"]1. Elementer aksesseres by position (y). Noe som impliserer at hvis man v.h.a InsertRow() setter inn to rader/elementer mellom element y=2 og y=3 vil det som før var element y=5 nå bli element y=7.[/COLOR]
Sist endret av Kråkelefse; 28. februar 2012 kl. 16:08.
med fruktkjøtt.
Tias's Avatar
Crew
Hvis du er nødt til å oppdatere alle nøklene kan jeg ikke se for meg en datastruktur som vil gi deg en bedre ytelse enn O(n).
Sitat av Tias Vis innlegg
Hvis du er nødt til å oppdatere alle nøklene kan jeg ikke se for meg en datastruktur som vil gi deg en bedre ytelse enn O(n).
Vis hele sitatet...
Ja, så lenge man bruker posisjonen (y) som en nøkkel må alle nøklene oppdateres. Det er jeg også klar over. Hvis ikke hadde jeg jo bare brukt en hvilken som helst vanlig datastruktur istedenfor å spørre her.

Det er derfor en selvfølge at jeg ser etter en algoritme der nøkkelen ikke er bundet til y. Eventuelt en algoritme uten nøkler.