abonnement Unibet Coolblue Bitvavo
pi_75694526
Ja en de absolute waarde zetten ze alleen om de x omdat alle andere delen (de drie, en de n/(n+1) toch sowieso positief zijn)
"Reality is an illusion created by a lack of alcohol."
pi_75694684
Mwah ze doen : lim n-> oneindig |xn/3n+3| ---> delen door hoogste macht noemer door n --->
|x/3+3/n| ---> daarna de limiet bepalen geeft: x/3+0

En dan om de convergentiestraal te bepalen: x/3 = +- 1 dus x = +/- 3 R= 3 En dan moet je die weer invullen in de originele etc. etc.
In fact, recent observations and simulations have suggested that a network of cosmic strings stretches across the entire universe.
pi_75695049
Nee eens goed kijken, ze zetten alleen de |x|/3 voor de limiet aangezien die toch niet beinvloed worden door de limiet, daarna doen ze pas de limiet uitwerken.
"Reality is an illusion created by a lack of alcohol."
pi_75695785
mja, maar het maakt niet veel uit an sich. Op mijn manier kom je er ook op uit.
In fact, recent observations and simulations have suggested that a network of cosmic strings stretches across the entire universe.
pi_75701186
quote:
Op woensdag 16 december 2009 16:50 schreef Burakius het volgende:
[ afbeelding ]

Zie het omkringelde. Hoe kunnen ze nou heel droog die twee n'en wegstrpen. Ik heb getracht het uit te werken door die 3(n+1) uit te werken tot : 3n + 3 en dan dingen wegstrepen, maar dan nog kom ik er niet op. Help please.

p.s.

Dit is trouwens een ratio test (Quotiëntentest)
Er wordt helemaal niks 'weggestreept'. Die factor |x|/3 is onafhankelijk van n en dus een constante factor wanneer n je variabele is. Zodoende is de limiet van |xn/3(n+1)| voor n →∞ gelijk aan |x|/3 maal de limiet van n/(n+1) voor n →∞.
pi_75704850
Ik heb er nog één meesterlijke meesters der Brontosaurussen.




Dit is dus een Bessel-functie van de 1ste orde. Heel leuk en aardig dat ze hier een Ratio test gebruiken. Nu kom ik zelf op :

(x/2)2 lim 1/n+2

Zoals jullie zien mis ik die n+1 die ook bij de noemer hoort. Nu zal het vast liggen aan iets met die faculteiten. [b]Ik weet dat (blijkbaar) ((n+1)+1)! = (n+2)! [b/] En ik weet ook dat (n+2)! = (n+2)n!
Als ik dit toepas kan ik wegstrepen etc. , maar dan houd ik die n+1 niet over iig.

Wat doe ik fout? (graag het dikgedrukte ook verifiëren)
In fact, recent observations and simulations have suggested that a network of cosmic strings stretches across the entire universe.
  woensdag 16 december 2009 @ 21:17:25 #32
75592 GlowMouse
l'état, c'est moi
pi_75704952
quote:
En ik weet ook dat (n+2)! = (n+2)n!
dat klopt niet.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_75705623
quote:
Op woensdag 16 december 2009 21:17 schreef GlowMouse het volgende:

[..]

dat klopt niet.
Oke dat zou goed kunnen. Voor (n+1)! = (n+1)n! wel geldig.

Dus dan is het voor (n+2)! = (n+1)(n+2) n! of iets in die richting?
In fact, recent observations and simulations have suggested that a network of cosmic strings stretches across the entire universe.
  woensdag 16 december 2009 @ 21:34:25 #34
147503 Iblis
aequat omnis cinis
pi_75705741
quote:
Op woensdag 16 december 2009 21:31 schreef Burakius het volgende:

[..]

Oke dat zou goed kunnen. Voor (n+1)! = (n+1)n! wel geldig.

Dus dan is het voor (n+2)! = (n+1)(n+2) n! of iets in die richting?
Tja, je kent de definitie van ! toch hoop ik?
Daher iſt die Aufgabe nicht ſowohl, zu ſehn was noch Keiner geſehn hat, als, bei Dem, was Jeder ſieht, zu denken was noch Keiner gedacht hat.
pi_75706144
quote:
Op woensdag 16 december 2009 21:34 schreef Iblis het volgende:

[..]

