javanuben

Hva er det du ikke skjønner? Fortegnsskjema? Ta isåfall en titt her.

Husk at:

Løs

3x² - 3 = 0 med hensyn på x.

Du vil da få en eller flere gyldige verdier for x. Dette vil være topp- og bunnpunktene.

For å finne ut hvilken verdi som er hva, kan du drøfte f'(x) i et fortegnsskjema.

EDIT: Typo

Deriver ledd for ledd med den vanlig regelen:

f(x) = x^a => f'(x) = a*x^a-1

Sett så f'(x) = 0 og løs mhp. x.

Hint: 3er-logaritme.

Må si at jeg fortsatt står fast...

Du kan ta logaritmen på begge sider av likhetstegnet. Bruk så: log₃(3^x) = x

Hint: 3er-logaritme.

Kanskje ikke akkurat det du spør om, men det finnes andre måter i implementere undo på, som er mye mer effektiv. Hvis du f.eks. bare lagrer bevegelsesretning og om du dyttet på noe, så er det smal sak å "reversere" brettet til slik det var før forrige trekk (tastetrykk).

Er avsatt en uke før fellesprosjektet hvor vi skal gjøre øvinger, men ikke noe før det.

Hvordan teste programmet:

1. Lagre .jar-filen hvor som helst på de to maskinene som skal synkroniseres.

2. Start programmet i cmd med:

java -jar [filnavn.jar]

3. Skriv følgende for å få generert en tom filliste:

generate file_list

4. Legg så til filene du vil synkronisere på følgende måte:

add_file [filnavn]

(Ja, dette er forholdsvis tungvindt foreløpig, men det blir bedre når jeg får ordnet GUI.)

5. Når du er ferdig med å legge til alle filene, "linker" du de to PCene sammen ved å skrive følgende i et av programmene:

set_ip [den andre PCens IP-adresse]

6. Skriv så følgende for å få synkronisert fillistene:

sync file_list

Følg så anvisningen på skjermen når du blir spurt om filstier til de nye filene osv.

7. Følgende kommando synkroniserer filene på fillisten(e):

sync files

8. Sleng så igjen en kommentar i kommentartråden om hvordan det gikk!

Merk: Hvis du gjorde 5-7 kun med den ene PCen, er det kun den som har fått den andre PCens filer.

For å synkronisere begge, må du gjenta de samme stegene på den andre PCen (eller gjøre det via 'send_command ...' (se commands.txt på github for mer info)).

Syntes du dette var tungvindt? Sleng igjen en kommentar i kommentartråden da vel!

Har nå testet og fikset, testet og tweaket, og testet og fikset litt mer. Jeg har lagt til en del ny funksjonalitet, og (skapt og) fikset en hel haug med bugs, men nå ser det ut til at synkroniseringen av filer fungerer (relativt) smertefritt. Jeg kommer dog til å fortsette testingen, samtidig som jeg jobber meg igjennom TODO-listen min, så får vi se om jeg snart drister meg over til GUI-utforming eller noen av de andre hovedpunktene (i førstepost) snart.

Ting som er lagt til/endret:

ø Executor.loadFilesToSynchronize kaller nå Executor.updateLastModified før den gjør noe annet (slik at man ikke trenger å gjøre dette manuelt).

ø Flyttet konflikttesten over til en egen medlemsfunksjon: FileElement.isConflict

ø Skriv en metode for å legge en fil til fillisten (Executor.addFileToFile_list).

ø Finne en god måte for å tilordne id-er til nye filer på (Executor.getNewFileID). (Se nederst i posten for mer informasjon.)

ø Skriv en metode som fjerner en gitt fil fra fillisten (Executor.removeFileFromFile_list).

Fiksede bugs:

ø Filer blir i blandt loadet (med Executor.loadFilesToSynchronize) uten at de egentlig skal det.

ø Filer blir (feilaktig) loadet hvis de ble endret og synkronisert samtidig.

ø Ved f.eks. Executor.synchronizeFiles og Executor.synchronizeFile_list terminerer ikke Executoren (eller metoden) selv om det skjer en feil når man prøver å connecte.

ø Hvis man connecter feil (eller til null) for å synkronisere filene, telles filene som synkronisert, selv om de ikke er det.

ø Ved valg av 'overwrite' ved en konflikt (i Executor.mergeFile_lists) blir ikke den gamle linjen i fillisten fjernet/endret. (Det blir bare lagt til en ny linje med den andre filen.)

ø Filer som ikke blir synkronisert forsvinner fra file_list når lastSynchronized oppdateres (Executor.synchronizeFiles). (Problemet er at fillisten blir skrevet over med de linjene som tilsvarer de filene som blir synkronisert. Løses enkelt ved heller å gå igjennom alle linjene i fillisten og oppdatere lastSynchronized for de filene som blir synkronisert, istedet for å overskrive hele filen.)

