gunnard

Dagens JPEG tilbyr så vidt jeg vet ikke tapsfri kvalitet selv om det er mulig å beskjære og rotere bilder uten ytterligere kvalitetstap.

Man har jo JPEG-LS, som bygger på andre kompresjonsteknikker enn JPEG. I tillegg er det enkelte som kaller lossy JPEG-kompresjon uten vektmatriseskalering for lossless, men det er ikke helt korrekt da tallene må avrundes til heltall etter DCTen (diskret cosinus transformen), men det store tapet i JPEG-kompresjonsalgoritmer, vektmatriseskaleringen, er borte.

Hva mener du med "finne eit angitt symbol"? Mener du symboler som har lignende form som det symbolet eller som er nøyaktig like? Å finne symboler med lignende form er vanskelig, med mindre du finner en implementasjon som gjør dette tilstrekkelig godt for ditt behov.

Dersom du er ute etter å finne en nøyaktig kopi, mer presist så har du (eller kan generere) et delbilde og ønsker å finne hvor dette forkommer i et bilde, er det bare å korrelere bilde med delbildet og ta ut pikselkoordinatene til de(t) høyeste verdi(ene). Merk at denne metoden, ofte kalt template-matching, er variant i forhold til både skalering og rotasjon, altså hvis du for eksempel har et delbilde av en liten firkant vil du ikke finne noen store firkanter i bildet, ei heller noen firkanter som er rotert annerledes enn den firkanten du har i delbildet. Fordelen med metoden er at den er så enkel å implementere at det ikke er verdt bryet å lete etter en ferdig implementasjon, i tillegg til at den er svært effektiv under forutsetning at du faktisk ikke ønsker også å finne skalerte og roterte versjoner av symbolet.

Når det gjelder feilmeldinger skjønner jeg ikke noe av det samme hvor det skulle peke hen.

NullPointerException betyr her at arrayen ikke er opprettet (så det er egentlig ikke en array ennå), det er bare en peker på "null".

Jeg glemte å si at verdiene inne i firkantparantesene IKKE er rett plassert. Jeg bare prøver meg frem uten å lykkes.

Det er jo opplagt, men det er mange andre feil, og det er disse som gjør at koden ikke kjøres.

Det er nok ikke bare denne delen som bør endres. Promblemet er jo at jeg ikke kan det.

Det kan være lurt å starte på et mye mer grunnleggende nivå og arbeide seg oppover. Dersom du insisterer på å løse dette problemet nå må du tenke at du trenger å lære deg mer generelle ting samtidig, altså må du uansett lese litt generelt utenom. Et greit sted å starte da er å lese såpass at du forstå hva som er feil i den kodebiten du sikter til:

if (generations > 0)
	for (int i=0;i<barn.length;i++)
			barn[i].lagBarn(generations -1);
					for(int i=0;i<barn.length;i++)
}

Exception in thread "main" java.lang.NullPointerException

at DataNode.DataNode.dump(DataNode.java:109)

at DataNode.Main.main(Main.java:28)

Java Result: 1

Når du får ut en feilmelding så bør du sjekke den linja som står oppgitt. Hvis det er denne linja:

if (data[i][j] == 0) {

så betyr feilmeldingen at data-arrayen din er null, det vil si at det ikke er en array, bare en tom peker. Hvorfor du får denne feilmeldingen vet jeg ikke, du får den iallfall ikke direkte av den koden du la ut. I den koden du la ut får man mange feil. For det første får du feil i:

DataNode top = new DataNode(data);

ettersom du prøver å aksessere (bruke) variabelen "data" som ikke er statisk, så her skulle det stått:

DataNode top = new DataNode(a);

Videre får iallfall jeg en bunch av feil siden du lager alle arrayene dine slik:

int nyData2[][] = {{data[2][1],data[1][0],data[0][2]},{data[2][2],data[2][1],data[1][0]},{data[2][2],data[1]2],data[0][2]}};

(merk [1]2]) men dette er kanskje en feil grunnet kopieringen?

Uansett, videre er det jo opplagt noe galt i denne delen av koden:

if (generations > 0)
	for (int i=0;i<barn.length;i++)
			barn[i].lagBarn(generations -1);
					for(int i=0;i<barn.length;i++)
}