Tja, je kent de definitie van ! toch hoop ik?
tja ik weet dat (n+2)! = (n+1) * (n+2) * ....... etc. dus = (n+1) * (n+2) * n! (hoop dat dit correct is).

Het is faculteit. Dus 3! = 1 * 2 * 3
In fact, recent observations and simulations have suggested that a network of cosmic strings stretches across the entire universe.
pi_75706665
quote:
Op woensdag 16 december 2009 21:42 schreef Burakius het volgende:

[..]

tja ik weet dat (n+2)! = (n+1) * (n+2) * ....... etc. dus = (n+1) * (n+2) * n! (hoop dat dit correct is).

Het is faculteit. Dus 3! = 1 * 2 * 3
Ik zou het wel andersom schrijven, nu lijkt het net of de termen steeds hoger gaat, maar dus:

(n+2)! = (n+2) * (n+1)! = (n+2) * (n+1) * n!
"Reality is an illusion created by a lack of alcohol."
pi_75707195
quote:
Op woensdag 16 december 2009 21:53 schreef Dzy het volgende:

[..]

Ik zou het wel andersom schrijven, nu lijkt het net of de termen steeds hoger gaat, maar dus:

(n+2)! = (n+2) * (n+1)! = (n+2) * (n+1) * n!
Thx duidelijk!
In fact, recent observations and simulations have suggested that a network of cosmic strings stretches across the entire universe.
pi_75728574
Beste mensen, ik heb een statistisch probleem:

Technisch verhaal:

Ik doe een onderzoek naar de effectiviteit van een interventie. Werkt onze beinvloeding ja/nee?

Idee: we hebben 3 plekken in Nederland gepakt. Op twee plekken hebben we een bord neergezet, namelijk bord1 of bord2. Op de derde plek staat niets (controleconditie).

Bij deze plekken hebben wij op drie dagen, voor twee weken, geobserveerd. Eerste voordat de borden er stonden (voor-/nulmeting) en daarna terwijl de borden er staan.
Mijn variabelen in mijn databestand ziet er ongeveer zo uit:

T0-1 T0-2 T0-3 T0-4 T0-5 T0-6 T1-1 T1-2 T1-3 T1-4 T1-5 T1-6 Conditie

T0-1 is de eerste dag van de nulmeting, T0-3 is de derde dag van de nulmeting enz.
T1-1 is de eerste dag van de nameting, T1-5 is de vijfde dag van de nameting enz.
Conditie is het bord dat er staat, 1,2 of 3 (waarbij 3 geen bord is).

Daaronder staan dus 3 rijen met cijfers, voor elk geobserveerde plaats 1.

Mijn vraag is deze: Hoe kan ik de effectiviteit van onze interventie berekenen? Doordat we maar drie plaatsen hebben, is er een n van 3 (erg weinig dus). Is er een mogelijkheid de data van de verschillende meetmomenten als 'within' info mee te nemen of nog iets anders ermee te doen?

Als ik een repeated measures anova doe kan ik wel contrasten bekijken tussen alle verschillende meetmomenten, maar ik wil eigenlijk een duidelijk contrast tussen nulmeting en nameting.
Als ik een gemiddelde pak van de nulmeting en de nameting heb ik het gevoel dat ik veel informatie weggooi door simpelweg een gemiddelde te pakken, terwijl ik in feite 6 observaties heb.

Kan iemand mij helpen?
Alvast bedankt!
pi_75747263
Wiskundige vraag

daar verder

[ Bericht 91% gewijzigd door GlowMouse op 17-12-2009 21:56:39 ]
I intend to live forever.. So far, so good..
Xbox 360 Live: EN4 360
pi_75801347
Stel ik heb twee lijsten A en B van ongeveer 100 natuurlijke getallen. Ik weet dat er een getal bestaat in beide lijsten. Maar ik wil een algoritme schrijven dat voor mij op een snelle manier uitzoekt welk getal dat is (ik vergeet even over de posities van dat getal in a1 en a2).

