Jaffe

Noen som kunne være så greie å hjelpe meg med følgende ulikhet?

 

ln(x+1)+ln(x+3)<ln(x+7)

 

Svaret skal bli -1<x<1, men jeg klarer absolutt ikke å få det svaret og jeg skjønner ikke hvorfor. Syntes det virket som en veldig lett ulikhet først, men nå vet jeg ikke helt...

Her er det flere måter å gå frem på, men vi kan f.eks. opphøye med e som grunntall på begge sider. Vi får da:

Poenget med dette er at når vi opphøyer e i logaritmen til et tall, så får vi det tallet:

Jeg vet ikke om det var dette du gjorde, men nå kan du i alle fall gå videre med å samle alt på én side, rydde opp, og faktorisere. Deretter kan du vurdere hver faktor for å se når produktet blir mindre enn 0, f.eks. i et fortegnsskjema.

Er det noen som kan forklare meg hvordan jeg regner ut tredgradsligning?

 

F.eks X^3 - X^2 -4X + 4 = 0

Prøv å finne en løsning ved å prøve og feile, altså en verdi for x som er sånn at når du setter den inn på venstre side, så får du 0. Begynn f.eks. med 0, så 1, 2 osv. Når du har funnet denne verdien kan du benytte polynomdivisjon til å faktorisere venstresiden. Det er slik at hvis du fant en løsning x = a, så vil du kunne dele venstresiden på (x-a). Andregradspolynomet du da ender opp med kan du finne nullpunktene til slik du antageligvis er kjent med fra før.

 

 

 

 

Hei!

 

Skal løse følgende grenseverdi:

 

lim sigma(sum) fra i=0 til i=n for sin(i*pi/i)

n->uendelig

 

Jeg løste de ved å se på det som en Riemannsum, for deretter å finne minste og største verdi for (i*pi/i), som da blir 0 og pi(stryker n over og under brøkstreken). Integrerer sinusuttrykket, og løser det bestemte integralet fra pi til 0 for -cos (x) og får to som svar. Er dette riktig fremgangsmåte?

Noen som vet?

 

 

Jeg tror ikke du har skrevet det riktig. sin(i*pi/i)=sin(pi)=0. Dermed er denne summen 0.

 

Men må jeg ikke integrere uttrykket, da? Cos(pi)=cos(0)=1

 

 

Er jo ikke vits i å integrere uttrykket når man med en gang ser at summen er 0.

 

Edit: Faktisk ble jeg litt usikker på om man kan si at den summen er 0. sin(pi*i/i) er jo ikke definert når i=0, altså i første ledd. Vil det si at summen ikke er definert?

 

Edit2: Både Wolfram og Maple sier summen er 0. Hva er feil med tankegangen min?

 

Det kan være Wolfram og Maple forenkler uttrykket før de beregner summen. Da får vi jo 0, som du forklarte i sted. Slik det står nå har vel summen strengt tatt ikke en verdi, siden det blir 0 i nevner.

Du må se på hver av de tre egenskapene. At en relasjon er refleksiv vil si at for alle . Siden er dette åpenbart sant. Se tilsvarende på de to andre. Hva vil det si at en relasjon er symmetrisk, transitiv?

Når det gjelder den geometriske følgen/sekvensen så er det som the_last_nick_left sier litt forskjellige navn på ting, men det du trenger for å entydig bestemme en slik følge er det første tallet og kvotienten. Det første tallet her er jo 4, så det er greit. Deretter får vi som du sier neste tall ved å gange med 3, så kvotienten må være 3.

Jeg kan ikke se noe galt i beviset ditt. Hva er det løsningsforslaget gjør? Husk at det ikke er noe "svar" i slike oppgaver som dette; en annen metode kan føre til andre sammenhenger mellom og .

Her er noe jeg brukte deler av gårsdagen og i dag på:

Igjen ganske 80-tallsinspirert (hørt mye på A Flock of Seagulls i det siste...), veldig enkel låt som kanskje blir litt kjedelig i lengden (vers/refrens/vers-strukturen er ganske forutsigbar), kom ikke på noe mer heller.

