Matematiktråden (dina matematikproblem här!)

Man kan skriva i = 1(cos(pi/2) + isin(pi/2)). Vi vet att "dra roten ur" är samma som att halvera argumentet och dra roten ur absolutbeloppet. Därför är ett möjligt värde på sqrt(i) = 1(cos(pi/4) + isin(pi/4)) = sqrt(2)/2 + i * sqrt(2)/2. Nu finns det massa andra möjliga svar också, t.ex är i = 1(cos(pi/2 + 2pi) + isin(pi/2 + 2pi)), osv.

=> är ingen operator, man sätter den mellan två påståenden för att visa att det ena medför det andra. A => B betyder att "A implikerar B", eller "A medför B". <= betyder antingen "mindre än eller lika med", eller så är det en "bakåtvänd" implikeringspil, A <= B betyder alltså B => A.

<=> står för ekvivalens. A <=> B betyder alltså att A medför B och att B medför A.

Okej, tack, även om jag kanske inte riktigt fattade allt, det var ganska många nya saker för mig om man säger så

EDIT: Din förklaring om <= och <=> förstod jag, så tack för den

(a,b) · (c,d) = (ac-bd,bc+ad)
(a,b)*(a,b) = (a^2-b^2,ab +ab)
(a,b)*(a,b) = (a^2-b^2, 2ab)
x^2 = (0,1)

2ab= 1 = ab = 0.5 (1)
a^2-b^2 = 0 = a^2 = b^2 (2)
(1) och (2) säger att a = b
a=b
ab=0.5
a = b = +-sqrt(0.5)
sqrt(0.5) +/- i*sqrt(0.5)

Orkar inte förklara bättre

Thomas: Det där är från mathschallenge.net. Säg det när du frågar, och det är inte meningen att man ska be om hjälp med problemen. Men du bör veta att de allra flesta ekvationer (och ekvationssystem) är olösliga (med operationerna +*^). Så det finns inget trick. Substitution brukar vara det bästa man har till hands (här kan du få ett uttryck för c, sätt in det i andra, och om du har tur kan du uttrycka a explicit i b). Sådana här problem finns på den där sidan just för att de ofta är svåra eller omöjliga att lösa matematiskt, utan måste lösas med brute force.

Med villkoret a+b+c=1000 vet du att a,b,c < 334. Loopa på.

Ditt ekvationssystem har den geometriska tolkningen att a, b, och c är sidor i en rätvinklig triangel med omkretsen 1000. Det är ett underbestämt system, och det finns oändligt många reella lösningar, men antagligen är du bara intresserad av heltalslösningar.

Pythagoreisk trippel heter det på svenska för övrigt.

Om du använder c = 1000 - a - b och sätter in i första ekvationen får man:
2000a + 2000b - 2ab = 1000000
Hur man skall lösa denna ekvation för heltalslösningar vet jag inte.

Det finns emellertid en formel som genererar alla primitiva pythagoreiska triplar (dvs där a, b, och c är relativt prima, dvs har största gemensamma delare lika med 1):
a = v^2 - u^2
b = 2uv
c = v^2 + u^2
där u och v > u är relativt prima

Alla pythagoreiska triplar fås genom att ta alla primitiva pythagoreiska triplar och multiplicera med godtyckligt heltal. Om (a, b, c) är pythagoreisk trippel så är (n*a, n*b, n*c) också det.
Därmed, om vi har en pythagoreisk trippel där a+b+c=1000 så är antingen (a,b,c) en primitiv pythagoreisk trippel, eller så finns det ett heltal n så att (a/n, b/n, c/n) är primitiv pythagoreisk trippel, och då är a/n + b/n + c/n = 1000/n

Vi löser alltså problemet om vi hittar alla primitiva pythagoreiska tripplar där a+b+c delar 1000 = 2^3 * 5^3.

a+b+c = v^2 - u^2 + 2uv + v^2 + u^2 = 2v^2 + 2uv = 2v(v+u)
Vi har att 2v(v+u) skall dela 2^3 * 5^3
dvs v(v+u) skall dela 2^2 * 5^3 = 500

Nu är det väl bara att gå igenom alla möjligheter. v måste vara minst 2 och mindre än sqrt(500) = 22.36...
(eftersom att 500 >= v*(v+u) > v^2)
v kan alltså vara 2, 4, 5, 10 eller 20
Titta på alla möjligheter för u därefter.

Edit: raderade sista biten.

En av a, b, c, måste vara mindre än 334, inte alla (ta c = 998, a = b = 1).

Right. Som du kan se var det rätt sent när jag svarade. Min poäng var att det inte tar så lång tid att loopa igenom alla heltalskombinationer.

Hej!

Behöver lite hjälp med en logik-uppgift som består av att jag ska bevisa:
"(A & B) eller icke-A eller icke-B" om ni förstår vad jag menar.
Har boken Language proof and logic som kursbok, vet därför inte om det är ett generrelt problem eller om det är specialiserat på boken och det språk vi använder.

tacksam för svar allafall

Jag ser inget påstående att bevisa.
Aha, ok..

icke-A eller icke-B <=> icke-(A & B)

så ditt påstående blir: (A & B) eller icke-(A & B) vilket ju är sant.

Kan någon hjälpa mig att lösa ut z ur denna ekvationen?

P+-z*squa(roten)p(1-p)/n

