gunnard

Håper noen har svar, eventuellt en indikator på om dette vil gå kjappere enn med LinkedList, hvis ikke kan jeg jo bare gi opp hele greia med en gang ><.

Fletting av to sorterte LinkedList vil ta O(N) kjøretid (dersom man husker på hvilket listeobjekt man sist sammenlignet i hver av listene og når et listeobjekts element er lagt til i den flettede listen/arrayet så oppdateres pekern fra dette listeobjektet til listeobjektets neste-peker). Fletting av to sorterte arrayer vil også ta O(N) kjøretid. I praksis vil det kanskje være noe forskjell, iallfall hvis du lager lister av arrayene for så å flette dem. Listeobjektene vil forøvrig ta mer plass i minnet.

Uansett, er god trening å implementere dette også, så hadde jeg vært deg ville jeg gjort det for treningens skyld

Vet ikke om det er meninga, men dersom for eksempel totalLength = 64 og disse saved-arrayene er på 16 vil først run()-kall lagre arrayen i sb-objektet, mens andre run()-kall gå inn i while-løkka, flette den første saved-arrayen med denne nye 16-arrayen, men siden sb.canMerge() fortsatt gir true (arrayene saved har nå lengde 32), vil den flette den flettede 32-arrayene i sb-objektet med den samme 16-arrayen temp som allerede er flettet inn, for så å få en 48-array, som igjen (sb.canMerge() fortsatt true) vil bli flettet med den samme 16-arrayen for å få en 64-array, nå vil sb.canMerge() gi false. Du vil altså få flettet den første 16-arrayen med tre identiske 16-arrayer (fra det andre run()-kallet).

Dersom nå for eksempel totalLength = 60 vil aldri saved.length == totalLength dersom for eksempel både den første og andre run()-kallet er med arrayen er av lengde 16 (vil merge til 32, til 48, til 64, til 80 osv..). Så hvis jeg kan gjette på problemet ditt er det slik at du for eksempel får inn et 30-array, deler det i åtte til 4,4,4,4,4,4,3,3, en array med lengde 3 blir ferdig, denne legges i sb-objektet, en array med lengde 4 blir ferdig og flettes til 7, til 11, til 15, til 19, til 23, til 27, til 31, til 35 osv. Testen saved.length == totalLength er alltid false. Mest sannsynlig, med mindre problemet ditt er annerledes enn jeg har oppfattet, vil du bare fjerne testen ( while (sb.canMerge()) ). Dette fjerner problemet med flere flettinger av samme array (hvis dette da ikke var ønskelig) og problemet med at saved.length == totalLength alltid kan gi false. Dersom flere flettinger av samme array mot formodning er ønskelig kan testen saved.length == totalLength byttes til saved.length >= totalLength - ikke at jeg ser hvilken nytte slik fler-fletting har

Bra du har fått det til

Forresten, beklager helt feil kjøringstidsmål i posten min over dersom du i tillegg til trådutnyttelsen kjører en mer raffinert sorteringsalgoritme som radix sort etterpå.. (ser det har kommet et annet emne som gjør dette) Da er selvsagt algoritmen din O(N) (ved radix sort)..

Dette minner ekstremt om mergesort, men dette visste du vel også? Men jeg vil regne med at den klassiske mergesort-algoritmen med thread-exploiting gir bedre kjøretid i spesialtilfeller og i gjennomsnitt, din algoritme vil jo ha O(N^2), mens mergesort har jo O(N*log(N)). Uansett, siden det er snakk om en primær datatype her gir jo quicksort bedre gjennomsnittlig kjøretid (i Java).

Som pgdx sier kan du lage såkalte flerdimensjonale arrayer. Tenk på en en-dimensjonal array, altså det du snakker om, som en liste med elementer (en vektor hvis du er vant til det begrepet). Denne lages ved: int[] arraynavn = new int[elements];