Jeg har startet på et "lite" sideprosjekt nå (litt inspirert av SID/APU-diskusjonen ovenfor), der jeg har tatt en 2A03-chip (CPU/APU-chippen i NES-en) og koblet den til en mikrokontroller (en Atmega168 for øyeblikket). Målet er å lage en liten synth basert på APU-en. Siden APU-en ikke er eksternt kontrollerbar, har det ikke vært helt trivielt å styre den fra mikrokontrolleren; det må gjørs via CPU-en. Det som skjer er at mikrokontrolleren sender CPU-en instruksjoner, som i sin tur manipulerer APU-en. CPU-en tror den kjører et program, men i realiteten mates den med instruksjoner fra mikrokontrolleren.

Så langt har jeg fått kommunikasjonsgrensesnittet opp og gå (alle kanaler kan manipuleres uten bugs etc.) og bygd et abstraksjonslag over dette som gjør det lett å manipulere lydkanalene i C-kode på mikrokontrolleren. Jeg har også implementert envelope-generatorer og LFO-er som kan modulere volum/frekvens på kanalene. Målet videre er å lage et MIDI-grensesnitt så den kan kontrolleres eksternt, og hvis jeg har tid og ikke mister interessen, et skikkelig produkt med et frontpanel for å endre parametere osv. (noe lignedne SIDstation)

Se mer om prosjektet her.

Fin artikkel. Tror mange ikke er klar over hvor enormt viktig transistoren har vært!

Men "Grunnlaget for all teknologi" er kanskje å ta litt sterkt i? En veldig viktig bit av grunnlaget for den moderne elektroniske teknologien vi har i dag, men på andre områder (biler, fly, whatever) har jo utvikling innen materialer og produksjonsprosesser vært vel så viktig. EDIT: Ser dere endra på overskriften nå.

Savner også at radiorør nevnes, de var jo transistorens forgjenger, og opererte etter det samme prinsippet som nevnes innledningsvis. Man hadde jo elektriske forsterkere og digitale datamaskiner også før transistorens tid, så grunnlaget var jo sånn sett allerede lagt.

 

Feil. Programmene bruker virtuelle adresser. En av de viktigste oppgavene til et moderne OS er nettopp å oversette virtuelt minne til fysisk minne. Det er noe OS-et gjør, ikke en underliggende firmware (BIOS/EFI/etc). BIOS har også lite med hvordan hardware er mappet til minneområdet, men kan som sagt konfigurere noen av disse tingene ved oppstart.

Nei her blander du kortene. Det du snakker om er paging, som gjøres av kernel etter bootstrapping og bytting til pmode, hvor hvert enkelt program får sine virtuelle minneadresser som oversettes direkte av CPUen. Dette har åpenbart ingenting med BIOS å gjøre, og er heller ikke hva jeg sikter til.

 

Det jeg snakker om er minneadressene til enheter som brukes til kommunikasjon. Her er et eksempel fra en av mine PCer:

01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 2822
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 88
	Region 0: Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at f0000000 (64-bit, prefetchable) [size=128M]
	Region 3: Memory at f8000000 (64-bit, prefetchable) [size=32M]
	Region 5: I/O ports at e000 [size=128]
	[virtual] Expansion ROM at fb000000 [disabled] [size=512K]
	Capabilities: <access denied>
	Kernel driver in use: nvidia

Jeg får gjenta det jeg sa i sted; denne uenigheten handler om begreper. Mange mener faktisk det du kaller "IBM BIOS" når de snakker om BIOS. Det er vanlig å kalle det du kaller for BIOS for "firmware". Inn under det begrepet ligger da både BIOS ("IBM BIOS"), EFI og det man finner i diverse embedded-platformer. Hvis vi ser bort fra disse begrepsuenighetene så er vi vel alle egentlig enige i denne tråden.