Ik hoef niet perse met a1 en a2 zelf te werken dus ik dacht het volgende: ik maak tien kleine lijsten (de lengte/geheugen is even niet zo belangrijk) A0, A1,...,A9 waarbij ik in lijst Ai alle getallen uit A stop die eindigen op i in hun decimale representatie (dus bijv 101 gaat naar A1, 1004404 gaat naar A4). Daarna maak ik een forloop die een b getal uit B neemt en dan i=b%10 uitrekent, dan zoek ik alleen in lijst Ai naar het getal b.
Dit algortime heeft toch hoogstens orde n? Is er nog een slimmer/sneller algoritme?

Alvast bedankt!
  zaterdag 19 december 2009 @ 13:03:54 #41
75592 GlowMouse
l'état, c'est moi
pi_75801652
quote:
Daarna maak ik een forloop die een b getal uit B neemt en dan i=b%10 uitrekent, dan zoek ik alleen in lijst Ai naar het getal b.
Het opzoeken kost ook nog O(n) zodat je voor het totaal op O(n²) komt. Door sorteren van beide lijsten kun je tot O(n logn) komen, maar de vraag is of dat bij n=100 veel uitmaakt.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
  zaterdag 19 december 2009 @ 13:06:15 #42
147503 Iblis
aequat omnis cinis
pi_75801718
Worst case is natuurlijk als alle getallen in A op hetzelfde eindigen, en dat dus, zeg |A0| = |A|, en idem voor B, waardoor je nog steeds n keer een lijst van n getallen lineair doorzoekt.

Als de lijsten van getallen niet bounded zijn dan is m'n eerste indruk dat je ze het beste individueel kunt sorteren (n log n), en dan mergen wat met gesorteerde lijsten lineair kan. Tijdens de merge kun je dan op duplicaten checken.

Is de boel wel gebound of weet je meer over de input, dan kun je een lineaire oplossing nadenken.
Daher iſt die Aufgabe nicht ſowohl, zu ſehn was noch Keiner geſehn hat, als, bei Dem, was Jeder ſieht, zu denken was noch Keiner gedacht hat.
pi_75803254
quote:
Op zaterdag 19 december 2009 13:06 schreef Iblis het volgende:
Is de boel wel gebound of weet je meer over de input, dan kun je een lineaire oplossing nadenken.
Die bound heb je ook, want je weet dat het natuurlijke getallen zijn. Je kan dan het maximum zoeken in O(n), een array maken vol booleans met de maximumgrootte van het gevonden maximum + 1, en alle startwaarden in die array op false zetten.

Tijdens de eerste for-loop zet je indices in je array die corresponderen met de getallen die in je eerste lijst staan op true (O(n)). Tijdens de tweede for-loop kijk je of de indices in je array die corresponderen met de getallen in je tweede lijst al op true staan (O(n)), zo ja, dan zit ie in beide. Kan een heleboel geheugen kosten als het maximum heel groot is enzo, maargoed, de orde is lager -.-
  zaterdag 19 december 2009 @ 14:12:17 #44
75592 GlowMouse
l'état, c'est moi
pi_75803313
Iblis heeft het over een a priori bekende bound, bedenk maar eens waarom het dan makkelijk wordt

Jouw 'oplossing' is niet goed, je ziet zelf dat het al fout gaat bij een groot getal.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_75803499
quote:
Op zaterdag 19 december 2009 14:12 schreef GlowMouse het volgende:
Iblis heeft het over een a priori bekende bound, bedenk maar eens waarom het dan makkelijk wordt

Jouw 'oplossing' is niet goed, je ziet zelf dat het al fout gaat bij een groot getal.
Er zullen vast wel meer bounds zijn waardoor het makkelijk wordt om een lineaire oplossing te bedenken. Als je weet dat de getallen natuurlijke getallen zijn (zoals in dit geval) ook, dus ksnap niet precies wat je bedoelt.

Het kan veel geheugen kosten maar in theorie gaat dit goed hoor, en er werd volgens mij niet gevraagd om rekening te houden met het geheugen. Kan je iets concreter vertellen wat er volgens jou dan mis gaat -.-
  zaterdag 19 december 2009 @ 14:22:46 #46
75592 GlowMouse
l'état, c'est moi
pi_75803541
Je moet kijken naar de verwerkingstijd als functie van je input. In jouw functie is die exponentieel, want om een groot getal K in te voeren kost dat mij log(K) stapjes terwijl de geheugenallokatie K stapjes kost.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
  zaterdag 19 december 2009 @ 14:26:22 #47