og dersom du fjerner den ekstra "for(int i=0;i<barn.length;i++)" vil du få feil siden "barn[2]" er "null" ettersom du i koden:

		if (data[2][2] == 0) {
		int nyData1[][] = {{data[2][1],data[1][0],data[0][2]},
						   {data[2][2],data[2][1],data[1][0]},
						   {data[2][2],data[1][2],data[0][2]}};
		int nyData2[][] = {{data[2][1],data[1][0],data[0][2]},
						   {data[2][2],data[2][1],data[1][0]},
						   {data[2][2],data[1][2],data[0][2]}};
		barn[0] = new DataNode(nyData1);
		barn[1] = new DataNode(nyData2);
	}

ikke tilordner (setter lik) "barn[2]".

Så det er endel feil og du får videre feil dersom du endrer det over. Men for at det skal være mulig å hjelpe deg må jeg / vi skjønne hva du faktisk vil. Det eneste jeg tror jeg forstår er at du har et program som gjør etter eller annet med en 2x2-array og du har lyst til å lage et program som gjør noe av det samme med en 3x3-array, sant? Og du skal omordne elementene i 3x3-arrayen, sant? Det jeg ikke forstår er hvordan du ønsker at omordningen skal skjer. Det jeg heller ikke forstår er hva som egentlig er poenget, men det er ikke så farlig dersom du er helt presis på hva du ønsker skal skje.

Bare hyggelig

Er bare en liten skrivefeil. Som du ser så finner den en String[][], altså en dobbeltarray av String's, mens den vil ha en String, siden "String" står som returtype i metodedeklarasjonen. Du må dermed skifte returtypen slik:

public String[][] leilighet()
{
return Main.leilighet;
}

For det er det som metoden skal sant, returnere hele dobbeltarray med alle leilighetene?

EDIT: Du fant ut av det selv ser jeg

Hvis du (igjen) fjerne "." etter "return" (som aldri skal ha noe "." etter seg) så fungerer det

Det gjør det

Dersom du vil bruke en statisk variabel i en annen klasse (som du har tilgang til, f.eks. at den er "public" som her), gjør du dette ved å skrive:

<klassenavn>.<variabelnavn>

For eksempel, for metoden:

	public String leilighet()
{
	return.leilighet();
}

som jeg regner med skal returnere selve leilighets-arrayen, skal dette skrives som:

	public String leilighet()
{
	return Main.leilighet;
}

mens for eksempel i testen:

if (leilighet[y][x] == null)

skal det stå:

if(Main.leilighet[y][x] == null)

Forøvrig vil nok mange reagere på kodestilen her, d.v.s. ha en statisk array i en klasse, bruke den og t.o.m. returnere den i/via metoder i en annen klasse. Om du bryr deg om dette er en annen sak

EDIT: Dersom du fjernet "." i leilighet-metoden vil den metoden nå bare kalle seg selv i det uendelige, noe som tvilsomt er det du vil.

Kan du utdype det litt? Legg gjerne ved hele kode i kodeblokker (

) og StackTrace dersom du får en feil under kjøring.

En statisk metode, som main-metoden er, kan direkte* kun kalle på statiske metoder og bruke statiske variabler. Med andre ord, dersom det er arrayen "public String leilighet [][];" som du ønsker å aksessere i main-metoden må du gjøre den statisk, altså skrive:

public static String leilighet [][];

* Indirekte, altså via et objekt, som for eksempel "hybelhus" over, kan en statisk metode også bruke ikke-statiske metoder og variabler.

EDIT: Omformulert.

Problemet er at du bruker hendelsestråden til å eksekvere koden. Hvis du for eksempel tar en kort titt på repaint-metoden du kaller ser du at opptegninga forårsakes av:

Toolkit.getEventQueue().postEvent(e);

som vil si at din oppdatering av tekstfeltet vil vente til eksekveringen av erlik-metoden er fullført siden denne utføres i hendelsestråden (EventQueue).

For å løse dette trenger du en klasse som implementere Runnable (enten direkte eller indirekte via Thread-utviding). Lag så en ny tråd og i den tråden kjører du erlik-metoden.

Hvis du vil ha enkleste løsning skrevet ut er det kun tre små endringer:

1. Kall erlik-metoden for "run", altså:

public void run() {

2. Skrive "implements Runnable" i klassedefineringen, altså:

public class Skjerm extends JPanel implements Runnable {

3. For å eksekvere metoden i en ny tråd skriver du nå:

new Thread(Skjerm.this).start();

"Skjerm.this" kan byttes ut med "this" dersom du er i Skjerm-klassen (og ikke i en indre klasse av den), men "Skjerm.this" fungerer i begge tilfeller.

Du skal forresten ikke behøve å kalle på repaint()-metoden. En annen ting, dersom du til en annen gang er i tvil om hvilken tråd du eksekverer en kodedel i er det bare å skrive:

System.out.println(Thread.currentThread());

Enjoy

Eventuelt kan du bruke:

String s = "" + lagret_tall;

Jeg vil påstå at java er blitt lettere å programmer, ikke vanskligere med hver ny versjon.

Helt enig, det er vel ingen her som har påstått noe annet heller?

Såvidt jeg kan skjønne snakker tmg om to JFrames, ikke JInternalFrames. Men ja, JInternalFrames er fint til sitt bruk, og flott hvis man skal lage et program der f.eks. brukeren skal kunne opprette vinduer (med nye nettsider, dokumenter, bilder, e.l.). Uansett, de fleste mindre programmer har bare et forhåndsdefinert mindre antall vinduer/dialogbokser der bruk av JInternalFrames blir kunstig (mener jeg).

Er ikke gærnt nei, men ofte bare unødvendig. Poenget var at mange roter seg bort i bruk av flere JFrames i program der det egentlig ikke engang er ønskelig å ha flere vinduer, bare dialogbokser. Ikke at det trenger å være tilfelle her da... Men for all del, det er ikke noen galt generelt ved å bruke flere vinduer, og i noen tilfeller er det også ønskelig/nødvendig.

Fikk denne jeg:

Repairs in Progress

The service you're looking for is unavailable at the moment. We'll be back up and running again before long, so please try again soon. Thanks for your patience!

Først har man en JFram el.l som instansierer 1 JFrame til og i den framen kommer det en helt standard JOptionPane boks => programmet tryner.

Ofte ikke nødvendig med mer enn én JFrame, for resten av vinduene vil ofte JOptionPane og utvidelser av JDialog kunne benyttes. Uansett, som pgdx sier, det er vanskelig å kunne gi deg noen gode spesifikke råd uten StackTrace'n.

2-eren er muligens 2-eren i "J2SE" (Java 2 Platform, Standard Edition). Det trenger ikke være snakk om Java 1.2.

 

Men 1999 var vel før selv 1.4 sin tid (versjonen jeg started å lære Java med). 1.4 vil bli regnet som utdatert meget snart. 1.5 har betydelige språkforbedringer (generics, enums, m.m.).

Stemmer, selv Java 1.3 ble lansert så sent som 8. mai 2000, så det er Java 1.2 som blir omtalt i den boka.

Det spørs selvsagt litt hva du skal programmere (i Java) og hvor mye tid du skal bruke på Java, men jeg ville nesten uansett gått for en bok beregnet på Java 1.5 eller Java 1.6. Det finnes mange elektroniske veiledninger til Java hvis du ikke vil kjøe en ny bok. Uansett, per prinsipp angående Java, "Write once, run anywhere", skal din Java 1.2 kjøre i nyere Runtime Environments på alle platformer, så meningsløs kode får du ikke, selv om enkelte ting blir svært tungvint i Java 1.2 (mange av oppdateringene til Java gjør det lettere å programmere og debugge).

Om du har lyst på den ekstra lagringsplassen må du finne ut selv, den ekstra GiB minnet vil nok i normale brukssituasjoner ikke ha noe/mye å si. CPU-oppgraderingen er betydelig, iallfall ifølge denne siden som karakteriserer den første, T2390-CPUen, blant "Budget Processors" som beskrives slik:

"The processors in this bracket are made to perform basic tasks, however, this does not mean that they are not capable of more intensive work. They can run almost any program, but be prepared for longer waits."

mens T7500-CPUen i klassen "Performance Processors" (over "Mainstream Processors") som beskrives slik:

"These processors are the cream-of-the-crop."

Om oppgraderingen er verdt tusenlappen må du jo finne ut av selv. Sett bort fra den ekstra lagrinsplassen vil det nok være en betydelig ytelsesøkning til den dyreste. Hvis du er redd for redusert batterilevetid kan det være greit å få med seg at TDP til T7500 er 34W, mens 35W for T2390, så selv om TDPen ikke sier alt burde det være ganske likt strømforbruk på disse.

Forresten har jeg personlig god erfaring med Elprice, fikk problemer med musa på en bærbar derfra, leverte den inn og nevnte samtidig at batteriet var litt dårlig, da den kom tilbake var musa fiksa, i tillegg hadde de satt inn et nytt batteri.

EDIT: Ser forresten på anmeldelsene av den dyreste at det er flere som klager på viftestøy, det kan hende at støynivået er lavere på den billigste, men trenger ikke siden strømforbruket på CPUene trolig er forholdsvis likt. Uansett, det er jo noe du må tenkte på når du kjøper denne, trolig uansett hvem du velger.

Jeg synes iallfall brevet ser langt bedre ut nå!

Litt småpirk-kommentarer kan være på sin plass likevel:

Igjen, lykke til med saken! Si fra hvordan det går..?

Interessant sak! Håper det går din / forbrukernes vei

Noen kommentarer (ble visst endel ):

Håper det kan være til hjelp Lykke til med saken!

Men, nytt spørsmål. Kan man typekonvertere en int[] til Integer[]?

Nei, men hvorfor/hva vil du?

Autoboxing

Ikke at jeg vet hvordan lassejl's kode er, men som du ser fra den siden du lenket til vil det trolig i de fleste tilfeller være mest effektivt å ikke bruke autoboxing og unboxing:

It is plenty fast enough for occasional use, but it would be folly to use it in a performance critical inner loop.

Meget skuffende resultat tho, beste er 0.078sec på 1mill tall, samme som før. Kjørte på 1 tråd med dual core cpu. Lurer litt på hvorfor 1 tråd går fortere enn 2 (0.109sec) på dual core men, er det slik at main metoden opptar en tråd eller noe?

Main-tråden, den tråden JVM lager når den kaller på din main-metoden, er også en tråd ja. Så dersom du lager da to nye tråder vil programmet ditt ha totalt 3 tråder (egentlig kjører også GC på egen tråd, kanskje også flere). Poenget er imidlertid at prosessorer har tradisjonelt sett blitt designet for å takle og kjøre flere tråder parallelt (teknisk er det bare litt fra en tråd så litt fra annen tråd så litt til kanskje på den først, fordelingen her er det OSet som tar seg av). Siden main-tråden ikke gjør noe, eller bare ekstremt lite, for eksempel at den bare står og venter, vil ikke denne "oppta" en kjerne, for det er ingen tråder som har enerett på en kjerne. Omvendt er det derimot (så vidt jeg vet iallfall), en tråd vil bare kjøre på en kjerne.

Det man må passe seg for er at det ikke er mange flere tråder som ønsker å bruke all kapasitet av en kjerne enn man har kjerner i systemet. Altså, hvis du har en dobbelkjerner, er det OK å lage to tråder som sorterer, selv om det teknisk er flere tråder som JVM kjører, men det er dumt å lage flere beregningstråder enn dette. Likevel, siden prosessor-forbedringene før flerkjerneteknologien ble en realitet for mannen på gata brydde seg om å optimalisere bruk av flere tråder på en kjerne, vil man ikke merke noen betydelig forskjell ved for eksempel å lage tre beregningstråder. Men ved å gå opp til 10 er det merkbart, og med 100 blir det bare idioti. Jeg lagde et tilsvarende lite testprogram som viser dette:

Forresten, dersom du prøver å sortere litt flere tall og finner at programmet ditt ikke kjører raskere med to tråder på en dobbelkjerne enn med en tråd på samme prosessor er det trolig noe galt. Det kan for eksempel være at du har synkronisert sorteringsmetoden (da kan bare en sorteringsmetode kjøre om gangen).

Hvis du fortsatt får den feilen kan du prøve å bruke -Xmx opsjonen når du kjører programmet. Den setter den maksimale grensen av minne JVM kan bruke. Som standard står den på 64MB, hos meg kan jeg sette den opp til like over 1610MB. (bruk for eksempel java -Xmx256m -jar MyJarFile.jar)

Ok Da er det O(N^2) hvis du lurte..

Den heap space erroren skyldes jo bare at JVM ikke blir tillatt / ikke ønsker (er kanskje noen innstillinger man kan endre?) å tildele programmet mer minneplass.. Grensen for hvor mange tall ditt program kan sortere avhenger av om du lager kopier av tallene eller ikke, men et sted vil grensen gå uansett.