En to-dimensjonal array er den naturlige utvidelsen av dette, som blir et rutenett av elementer (en matrise hvis du har hatt litt matematikk). Du kan tenke på dette som et regneark for eksempel i Excel. Det høres ut som det er dette du er ute etter, dette vil bli en array av array-objekter. Teknisk er en slik to-dimensjonal array bare en vanlig liste, men liste-elementene er ikke tall som i det en-dimensjonale tilfellet, men liste-elementene er her pekere til en-dimensjonale arrayer. Disse lages, som pgdx sier ved: int[][] arraynavn = new int[rowElements][columElements];

Du kan forøvrig ha arrayer der liste-elementene er to-dimensjonale arrayer, disse er da tre-dimensjonale arrayer, og så videre oppover.

Hvis du vil ha en effektiv løsning til ditt problem - og du ikke nå for sett hvordan du selv klarer å gjøre det - er det best om du skriver litt mer hva du er ute etter å gjøre. Hva er kriteriene for oppdelingen i mindre arrayer? Skal de mindre arrayene være av samme størrelse, inneholde tall i et gitt intervall? Hvordan er den arrayen du i utgangspunktet har bygd opp? Er det for eksempel sortert, kan inneholder duplikater som skal fjernes?

Blir nextLine() hos meg "overskrevet" da?

Ikke helt sikker på om jeg skjønner hva du lurer på, men kan prøve å forklare forskjellen på bruk av nextInt() nextLine() her.. Når du tillater at en bruker å skrive inn noe kan du tenke at det skrevne legges i en kø av tegn. Det normale er at denne køen avslutter med tegnet for linjeskift (i Windows to tegn) som kommer av at brukern avsluttet ved å trykke Enter. "Java" har et leserhode som leser seg bortover i denne køen. Når du bruker nextInt() leser du fra nåværende posisjon til først ikke-tall, stopper der og returnerer tallet. D.v.s. for en linje med bare et tall leser "Java" kun tallet og stopper før linjeskiftet like etter tallet er lest. Når du bruker nextLine() vil "Java" lese t.o.m. først linjeskift og returnere det som var før linjeskiftet. Så når du først brukte nextInt() hadde du fortsatt et linjeskift igjen å lese, og dette linjeskiftet ble lest når du etterpå kalte nextLine() (men siden det bare var et linjeskift var det nextLine() returnerte en tom streng).

Håper du forstod litt hva jeg mente

Når jeg kjører programmet virker det som det hoppes over linje 41: bruker = tastatur.nextLine(); når løkka begynner på andre gjennomkjøring. Istedenfor å prompte for userinput går den rett videre til switch setningen. Alt fungerer normalt ved første gjennomkjøring! Noen som ser hvorfor?

Fordi du bruker tastatur.nextInt() for å lese inn tallet. Da "taes" kun tallet, ikke linjeskiftet etterpå. Ved å i stedet bruke Integer.parseInt(tastatur.nextLine()) , eventuelt med en feilsjekk på om det er en Integer som er inntastet (NumberFormatException hvis ikke), slipper du problemet..

Bruk batteriet!

Ikke kjør maskinen på strømadapteret hele tiden. Bruk batteriet i PC-en innimellom slik at det "trimmes".

Hva er bakgrunnen for dette tipset? Nøyaktig hva innebærer trimming av Li-Ion-batterier, eksempelvis?

Som nevnt mener de nok at batteriet skal brukes og ikke stå fulladet. Synes Acer beskriver problemet godt:

Lithium-ION batterier er som alle andre batterier, basert på kjemiske reaksjoner. I forhold til eldre batteriteknologi, så som NiCD (Nickel Cadmium) og NiMH (Nickel metal-hydride) er disse batteriene et bedre valg for bærbare datamaskiner. De er lettere og tar en høyere ladning enn de gamle typene. Det betyr mer batterikapasitet pr. vektenhet. De har også relativt sett lavere selvutladning og trenger ikke jevne oppladning/utladningsrutiner slik som de eldre batteriene trengte for å komme rundt den såkalte ”minnefunksjonen”. Dette betyr at det ikke lenger er viktig med en rekke fullstendige opp og utladninger i batteriets levetid. ”Klattlading” er ikke noe problem med Lithium ION batteriene

 