At folk bruker begreper ulikt/feil endrer ikke på det faktum at UEFI er en type BIOS, og at flertallet av datamaskiner bruker én eller annen form for BIOS (pluss eventuell firmware). F.eks. dagens Intel-CPUer har en egen firmware som lastes av BIOS.

 

Hvis vi med BIOS mener et generelt "basic input output system", og ikke en firmware som er kompatibel med IBM BIOS-en, så kan vi si at EFI er en type BIOS, ja. Hvis ikke kan vi jo selvsagt ikke det - så nei, det er ikke et faktum, og det er utelukkende pga begreper.

Jeg vil si du blandet kortene ved å introdusere virtuelle adresser her - de har ingenting med saken å gjøre. Adressene til systemkomponenter settes i stor grad opp i hardware (hvordan tror du BIOS selv finner frem til ting?). Jeg vet ikke om du blander med PCI-enumerering her, men det er også noe som godt kan gjøres av OSet.

 

Ingen moderne operativsystem bruker BIOS for å kommunisere med maskinvare, nei. Tildeling av minneadresser, hvor har du det i fra? Minneadressering er ekstremt komplisert i en moderne x86-maskin, men det gjøres i hardware (chipsettet og kretsdesignet i hovedkortet), ikke av BIOSen. Noen aspekter ved hvordan dette skjer kan konfigureres i BIOS/EFI/firmware/whatever, men det har ingenting med BIOS i seg selv å gjøre.

Her tar du grundig feil. Operativsystem og drivere bruker virtuelle minneadresser for å kommunisere med enheter, disse adressene befinner seg utenfor maskinens fysiske minneområde og er reservert av BIOS. Du husker kanskje tilbakke til XP(32-bit) som typisk kun kunne bruke rundt 3.25-3.75 GB av 4GB minne. Mange har mistolket dette som reservert minne til integrert grafikk men det er ikke det jeg snakker om her. Alle hovedkort har nemlig reservert et minneområde i øverste del av adresseområdet, og størrelsen til området varierer med tilkoblingsmulighetene til hovedkortet. Noen hovedkort kan ha bare et par hundre MB reservert, mens andre har mye mer. Drivere "skriver" og "leser" til disse minneadressene for å kommunisere med enhetene, enten det er skjermkort, diskkontrollere eller USB. Hvis du kjører Windows kan du se på enhetsbehandling hvilke slike områder som er aktivert for hver enkelt enhet. I Linux og UNIX er disse synlige som virtuelle "filer" i filsystemet.

 

Bare så det er sagt, dette må ikke blandes med interrupts som typisk ble brukt i MS-DOS. Jeg har programmert med det så jeg vet forskjellen.

Feil. Programmene bruker virtuelle adresser. En av de viktigste oppgavene til et moderne OS er nettopp å oversette virtuelt minne til fysisk minne. Det er noe OS-et gjør, ikke en underliggende firmware (BIOS/EFI/etc). BIOS har også lite med hvordan hardware er mappet til minneområdet, men kan som sagt konfigurere noen av disse tingene ved oppstart.

 

BIOS er akkurat hva navnet sier, ett grunnleggende grensesnitt for å kommunisere IO. Du må ikke blande den generelle betegnelsen BIOS med den spesifikke "IBM BIOS" som er en del av PC-standarden. EFI er en BIOS som er utvidbar med firmware, noe en tradisjonell "IBM BIOS" ikke har. Ser du på ulike embedded-plattformer så har de som regel en eller annen form for BIOS uten at det har noen relasjon til "IBM BIOS".

Jeg får gjenta det jeg sa i sted; denne uenigheten handler om begreper. Mange mener faktisk det du kaller "IBM BIOS" når de snakker om BIOS. Det er vanlig å kalle det du kaller for BIOS for "firmware". Inn under det begrepet ligger da både BIOS ("IBM BIOS"), EFI og det man finner i diverse embedded-platformer. Hvis vi ser bort fra disse begrepsuenighetene så er vi vel alle egentlig enige i denne tråden.

Hva med å skrive artikler om ting dere faktisk kan, eller gjøre grundige undersøkelser?

 