ø Visse linjer blir overskrevet i fillisten hvis fillisten merges flere ganger uten at filene blir synkronisert, og fillisten(e) inneholder nye filer. (Problemet var at jeg fjernet alle de nye filene fra fillisten i starten av Executor.mergeFile_list, for å løse id-konfliktene, men jeg glemte å legge de som ikke fikk ny id tilbake igjen.)

TODO:

o Være litt mer nøye på hvilke metoder som er static, og hvilke som ikke er det.

o Håndtere feil i fillisten(e)

o Lage en metode som lar brukeren vise innholdet i fillista i konsollen.

o Lag en test på om vi får konflikter mellom id-er.

o Lag en "bedre" måte å drepe Executors på. (Hvordan gjøre dette med en Executor som bare lytter på en port? -La en annen Executor koble til porten for å få Executoren til å "gå videre"?)

o Fjerne/Fikse unødvendig spamming av System.out.

o Behandle exceptions litt bedre (kast de videre til Executoren, istedet for å behandle alle der de oppstår).

o Forbedre Executor.synchronizeFiles og Executor.sendFile til å sende flere filer samlet, istedet for å sende en og en (noe som innebærer at programmet må lete igjennom file_list for å finne id og path hver gang).

o Undersøke (og eventuelt fikse) om programmet overskriver filer ved synkronisering av nye filer.

o Lage en mulighet for å endre på fillisten.

o La brukeren velge navn på fil, hvis han velger 'keep both' for en konflikt.

o La programmet slette temp-mappen når programmet stoppes (evt. la bruker velge om den skal slettes eller ikke).

o Legge til støtte for å ha forskjellige filnavn (på forskjellige PCer) for samme fil.

o Lage en sjekk på om fila som skal sendes eksisterer i FileSender.

o Legg til en help-kommando.

Bugs:

o Visning av IP blir ikke alltid riktig (f.eks. vises VirtualBox sin IP noen ganger). (Her trenger jeg hjelp! Forslag og hint mottas med takk i kommentartråden!)

o Closingen av sockets i FileReceiver fungerer ikke som planlagt... (Har innført en midlertidig løsning ved å duplisere (fy!) litt kode for å stenge socketene, men en mer elegant løsning er ønskelig. (Et av problemene ved den gamle løsningen var at Socket-objekter av en eller annen grunn ikke ble gjenkjent som "closeable", selv om Socket implementerer java.io.Closable (kilde)))

o lastModified2 kan bli oppdatert (satt > 0), selv om den ikke finnes på den andre PCen, og lastSynchronized er lik 0. (Sliter dog med å gjenskape hendelsen.)

Hvordan blir fil-id-ene organisert?

Hvis det er nye filer som skal bli synkronisert på bare én av PCene, er det rimelig rett frem, og filene blir bare tildelt neste ledige ID.

Er det derimot nye filer på begge PCene, blir det nødvendigvis konflikter (siden begge bruker samme algoritme til å generere ny ID). Det som da skjer, er følgende:

Når programmet mottar fillisten fra det andre programmet, blir de nye filene der kopiert direkte inn i fillisten. Deretter sjekkes det for ID-kollisjoner (dvs. at to filer har samme ID). Når slike kollisjoner oppdages, får filene fra den gjeldende PCen generert nye IDer, etter at fillisten med de nye mottatte filene er lagret, slik at de samme IDene ikke blir generert om igjen.

Jeg legger også ved nyeste test build for de som vil teste programmet. Siden det foreløpig ikke er veldig rett fram å bruke programmet, poster jeg en liten "tutorial" i neste post (for å prøve å holde det ryddig).

Nyeste versjon: test-build-130112_2.zip

Github er som vanlig(?) oppdatert!

Nå har prosjektet vært i gang en liten stund igjen, og det er derfor på tide med en oppdatering.

Ting som er lagt til/endret:

Jeg har brukt mye tid på å teste og fikse på forskjellige metoder. Noen av de viktigste endringene er listet opp her:

ø Fikset sånn at temp-mappen blir laget hvis den ikke eksisterer når Executor.ReceiveFile_list blir brukt.

ø Endret Executor.synchronizeFile_lists til å sende en spesialkommando ('syncing'), istedet for å sende to kommandoer etter hverandre ('set_ip #IP' og 'send file_list false'). Synkroniseringen av fillistene skal derfor fungere som planlagt nå.

ø Endret Executor.mergeFile_lists slik at det eneste den gjør er å legge til filer som mangler, og oppdatere lastModified2.

ø Endret Executor.loadFiles til å finne ut hvilke filer programmet trenger å få tilsendt (ut fra lastModified og lastModified2), for så å "loade" filene. (Dette innebærer også å behandle konflikter.)