Med ord, sannolikheten plus minus z gånger roten ur sannolikheten gånger 1 minus sannlolikheten delat med antalet observationer.

Lite svårt att skiva en vettig ekvationen men det borde vara förståeligt.

Det är väl basic matte det här.

mvh

Menar du P ± z*sqrt(p*(1-p)/n) ?
Det är inte någon ekvation.

Jao, det är ju ganska trivialt men det är ett formellt bevis jag ska lägga fram, lite jobbigare.

Har en fråga till om logik, Hur fasen ska man kunna få ner denna mening till en mening bestående av enbart sex konjektiv och varje individ får bara benämnas en gång... har skapat denna mening m.h.a. en sanningstabell men jag får inte ut mer från den.

"(~Q & R) v (Q & P) v (~R & ~P)"

Nä det är en formel men so what, går det inte att lösa ut z eller?

Nej, det går faktiskt inte.

Hur tänker du när du säger "lösa ut"? Med lösa ut menar man t.ex. z = "Uttryck av andra varibler".
Du kan inte lösa ut något ur ett uttryck, för de andra variblerna medför inte några krav på z som gör att man kan tilldela det något uttryck av dem.

P ± z*sqrt(p*(1-p)/n) = A
z = (A - P) / ±sqrt(p*(1-p)/n)

Du måste veta värdet av konstanten A.

Borde inte "körtid" vara det förväntade antalet gånger som man måste prova lösenord för att hitta det riktiga? Eftersom varje kombination har lika sannolikhet att prövas, så borde väntevärdet vara totala antalet kombinationer delat med två. Eller tänker jag fel?

Sen vet jag inte hur man räknar ut antal möjliga kombinationer för (1). Om man bara fick prova en bokstav åt gången hade det kanske varit lättare Rimligen borde det vara samma antal (256^n) om man bara har en bokstav åt gången, men eftersom man prova alla samtidigt så blir "körtiden" mindre.

Kanske lite OT, men vilken server skickar information om enstaka bokstäver i ett lösenord som är fel? Låter som en ganska dum server

Maximal körtid för (1) är 256, precis som om lösenordet bara varit en bokstav.
Du kan ju börja med AAAAAAAA, och sen stega uppåt, och låsa de bokstäver som blir rätt efterhand.

Man kanske skulle säga att (2) är 256^n/256 = 256^(n-1) ggr säkrare.

Det är lite svårt att förklara vad jag håller på med men om ni kan statistik så kanske det går bra.

Jag har räknat om olika medelvärden baserar på olika grupper till z värden för att kunna jämföra dem. Populationsmedelvärdet blir då 0 och respektive grupp får ett positivt eller negativt värde eller 0 (osannolikt).

Samma sak försöker jag göra för sannolikheter, frekvenser (procent). Jag vill kunna jämföra tex olika gruppers frevenser på en viss ja/nej frågeställning.

Någon som förstår?

Jag har nu löst det genom att räkna ut medelvärdet för frekvensen för hela gruppen. Tagit respektive undergrupperings frekvens och subtraherat det från medelvärdet. Gjort alla negative värden till postitiva och lagt ihop dessa och delat med antalet som någon slags standardavviklese för procentsatser. Skillnaden mellan respektive undergrupp har jag delat med "standardavvikelsen". Sen delade jag igen med antalet grupper för att annars så blev de så höga värden.

Det största problemet är att jag försöker jämföra kvot och ordinaldata med i det här komplicerade fallet nominaldata.

Ingen som fattar något va?

För Hedis fråga, säg att man inte vet lösenordets längd.

För (2) är det väl inte så svårt, om man gör antagandet att man börjar med lösenord på en bokstav, fortsätter med två, sen tre osv. Eftersom alla försök på 1 till (n - 1) bokstäver kommer vara fel så kommer man garanterat ha fel på 256 + 256² + ... + 256^(n-1) försök. Sen kan det krävas mellan 1 till 256^n försök till efter det. Maximalt körtid är 256 + 256² + ... 256^n försök.

För (1) är det mycket svårare. Säg att man har ett lösenord ABCDEFGH. Om man då skickar in ABED, så antar jag att servern svarar SSFS. Jag antar också att om man skickar in för många bokstäver så svarar servern F på alla extra bokstäver. Då verkar den bästa algoritmen att testa "oändligt antal bokstäver" (så många som är tillåtna) och behålla de som blir riktiga. Man kan fortfarande börja på AAAAAAAAAA.... sen BBBBBBBB... osv. Alltså så behövs det fortfarande bara 256 försök, och här vinner (2) med ännu större marginal.

Riktigt tänkt?

roggles: I den där analysen ser man bara på hur många försök som behövs för att knäcka lösenordet, inte hur mycket data man behöver skicka (alltså överföringshastigheter och så bryr man sig inte om). Algoritmer jag skulle använda i det här fallet:
(2): Börja med lösenord av längd 1, testa alla kombinationer, fortsätt med lösenord somär en bokstav längre, osv.
(1): Börja med lösenord av längd 1, testa alla kombinationer, fortsätt med ett dubbelt så långt lösenord, osv.

I (2) måste man testa n olika längder, medan det i (1) räcker med lg2(n). Sedan kan man ju ändra hur mycket man ska ändra storleken i (1), t ex istället med power towers, ackermannfunktionen eller BB-funktionen.

edit: Rätta mig om jag har fel. Jag är inte så insatt i detta, men vad jag säger låter rimligt tycker jag.