En moderne PC består som kjent av mange forskjellige komponenter som gjør sine ting, og disse må kommunisere og koordinere innsatsen. Spesielt viktig er dette i oppstarten, før selve operativsystemet tar over styringen.

...

Ingen av dagens nyere operativsystemene bruker BIOS aktivt. På en moderne PC er BIOS' hovedfunksjon å sparke i gang maskinvaren slik at operativsystemet kan lastes inn.

Her har dere ikke forstått hva BIOS faktisk er. BIOS er nettopp et grunnleggende I/O-system som operativsystemet bruker for å kommunisere med maskinvare. Alt dette har dere glemt, men dere nevner i stedet det som kalles POST(Power-On Self-Test), og det er langt fra det eneste en BIOS gjør. Viktigst av alt er oppgaven med å tildele minneadresser for at operativsystemet skal kunne kommunisere med maskinvare, og strømstyring som ACPI. POST er en nyttig ting, men ikke en kritisk oppgave.

Ingen moderne operativsystem bruker BIOS for å kommunisere med maskinvare, nei. Tildeling av minneadresser, hvor har du det i fra? Minneadressering er ekstremt komplisert i en moderne x86-maskin, men det gjøres i hardware (chipsettet og kretsdesignet i hovedkortet), ikke av BIOSen. Noen aspekter ved hvordan dette skjer kan konfigureres i BIOS/EFI/firmware/whatever, men det har ingenting med BIOS i seg selv å gjøre.

 

Dere sier ikke et ord om hva EFI faktisk er. EFI erstatter ikke BIOS, det er en utvidet BIOS.

Her tror jeg man snakker litt forbi hverandre pga. begreper: Både EFI og BIOS er eksempler på det mer generelle begrepet firmware, noe alle datamaskiner har, uansett hvor gamle eller nye de er. BIOS og EFI har også samme oppgave i en datamaskin, men slik begrepene vanligvis brukes blir det feil å kalle EFI for en utvidet BIOS.

BIOS defineres vanligvis til å være en firmware som er kompatibel med den originale PC-firmwaren til IBM. Kompatibel vil her si måten operativsystemet lastes på (bootsector-konseptet osv.), hvilke funksjoner firmwaren implementerer, og grensesnittet for å bruke disse. Man kan boote MS-DOS fra en moderne PC med BIOS nettopp av denne grunn -- fordi firmwaren implementerer BIOS-standarden (i tillegg til mye, mye mer). Det er ikke noe slikt krav for en EFI-firmware, men mange har en såkalt "BIOS legacy mode" for å være bakoverkompatible.

Hvis ei flate er parameterisert ved en funksjon så vil flateelementet uttrykt ved parameteriseringsvariablene være (dette bør stå i boka!)

Her har du at parameteriseringen av flaten er gitt ved . Du må altså finne vektorene og , krysse dem, og finne lengden av den resulterende vektoren.

Omega verksted hadde noen sånne minibreadboards sist jeg var der, men ingen større. Når jeg søker i komponentdatabasen deres nå finner jeg tre stk de visstnok har inne. De bruker også å ha noen til låns der hvis du bare trenger noe midlertidig. Hvis du har litt tid på deg så har DealExtreme mange billige og brukbare breadboards. Eventuelt er jo elfa et (litt dyrt) alternativ..

Ja, kurven er randen ("boundary") til flaten man ser på. Dette er det vel tegninger av i Matte 2-boka? Kurva trenger ikke stamme fra en lukket flate som så deles i to, selv om mange eksempler kanskje har det (kanskje jeg misforstår spørsmålet?)

Bare sånn for å illustrere forskjellen, se her (hold musepekeren over bildet for å se HD-utgaven av samme stillbilde).

Som man ser her mister man noe av bildet øverst og nederst, men får mer på sidene. Det er litt uenigheter blant folk om det hadde vært bedre å beholde 4:3-formatet, slik det var ment å være. Jeg syns det tar seg bra ut i 16:9, selv om bildet kan være litt tomt på sidene i noen av scenene. Det gir i alle fall serien et mer filmaktig preg, slik Chris Carter har uttalt at han ønsket at X-Files skulle ha.