ø Oppdaterte javadoc om endringene i Executor.mergeFile_lists og Executor.LoadFiles.

ø Lagde en metode som genererer en tom filliste.

ø Teste om Main "får tilbake" reader etter at Executoren er ferdig med å hente input (evt. fikse dette hvis det ikke fungerer) - Se under "Bugs som er fikset".

ø Oppdater lastSynchronized når filer blir synkronisert.

Bugs som er fikset:

ø Fikset en bug i Executor.mergeFile_lists hvor lastModified og lastModified2 på "nye" filer ble byttet om.

ø Fikset en bug som gjorde at lastModified2 ikke ble oppdatert som den skulle i Executor.mergeFile_lists.

ø Main ser ikke ut til å få tilbake reader etter at en Executor har hentet input. Dette me fikses!! - Oppdatert: Feilen er at Executoren fortsatt står som waiter, selv om den har fått det den ventet på. - Oppdatert: Løst ved å endre fra get(0) til renmove(0) i Main.getNextUserInputWaiter.

ø Ved 'sync files'/'load files' skal ikke programmet prøve å få tilsendt filer som ikke er på den andres filliste (og heller ikke filer som ikke trenger å bli oppdatert). (Fikset ved å sjekke om lastModified2 er lik 0.)

Nå ser det ut til at programmet er i stand til å utføre kjerneoppgavene som planlagt (synkronisere fillistene og overføre de nødvendige filene). Deler av dette er dog relativt utestet, og derfor får testing høyeste prioritet nå.

I tillegg har følgende oppgaver rimelig høy prioritet (oppsummert fra tidligere poster + nye oppgaver):

Ting som må gjøres:

o Lage en metode som lar brukeren vise innholdet i fillista i konsollen.

o Finne en god måte for å tilordne id-er til nye filer på.

o Lag en test på om vi får konflikter mellom id-er.

o Lag en "bedre" måte å drepe Executors på. (Hvordan gjøre dette med en Executor som bare lytter på en port? -La en annen Executor koble til porten for å få Executoren til å "gå videre"?)

o Fjerne/Fikse unødvendig spamming av System.out.

o Behandle exceptions litt bedre (kast de videre til Executoren, istedet for å behandle alle der de oppstår).

o Forbedre Executor.synchronizeFiles og Executor.sendFile til å sende flere filer samlet, istedet for å sende en og en (noe som innebærer at programmet må lete igjennom file_list for å finne id og path hver gang).

o Undersøke (og eventuelt fikse) om programmet overskriver filer ved synkronisering av nye filer.

o Lage en mulighet for å endre på fillisten.

o La brukeren velge navn på fil, hvis han velger 'keep both' for en konflikt.

o La programmet slette temp-mappen når programmet stoppes (evt. la bruker velge om den skal slettes eller ikke).

Bugs:

o Visning av IP blir ikke alltid riktig (f.eks. vises VirtualBox sin IP noen ganger).

o Closingen av sockets i FileReceiver fungerer ikke som planlagt... (Har innført en midlertidig løsning ved å duplisere (fy!) litt kode for å stenge socketene, men en mer elegant løsning er ønskelig. (Et av problemene ved den gamle løsningen var at Socket-objekter av en eller annen grunn ikke ble gjenkjent som "closeable", selv om Socket implementerer java.io.Closable (kilde)))

o Filer som ikke blir synkronisert forsvinner fra file_list når lastSynchronized oppdateres (Executor.synchronizeFiles). (Problemet er at fillisten blir skrevet over med de linjene som tilsvarer de filene som blir synkronisert. Løses enkelt ved heller å gå igjennom alle linjene i fillisten og oppdatere lastSynchronized for de filene som blir synkronisert, istedet for å overskrive hele filen.)

o Ved valg av 'overwrite' ved en konflikt (i Executor.mergeFile_lists) blir ikke den gamle linjen i fillisten fjernet/endret. (Det blir bare lagt til en ny linje med den andre filen.)

Ser forøvrig at "The Sigma Project"-navnet allerede er i bruk, men siden det bare er en arbeidstittel lar jeg den stå.

Oppdateringene blir tilgjengelig på github i løpet av dagen!

Sette stor pris på kommentarer. Både om prosjektet, koden og ikke minst om loggskrivingen min.

Edit: Har nå fått oppdatert klassene på github, samt lastet opp en not-so-up-to-date liste over kommandoer (commands.txt). Denne kan brukes for de som av en eller annen grunn har lyst til å teste programmet. En kjørbar jar-fil kan lastes ned her: test-build-120112_3.zip

(For problemer eller spørsmål, vennligst bruk kommentartråden. Kommer nok også til å skrive en kort guide om hvordan programmet kan brukes via cmd for de som synes at commands.txt ikke er nok.)