Dette betyr ikke at Lithium-ION batteriene ikke er sårbare eller at de er evigvarende. Det er et par forhold man skal være oppmerksom på her også. Det første er ”aldringsprosessen”. Batteriene mister/taper kapasitet over tid. Dette gjelder enten batteriet er i bruk eller ikke. Prosessen er naturlig og kan ikke stoppes. Den kan til en viss grad forsinkes og den kan selvfølgelig akselereres. På grunn av kjemiske endringer inne i batteriet (oksidering), øker batteriets indre motstand slik at det ikke lenger kan opprettholde den opprinnelige ladningskapasiteten. Temperaturforholdene er en av faktorene som påvirker batteriets kapasitet. Jo varmere omgivelser desto raskere brytes batteriets kapasitet ned. Det er ikke gunstig å la den bærbare datamaskinen ligge i sola eller inne i en overopphetet bil en varm sommerdag. Batteriene bør ikke brukes eller lagres i temperaturer over 40 grader. Ønsker man å lagre Lithium-ION batterier, bør dette skje i kjøleskap og med batteriet 40 % ladet. Det verste man kan gjøre er å lagre 100 % ladet batteri i for varme omgivelser. Det er heller ingen god ide å lagre fult utladede batterier. Det som ytterligere reduserer batteriet levetid er stadige fullstendige utladninger. Det er elektronikk inne i batteriet som regulerer både oppladnings- og utladningsprosessen og jo raskere disse prosessene kjøres, jo mer reduseres batteriet. Bruksmessig bør man unngå fullstendige utladninger av batteriet.

Som for svært mange andre ting, batteriet varer lengst hvis det behandles pent.

Hvis du vil ha et bra SLI-kort kan du gå for EVGA nForce 680i SLI. Ellers kan et Asus P5K-kort være aktuelt, men dette har ikke støtte for SLI. Et billigere kort er Gigabyte GA-P35-S3.

Hva slags oppløsning ønsker du å bruke på spill? Er det snakk om 2560x1600 ville jeg vurdert 8800 GTX - eller 2x8800 GT. Dersom det er 1920x1200 eller lavere (f.eks. maks skjermoppløsning) er forskjellen mellom GTX og GT marginal eller ingen. Hvis du tenker for fremtida vil nok 2x8800 GT yte bedre (enn 8800 GTX) - iallfall dersom ordentlig SLI-støtte er tilstedet. Men da hadde du vel kanskje gått for Q6600 i stedet? Dersom du skal ha 2x8800 GT ville jeg gått for en litt kraftigere PSU..

Test av GF 8800 GT hos VR-Zone konkluderer:

Looking at the charts, gamers with monitors under 22 inches will do very well with a single G92 with significant eye candy thrown in, and the G92 also holds up well at 1920x1200, the native resolution of monitors of 27" and below, even beating the GTX in some benchmarks. The question now is, why should anyone pay more for a 8800GTX/Ultra especially when the performance gap is narrowed down till such a stage? Priced at USD$249, it's ridiculous for anyone to spend a good 300bucks more just for a marginal performance difference at maximum resolutions!

Så hvis du har høyere enn 1920x1200 oppløsning hadde jeg satsa på et annet hovedkort og 2x8800 GT, hvis ikke holder det lenge med ett, og du sparer 2000 kroner til noe annet fett!

Crossfire = ATI dobbelskjermkortoppsett, SLI = NVidia dobbelskjermkortoppsett, ditt hovedkort støtte ikke SLI, men støtter Crossfire, men ikke en god støtte, den blå slotten virker bare på x4-hastighet, mot den svarte som er det den skal være x16. (kilde)

Du får svar uansett hvor du pinger, f.eks. www.google.com? Da er det nok et problem med nettleseren.. Hvis du bruker Internett Explorer kan det hende den prøver å ringe opp.. Verktøy -> Alternativer for Internett -> Tilkoblinger -> Slå aldri et nummer.

Hvis du bruker new JTextArea(int antallLinjerSomSkalVises (2?), int minstAntallTegnSomSkalVises) slepper du pikselperfeksjonering, og ofte er det ønskerlig bare å vise hele linjer, ikke deler av neste/forrige linje også. Legg den sør i BorderLayouten, så vil den overstyre minstAntallTegnSomSkalVises og fylle bredden. Det vil den også gjøre dersom du resizer vinduet.