Husk på at , så .

På tide å fyre opp denne tråden igjen!

I disse dager foregår det en HD-remaster av X-Files; de har leita frem de originale filmrullene og scannet dem i widescreen i høy kvalitet. Jeg har lasta ned et par episoder og må bare si at det ser helt utrolig ut! Det er nesten som å se serien på nytt. Det er så mange detaljer jeg aldri har lagt merke til før, fargene er krystallklare (ikke blasse og slørete som det var før), og bildet er sylskarpt. Merker først nå at cinematografien i denne serien var på topp allerede fra starten av. Ser man bort fra noen av effektene (som er i samme kvalitet), så er det ikke mye igjen av "cheesy 80/90-talls"-preget lenger, det er nesten som en ny serie.

Det som trekker litt ned er at noen av scenene, inkl. alle scener med digitale effekter er i den originale kvaliteten. Det er heldigvis ikke så mange av disse per episode. Lyden er såvidt jeg kan høre også den samme, og altså ikke helt optimal.

Merkelig nok er det en tysk tv-kanal som har tatt på seg å gjøre dette, men episodene er heldigvis på engelsk. Så langt har de sendt sesong 1 i HD, og holder på å sende sesong 2 nå. Forhåpentligvis fører dette før eller senere til en blu-ray release av serien, det hadde vært knall.

edit: La ved noe eye-candy fra "Blood" (S02E03). Sesong 2 har mer stabil bildekvalitet vil jeg si.

Her er noe jeg laga i helgen, mest for å teste min nye Bass Station 2 (de andre instrumentene er de samme som nevnt ovenfor):

Stort sett, ja. Se mer her.

Du har funnet ut at fartsvektoren er , som er riktig. For å finne fartsvektoren etter to sekunder så setter du rett og slett inn t = 2: . Fartsvektoren peker altså én enhet bort og to enheter ned. Nå gjenstår det bare å tegne denne vektoren inn i figuren din, i posisjonen på kurven som svarer til t = 2. Det finner du ved å bruke posisjonsvektoren (den du deriverte).

Ta f.eks. rekkene og : Førstnevnte divergerer, mens den andre konvergerer -- selv om leddene går mot 0 i begge tilfeller. Leddene i sistnevnte går "fortere" mot 0, siden nevnerne er opphøyd i andre, og det viser seg altså at de går fort nok mot 0 til at rekken konvergerer. Generelt har vi at konvergerer når p er større enn 1 og divergerer ellers.

H består av alle lineærkombinasjoner av to vektorer fra R^3. Alle vektorene i H må jo da også være i R^3, ikke sant? (De har jo fortsatt tre komponenter). At dimensjonen til H viser seg å være den samme som for R^2 forandrer ikke på det (men vi vet da at H er isomorf med R^2).

Friksjonskraften og normalkraften er ikke motkrefter. Motkraften til friksjonen er en kraft som virker på veien, og som peker i stikk motsatt retning. Motkraften til normalkraften er en kraft som virker på veien og som peker rett ned. Newtons 3. lov sier bare at disse motkreftene alltid finnes. Tyngdekraften som trekker deg ned mot jorden har f.eks. en motkraft, nemlig en like stor kraft som du virker på jorden med.

DC er parallell med AB, så å finne er vel en smal sak? På de to andre kan det være nyttig å tenke at du skal "gå" fra start- til sluttpunktet til vektoren du skal finne. For å gå fra A til C kan vi først gå fra A til D, og deretter fra D til C, ikke sant? Det betyr altså at (fyll inn resten).

Det virker ikke som det er noen fast regel, nei. I én bok jeg har bruker de konsekvent hatter for å indikere enhetsvektorer (og stor bokstav for å indikere at det er en normalvektor), men i en annen bok antar de bare at det er implisert fra situasjonen og skriver ikke enhetsnormalvektorer på noen spesiell måte.