147503 Iblis
aequat omnis cinis
pi_75803623
De bound komt dan sowieso niet te liggen bij de lengte van de input maar bij de maximale waarde van de getallen in de input. Of je nu rijen van 2 of rijen van 10.000 wil vergelijken, je hoofdprobleem zal waarschijnlijk zijn – op een 64-bits machine b.v. – een array van 264 booleans te alloceren.

Overigens, wat Optimistic1 doet, is simpelweg de input hashen. En in feite kan dat algemener. En dan kun je – met random data – wel een in de praktijk lineaire oplossing krijgen. Maar de vraag is dus even of je worst-case wilt gaan zitten analyseren of niet.
Daher iſt die Aufgabe nicht ſowohl, zu ſehn was noch Keiner geſehn hat, als, bei Dem, was Jeder ſieht, zu denken was noch Keiner gedacht hat.
pi_75806029
quote:
Op zaterdag 19 december 2009 14:22 schreef GlowMouse het volgende:
Je moet kijken naar de verwerkingstijd als functie van je input. In jouw functie is die exponentieel, want om een groot getal K in te voeren kost dat mij log(K) stapjes terwijl de geheugenallokatie K stapjes kost.
In de praktijk kan je hierop letten, maar om de orde van n te bepalen hoef je niet te letten op maximumgetal K en kdenk dat Optimistic bedoelde dat hij de laagste orde n wou. De oplossing die ik in mn post noemde is overigens ook geaccepteerd als oplossing (als n dichtbij K zit), alleen wordt hij nauwelijks gebruikt -.-

Wat Iblis zegt kan mis gaan (ook al kom je in de praktijk niet altijd tegen dat je getallen groter dan 2^64 moet verwerken) waar ingewikkelde oplossingen voor zijn (met nog meer trees en arrays), dus daar gaan we niet aan beginnen -.- Daarom kan Optimistic maar beter zoiets zeggen (wat in de vorige posts al beetje gezegd is, maar het algoritme is nog niet echt gegeven):
- Beide lijsten sorteren (via merge-sort heb je uiteindelijk de laagste orde, namelijk O(n log(n)), maar quick-sort is in de praktijk sneller maar heeft worst-case O(n^2)).
- Neem telkens het minimum van de twee gesorteerde lijsten en kijk of hij overeenkomt met het minimum van de andere lijst. Zo niet, streep die weg en herhaal.
pi_75812623
De getallen die ik heb komen doordat ik een algoritme gebruik om het aantal punten op een elliptische kromme E gedefinieerd over een lichaam Fp uit te rekenen. Het algortime heeft complexiteit O(p1/4+e) en gaat als volgt:

*Kies een random punt P op de kromme E.
*Bereken de eerste s veelvouden van P, namelijk P, 2P, 3P,...,sP, waarbij s=p^(1/4) (bij mij is s ongeveer 100) en sla deze op in een lijst.
*Bereken Q:=(2*s+1)P en R=(p+1)P door binaire expansie van p+1 te gebruiken.
*Schrijf t=[sqrt(p)/(2*s+1)] (dit is een getal ongeveer gelijk aan s) en bereken
R +/-P, R+/- 2P,R+/-3P,....,R+/-tP en dit zijn 2s+1 punten. Deze sla ik weer op in een lijst.

Er is een stelling die zegt dat er een i en j bestaan met R+iQ=jP, dus er is een punt zowel in de 1e als in de 2e lijst en dat punt wil ik vinden... want als ik die vind en dus ook i en j weet..
dan kan ik weten wat het aantal punten is op mijn kromme E. Over het vinden van dit punt staat;
"It is important that one can efficiently search among the points in the
list of baby steps; one should sort this list or use some kind of hash coding.
It is not difficult to see that the running time of this algorithm is O(p1/4+e)"
http://www.mat.uniroma2.it/~schoof/ctg.pdf

Mijn idee was om dus om gebruik te maken van de x-coordinaat van de punten en die gaan onthouden.
pi_75896014
ok, ik heb alleen mn telefoont en moment tot mijn beschikkng, dus alle informatie kan ik niet geven, maar het schijnt dat je hieraan genoeg hebt:

a= 0,5(0,84a+0,4c) + 0,8c
a = 1,72

waarom wordt dit 1,72c ?
abonnement Unibet Coolblue Bitvavo
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')