For å få JTextArea til å ikke bare skrive bortover kan du bruke <obj>.setLineWrap(true) (resultatet ligner da på å bruke JEditorPane), og <obj>.setWrapStyleWord(true) vil gjøre at ord ikke deles midt i ved linjeslutt.

Noen fra Intel sa på idf at de holdt på med 8 kjerners nehalem, men de visste ikke om de ville bli ferdige til lanseringa på 4kjerne cpu'ene, og det vil si 4 kvartal av 2008 eller i løpet av 2009.

Ser sånn ut om denne artikkelen og.. Blir lenge å vente på de, iallfall til de er på et akseptabelt prisnivå.. Quad-Core blir det neste på meg da

Det jeg lurer litt på er om du må skrive programmer for å ta i bruk spesifikt et antall prosessorer, eller om du kan sette det opp til å effektivt dynamisk tilpasse seg x antall kjerner. I dag så ser det jo ut som utviklere må bruke tid på å få 2-kjerner til å fungere optimalt, og nå også 4-kjerner. Ville det ikke kunne bli et virvar jo flere konfigurasjoner med antall kjerner det finnes?

Det er mulig å finne antall kjerner på maskinen og optimalisere koden dynamisk etter det. Det er også mulig å lage et program som kan utnytte et bestemt antall kjerner, dvs lage et bestemt antall tråder i programmet, og disse programmene vil da kjøres best på maskiner med så mange kjerner, men kan kjøres på alle. Hvis maskinen har flere kjerner vil ikke de ekstra kjernene bli utnyttet, hvis maskinen har færre vil programmet bli noe tregere enn om det hadde vært optimalisert for det antallet kjerner (grunnet mer leting i høyere minnelager).

Lurte på om noen visste når 8-kjerne-prosessorer er forventet å komme for desktop-maskiner? Leste at Intel skulle få 80 kjerner innen 2011.. Hvis de skal holde dette må de nesten komme med 8-kjernene snart? Noen som vet hvordan prisnivået kommer til å være på disse?

Bios sier jeg har 4, mens Windows sier jeg har 3^^

32-bits-systemer kan bare se 4 GiB minnet, og GiBen fra 3-4 er reservert for kommunikasjon med andre enheter som har minnelager, f.eks. skjermkortet.. I Windows NT-systemer kan man bruke /PAE i boot.ini for å kunne bruke den siste GiBen med RAM, men den skaper ofte mye problemer, så mye at i XP SP2 ble den endret til å ikke gjøre noe.

Har du 64-bits Windows (eller et annet OS) vil du kunne "memory hole remapping" eller "memory hoisting" til å gjøre nytte av (deler av) den siste GiBen med RAM..

(kilde)

CMD bruker annet tegnsett enn selve Windows.. Hvis du ikke skal bytte ut dette kan du bruke følgende:

Tegn - Skriv i Java

æ ---- (char)8216

Æ ---- (char)8217

ø ---- (char)8250

å ---- (char)8224

