toddy23

Like greit å lage en kombinert test slik drange skriver (så slipper du to nøstede if-tester), og bruke for-løkke. While er så tungvint i forhold.

7461838[/snapback]

 

Joda, kom bare med et eksempel. Skriver automatisk while i stedet for for av en eller annen grunn, men det er opp til den enkelt. Testklassen tok meg forøvrig ca. 10 minutter å skrive

 

Edit: etter en kjapp omskriving kan det også gjøres slik:

 

private int findSongPos(String songName, String artist){
    for (int i = 0; i < songList.length; i++){
        if(songList[i] == null){}
        else{
            if(artist.equals(songList[i].getArtist()) && songName.equals(songList[i].getTrackname())){
                return i;
               }
           }
       }
       return -1;
   }  

7461857[/snapback]

Jeg hadde skrevet continue inne i de tomme klammene, forløkken vil da fortsette med neste iterasjon.

Kjøpte textmate. Konge program. At det kostet 39€ gjør meg ingenting. betaler gjerne for gode programmer.

Antar at det er mulig å lage en thread som kjører inni en prosess. Hvordan får man til dette? noen som kan komme med et enkelt eksempel eller vise med videre et sted man får greie på dette.

 

Har lest litt på google, det meste var litt avansert, og mye unødig kode innvolvert.

7029636[/snapback]

Ofte kan det være enklest å slå opp i api-et Tråd i java 5.

Ikke noe problem. Bra vi kom til enighet.

Stemmer du har rett Mr.Garibaldi. Min feil, den rekursive metoden min var ikke halerekursiv. Jeg skrev en ny en som jeg vet er halerekursiv med og den gir nesten de samme tidene som den rekursive. Altdå 2 ganger tregere Både med java og gcj.

static int fakTail(int n, int accumulator)
{
    return n == 1 ? accumulator : fakTail(n-1, accumulator * n);
}

Har nå prøvd å kompilere med gcj, jeg ser fortsatt at den rekursive bruker ca 2 ganger mer tid.

Med mindre jeg har gjort en blunder i koden, tror jeg dere må gi dere på denne. Testen nedenfor er kjørt på en 2.4 p4 med ubuntu

Java 5 sun

javac Fak.java

:~java Fak

1091 2495

:~$ java Fak

1093 2411

:~$ java Fak

1090 2416

:~$ javac -O Fak.java

:~$ java Fak

1092 2493

:~$ java Fak

1090 2409

:~$ java Fak

1089 2411

Gcj

:~$ gcj-4.1 --main=Fak Fak.java

:~$ ./a.out

3276 4606

:~$ ./a.out

3294 4597

:~$ ./a.out

3294 4591

:~$ gcj-4.1 --main=Fak -O2 -g0 Fak.java

:~$ ./a.out

883 2214

:~$ ./a.out

884 2213

:~$ ./a.out

885 2215

Fak.java

public class Fak{

       static int fak(int n){
               for(int i = n; i > 2; n*=--i);
               return n;
       }

       static int fakRek(int n){
               return n == 1 ? n : n * fakRek(n-1);
       }

       public static void main(String[] args){
               long result1 = 0, result2 = 0;
               long start;

               start = System.currentTimeMillis(); 
               for(int i = 0; i < 10000000;i++) fak(19);
               result1 += System.currentTimeMillis() - start;

               start = System.currentTimeMillis(); 
               for(int i = 0; i < 10000000;i++) fakRek(19);
               result2 += System.currentTimeMillis() - start;

               System.out.println(result1 + " " + result2);
       }
}

Grunnen til at man ikke bør bruke halerekursjon er at de kan skrives om til løkker og løkker bruker mye mindre minne enn rekursjon.

En god kompilator burde klare å detektere halerekursjon og generere den samme koden. Dette er forholdsvis grunnleggende kompilator-optimalisering.

 

Det finnes språk som ikke har konstruksjoner for løkker, der standarden krever at halerekursjon skal optimaliseres. Scheme er et eksempel på et slikt språk.

7011883[/snapback]

Send en mail til Sun da, java 5.0 optimerer ikke bort halerekursjon, bare test løsningsforslaget mitt ovenfor. Hos meg brukte maskinen over dobbelt så lang tid på å bruke halerekursjonen i forhold til den med løkken og det ved bare 19 rekursive kall. Jeg vil anta at forskjellen vil bli større jo flere kall som blir gjort. Hvis du vil motbevise påstanden min ovenfor om bruk av minne og kjøretid, kan du legge ut et eksempel som jeg kan kjøre.

Foresten heter slike språk som du refferer til Funksjonelle språk, og der er man tvunget til å benytte rekursjon for løkker. Har selv programmert ml som også er et funksjonellt språk. Føler foresten at hele diskusjonen har vandret ganske langt bort fra tråden.

takk takk, skal teste litt ut.

På denne siden finner du ferdig oppsatt Eclipse med til de tingene du lister opp. De har også en liste over de ulike pluginsene de har brukt i de forskjellige versjonene.

Easyeclipse

Grunnen til at man ikke bør bruke halerekursjon er at de kan skrives om til løkker og løkker bruker mye mindre minne enn rekursjon. Hver gang en ny metode kalles via rekursjon må variablene dyttes på stakken. Det trengs ikke i en løkke.

Nedenfor har jeg pastet en link til wikipedia som forklarer litt mer detaljert hvorfor.

Wp:Tail recursion

stemmer du har rett, man trenger ikke bruke returverdien av en ? : man kan kalle slik du har vist

nesten riktig den fungerer som følger

variable = (boolsk uttrykk) ? (hvis true tilordne denne) : (hvis false tilordne denne)

bare tenkte jeg skulle lage 2 eksempler som regner ut fakultet som fungerer. Mr.garabaldis kode kompilerer ikke og er et dårlig eksempen på en rekursiv metode, men som sagt ikke finn på å bruke min rekursive metode heller, det beste ang ytelse er å skrive noe som ligner på den for løkken jeg laget.

Ps. trådstarter spurte jo etter en metode som multipliserer sammen tallene fra 1 til n. Begge metodene mine gjør det.

Noen som vet om noen gode gratis ruby editorer?

Bruker OSX og linux, er ikke glad i vim eller emacs.

Halerekursjon er en uting og bør ikke brukes. Men bare på gøy lager jeg en, som dere ser bruker fakRek bare en parameter

Ikke rekursiv

public class Fak{

static int fak(int n){
 for(int i = n; i > 2; n*=--i);
 return n;
}

static int fakRek(int n){
 return n == 1 ? n : n * fakRek(n-1);
}

public static void main(String[] args){
 System.out.println("Fak 8 = " + fak(8) + " = " + fakRek(8));
}
}

edit: la til den rekursive løsningen

kjøp en bærbar uten glossy skjerm, glossy skjermer plager alle som sitter bak deg hvis du har tenkt å bruke den på skolen