Stor forbedring i forhold til den gamle siden. Godt jobbet!

En ting som dog ser litt smårart ut er den dato-knappen på "Bestilling/forespørsel buss", den er ikke på linje med de andre feltene, noe som jeg synes hadde vært mer naturlig. (Er slik i både nyeste Chrome og IE for meg.)

På sparket kommer jeg ikke på noe "konkret" den lar deg gjøre, som du ikke på annet vis får gjort. Men den gjør (etter min mening) kode mye mer leselig, ved at den forteller at denne metoden kalles på dette objektet, eller denne variabelen er en medlemsvariabel osv.. Enn om du f.eks. kaller en metode "ut fra løse luften".

Hovedbruken (rett meg hvis jeg tar feil) til "this" er vel å la deg bruke "shadowed" felter, som i eksemepelet mitt over, eller lignende.

"this" kan vel også brukes til å kalle andre konstruktører inne den samme klassen. Står litt mer om det her.

this er en peker til objektet du er i. (Litt dårlig formulert kanskje?) Ta følgende eksempel:

public class MyClass {
private String name;

public MyClass(String name) {
	name = name;		// Denne vil ikke gjøre særlig mye
	this.name = name;	// Denne vil sette medlemsvariabelen name, til innholdet i variabelen name (argumentet)
}
}

Konstruktørene nedenfor, derimot, gjør akkurat det samme, men det kan argumenteres for at den første er mer lesbar:

public MyClass(String n) {
this.name = n;
}

public MyClass(String n) {
name = n;
}

[...]

Kjapt spørsmål: Hva er den enkleste måten å finne når den retningsderiverte er lik null?

 

Det kommer vel nesten litt an på tror jeg. Har du en spesifikk oppgave?

Oppgave 4

 

Finn først gradientvektoren i punktet (1,1). Den blir ett eller annet, la oss si (a,b). Den retningsderiverte er definert som skalarproduktet mellom gradienten og enhetsvektoren som peker i ønsket retning. Du ønsker å finne hvilken vektor du må prikke gradientvektoren med for å få 0. Når du har en vektor (a,b) så vil de to vektorene som står vinkelrett på denne være (b, -a) og (-b, a), siden og . Bruk dette for å finne de to vektorene som gir 0. Husk så at skal være enhetsvektor.

Det var ikke verre nei.. Takk for hjelpen!

[...]

Kjapt spørsmål: Hva er den enkleste måten å finne når den retningsderiverte er lik null?

 

Det kommer vel nesten litt an på tror jeg. Har du en spesifikk oppgave?

Oppgave 4

Kjapt spørsmål: Hva er den enkleste måten å finne når den retningsderiverte er lik null?

Ok, takk for svar!

Det er altså trygt da?

Vil jeg merke forbedringer i ytelse?

Hei!

I BIOS står "Memory Frequency (Mhz)" satt til "Auto", og under står det "1333".

Jeg har følgende HW:

Hovedkort

RAM

Burde det ikke da bli satt til 1600 med auto? Evt. hvorfor ikke?

Og er det trygt å "tvinge" den til å bruke 1600? Hva kan evt. gå galt?

Mange dumme spørsmål her kanskje, men har ikke særlig mye kunnskap om slikt, så synes det er best å spørre før jeg gjør noe drastisk

Da er den bestilt! Takk for kommentarene, begge to!

Takk for svar, olestokk, da går jeg for denne, hvis det ikke er noen som har bedre forslag.

Hva synes dere om dette oppsettet fra Komplett? Vil det kjøre spill som BF3 brukbart, og er det en grei pakke til prisen (med tanke på disse dagers hardiskpriser)?

Er klar over at det ikke følger med OS.

Han blir født på ny, som alle mennesker

Takker

 

Jeg rollet nettopp en thief, stjeler ofte, og i det siste har jeg fått en del thugs etter meg. Leste på brevet at er vakter fra whiterun(der jeg er verst) som har sendt dem. Gjør de det fordi de ikke har noe bevis for å fengsle meg? og hvis de ikke så meg gjøre det, hvordan kan de vite noe?

 

Edit: Når jeg har fått 100 i smith, og har valgt perkene på venstre siden(light armor) og unlocka dragon armor, kan jeg bruke bare 1 perk for å få daedra? Siden det er linket til drage armor, eller må jeg unlocke Dwarven, orcish og ebony armor først?

Du må nok unlocke dwarven, orcish og ebony før daedra, selv om du har dragon-perken, sånn som jeg har forstått det.

Dragene burde vært sjeldnere og sterkere etter min mening.. Slik at å drepe en drage hadde vært litt mer "spesielt", ikke bare noe du må gjøre for å få lov til å bruke fast travel.