Jeg har ikke sett noen charverdi som entydig gir ØÅ, men dersom du skal lese inn fra terminalen og vil teste om disse tegnene finnes i det du har lest inn, blir de iallfall oppfattet ved å sjekke etter char c == 65533 (f.eks. if(innlestlinje.indexOf(65533) > -1) // Det finnes trolig ØÅ i det brukeren skrev).

Etter GRUB ikke takla RAID-kontrollern på den ene PC-en fant jeg GAG - Graphical Boot Manager. Lett å installere, grafisk, norsk (hvis ønskelig) og støtter DOS, Windows, Linux o.s.v.. Kan også blant annet passordbeskytte de enkelte operativsystemene. Ville bare nevne det

F.eks photoshop cs3 og firefox med 5-10 tabs + musikkavspilling.

Med 3 GB går det uten problemer.. Regner med at det ikke hadde vært noe hakking med 1GB engang!

Jeg skjønner det med at jo flere programmer jo mer minne blir brukt, men om 3gb holder til mange programmer (5-10 halvtunge programmer) oppe på en gang, uten for mye hakking og etterslep... har slitt med det med eldre PC-er/laptoper.

Et "tungt" program kan bruke mye CPU-tid, men ta lite minne - og omvendt. Men 3 GB holder i dag for alt du trenger. Forresten så tror alle programmer i Windows det samme, ved standardinnstillinger, at den har 2 GB delt minne med alle programmer, og 2 GB eget minne. Dette gir Windows beskjed om uavhengig av hvor mye som faktisk er tilgjengelig..

En annen ting  , /PAE er uten virkning i XP Pro etter SP2:

http://www.dansdata.com/askdan00015.htm

9539542[/snapback]

Bra side!

du kan stappe så store rambrikker ein vil inn men windows 32bits kan ikkje bruke meir dette er rett og slett fordi 32bits software har ikkje fleire adresser til minnehandteringa enn ca 3.000.000.000. 64bits derimot støtter ein del meir.

9539698[/snapback]

Litt mer presist, 32-bits-systemer bruker 3-4GB-minne-adressene til annet enn RAM (kan se hva innenfor Minne på Enhetsbehandling - Vis - Ressurser etter tilkobling), som f.eks. for å komminusere med skjermkortminnet. I mange 64-bits-systemet vil også 3-4GB-adressene bli brukt til dette og man vil dermed "miste" 1GB RAM - dersom ikke "memory hole remapping" eller "memory hoisting" brukes.

Regner med at du har en skjerm med Crystal Bright.. De skinner litt mer enn vanlig skjermer.. Er meninga at det skal bli enda bedre å se på tror jeg Men de er dårligere enn vanlige når det står mye lys på dem.. Jeg sitter mye på en PC med CB-skjerm, synes ikke det er så ille dersom lysstyrken på skjermen er på fullt (Fn + pil til høyre er øking av lysstyrken tror jeg)..

Mellom linje 65 og 85 er en klasse av typen ActionListener, og en annen mellom 92 og 97. Som du ser lages disse ved:

<objekt>.<metode>(new <klassenavn>() { //variabler og metoder });

der "//variabler og metoder" er koden til den anonyme klassen av <klassenavn> er. Alternativt kunne du laget en egen klasse, dersom <klassenavn> er ActionListener som her:

class Lytter implements ActionListener {

//samme kode, public void actionPerformed(ActionEvent e) må implementeres

}

og skrevet i stedet:

<objekt>.<metode>(new Lytter());

Håper det hjalp

Vet ikke om det har noe å si, men bare et par ting jeg ville gjort annerledes:

- Slenge inn conn.setUseCaches(false) (f. eks. etter conn.setDoInput(true))

- Hvis mer enn " " er URL-kodet burde du bruke URLEncoder.encode(artist, "UTF-8") (hvis artisten har noen andre tegn som skal konverteres kan det jo hende du prøver å koble deg opp mot feil dokument)

- Trenger du input.close()? Mulig jeg tar feil, men tror det holder å lukke BufferedReader'en (iallfall har det holdt for meg)

Lykke til!

Bra du fikk det til

Fungerer som pgd sier, eller sagt litt med andre ord fra min gamle lærebok (etter hukommelsen), "Et interface er en ekstremvariant av en abstract klasse der alle metodene er public abstract og alle "variablene" er public static final."

Bedre klokkeevne

EDIT: Kan klokke høyere opp, så ikke spesielt aktuelt for deg..

"Array <int> noe" har jeg aldri hørt om heller..

jeg lurer spesielt på hva <...> betyr.

I for eksempel "ArrayList <Integer> noe" deklareres en liste av heltallselementer, og da står <...> for klassen listen "noe" skal være av. Dersom man skriver bare "ArrayList noe" vil man få en listen av typen Object. Dersom man da skal ta ut elementene i "noe" (gjøres ved noe.get(plassnr)), må det objektet som returneres omtypes (castes) til ønsket klasse (for eksempel Integer) før du kan brukes (som i eksempelet et heltall). Dersom man i deklarasjonen og tilordningen har presisert klassen slepper man å omtype elementene.

Forresten, dersom man skriver: "ArrayList <Klassenavn> noe;" burde tilordningen skje ved "noe = new ArrayList <Klassenavn> ();" for å få ønsket effekt.