Mielenkiintoinen lause heittoliikkeestä

GeoGebra Materiaaleihin ilmestyi lokakuun lopussa Kari Peisan tekemä appi liittyen vinoon heittoliikkeeseen. En ole itse aiemmin törmännyt tähän teoreemaan/lauseeseen/väitteeseen, mutta ainakin minua se kummastuttaa kummasti. Pakkohan tätä on tutkia. Karin mukaan ongelma on esitetty alun perin eräässä Facebook-ryhmässä.

GeoGebra appissa ”Pisimmän heittoliikkeen alku- ja loppunopeus” https://www.geogebra.org/m/hgujahsm on seuraava väite.

Oheisessa kuvassa asetin h:n arvoksi 4 ja v:n arvoksi 10. Liu’un alfa avulla säädin kantaman mahdollisimman suureksi. Vaikuttaa siltä, että väite pitää ainakin likiarvoisesti paikkansa. Kokeilemalla eri korkeuksilla ja alkunopeuksilla alkaa vaikuttaa, että väite on luultavasti totta.

Päätinpä yrittää ”todistaa” lausetta kokeilemalla joillain lähtöarvoilla. Valitsin alkunopeudeksi 5 (m/s) ja lähtökorkeudeksi 13. Putoamiskiihtyvyys on 9.81 m/s2. 

Ratkaisun juoni on yksinkertainen. Määritetään kantaman lauseke kulman funktiona. Ratkaistaan kantaman derivaatan nollakohta, näin saadaan kulma, jolla kantama on suurin. Kyseisen kulman avulla lasketaan lentoaika ja sen avulla nopeuden komponentit kyseisellä ajan hetkellä. Alla kuvankaappauksia ja selityksiä ”todistukseen”.

rivi 1: kantamayhtälö

rivi 2: RA on yhtälön ratkaisulista

rivi 3: aika on suurempi ratkaisuista

rivi 4: kantama kulman funktiona

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Kuvaajassa kantama kulman funktiona. Kulma yksiköissä radiaani.

rivit 5-8: Kantaman derivaatan nollakohta, minua kiinnostaa vain tuo ensimmäinen eli maksimikohta.

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

rivi 9: tt on lentoaika.

rivit 10–11: loppunopeuden komponentit

rivi 12: nopeuden suunta lopussa radiaaneina

rivit 13 ja 14: Alku- ja loppunopeusvektoreiden välinen kulma

Vaikuttaa siltä, että Lause pitää paikkansa.

Kun aloin kokeilla yleistä todistusta, niin törmäsin hankaluuksiin tuossa rivin 6 yhtälön ratkaisussa. Siitä taitaa tulla kuudennen asteen yhtälö sin(α):n suhteen. Pitääpä tutkia, miten saan lauseen todistettua yleisesti. 

Tai sitten jätän sen tehtäväksi sinulle arvoisa lukija.

OMG-hiukkanen – GeoGebran Lukuarvona-komento

Luin Wikipedia-artikkelin OMG-hiukkasesta. Siinä kerrottiin, että: ”OMG-hiukkanen eli Oh-My-God-hiukkanen on lempinimi kosmiselle hiukkaselle, joka havaittiin 15. lokakuuta 1991 Fly’s Eye -ilmaisimella Dugway Proving Groundsissa, Utahissa. Hiukkanen oli atomia pienempi, mutta sen liike-energia oli yhtä suuri kuin 25 m/s (90 km/h) liikkuvalla pesäpallolla (160 g): noin 3 × 1020 elektronivolttia eli suunnilleen 50 joulea. Hiukkanen oli luultavasti lähes valonnopeudella kulkeva protoni. Mikäli se oli protoni, sen nopeus oli noin (1 − (5 × 10−24)) c. Jos tällä nopeudella liikkuva hiukkanen lähtisi liikkeelle yhtä aikaa fotonin kanssa, vuoden kuluttua se olisi vain 46 nanometriä fotonia jäljessä.” 

Myös useammassa muussa artikkelissa kerrotaan nopeudeksi v = 0.9999999999999999999999951 c

tai että c – v ≈ 5·10-15 m/s. Pakkohan se on minunkin laskea, varsinkin kun GeoGebra laskee likiarvoilla vain 15 merkitsevällä numerolla. Lasken varmuuden vuoksi saman laskun myösWolframAlphalla ja Pythonilla.

Ratkaisu GeoGebralla

Lasketaan nopeus käyttämällä Suppeaa suhteellisuusteoriaa ja protonin kokonaisenergiana arvoa 51 J, lukuarvo löytyy englanninkielisestä Wikipedia-artikkelista.

MAOL-taulukkokirjasta löytyvät tarvittavat kaavat.

Kuva, joka sisältää kohteen pöytä

Kuvaus luotu automaattisesti

Kirjoitetaan yhtälö GeoGebran CASiin, ratkaistaan nopeus v ja sijoitetaan arvot. Käytän Ratkaisut-komentoa, jotta saan ratkaisuksi listan, jossa on vain v:n lausekkeet, niitä on mukavampi käsitellä. Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Nopeudeksi saadaan tasan 300000000 m/s. Vaikka GeoGebran asetuksista muuttaa tarkkuuden 15 merkitseväksi numeroksi, niin nopeuden arvo ei muutu.

Jotta lausekkeen arvo lasketaan suuremmalla tarkkuudella, niin tarvitaan Lukuarvona-komentoa. Sen toiseksi syötteeksi voi laittaa halutun tarkkuuden.

Rivillä 6 on sijoituksen tulos, kun käytin Sijoita työkalua ja valitsin Sijoita painikkeen

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Tässä on hyvä hetki muistuttaa bugista, joka on vaivannut GeoGebraa jo jonkin aikaan. Ainakin GeoGebran versionumerossa 666 oli vielä vika, jossa sijoita-työkalun Sijoita-painikkeen painaminen aiheutti virheellisiä tuloksia, kun sijoitetut luvut oli esitetty 3E8-tyyppisesti. Tätä vikaa ei enää ole lokakuun 21 GeoGebran 672-versioissa. Alla 666-version virheellinen sijoitus.

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Lasketaan vielä, kuinka paljon saatu tulos poikkeaa valonnopeudesta muutamalla eri tavalla.

Kuva, joka sisältää kohteen pöytä

Kuvaus luotu automaattisesti

Laskun olisi voinut suorittaa ilman Sijoita-työkalua käyttämällä Sijoita-komentoa.
Sijoita( <Lauseke>, <Korvauslista>)

WolframAlpha ja Python

WolframAlpha on siitä mukava, että se laskee oletuksena isolla tarkkuudella. Tässä syötän luvut uudella MATH INPUT-menetelmällä.

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

WoframAlphan tulos hieman enemmillä desimaaleilla. 2.99999999999999999999998697226643598615916955014472340698701… × 10^8

Pythonissa tulee vastaan samankaltainen laskentatarkkuusongelma kuin GeoGebrassakin. Alla Colabista kaapattuja kuvia.

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Pythonin saa laskemaan mielivaltaisella tarkkuudella vaikkapa mp-math-kirjaston avulla.

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Pari linkkiä

Wikipedia

https://fi.wikipedia.org/wiki/OMG-hiukkanen

https://en.wikipedia.org/wiki/Oh-My-God_particle

John Walkerin artikkeli vuodelta 1994

https://www.fourmilab.ch/documents/OhMyGodParticle/

Monty Hall Pythonilla – osa 2

Pari viikkoa sitten käsittelin Monty Hall -probleemaa Python ohjelmoinnin avulla. Jatkan tässä tarinaa aiheesta. Yleistetään ongelmaa hieman ja saadaan uusia ongelmia ratkaistavaksi. Aiempi artikkeli löytyy täältä.

Ongelma sanallisesti

Wikipediassa perinteinen Monty Hall -ongelma esitetään seuraavasti: ”Monty Hallin ongelmassa kilpailijalla on edessään kolme ovea. Yhden oven takana on palkintona auto, kahden muun takana vuohi. Kilpailija, joka ei tiedä minkä oven takana mikin palkinto on, saa valita ovista yhden. Valittuaan oven hän ei vielä avaa sitä. Jäljelle jääneistä kahdesta ovesta avataan toinen, ja sen takana on aina vuohi. Tämän jälkeen kilpailija saa valita, vaihtaako ensin valitsemansa oven toiseen jäljellä olevaan suljettuun oveen, vai pitääkö ensin valitsemansa oven.”

Yleistetään ongelmaa siten, että vuohien ja autojen määrää voi vaihtaa. Ongelma olisi nyt tämän kaltainen. ”Olkoon v vuohien määrä (v > 1) ja a autojen määrä ( a ≥ 1). Ovien määrä on v + a.  Vuohet ja autot laitetaan satunnaisesti, yksi kunkin suljetun oven taakse. Kilpailija valitsee jonkin oven. Sen jälkeen lopuista ovista poistetaan yksi sellainen ovi, jonka takana on vuohi. Tämän jälkeen kilpailija saa valita, vaihtaako ensin valitsemansa oven johonkin jäljellä olevaan suljettuun oveen, vai pitääkö ensin valitsemansa oven.”

Ratkaisu Pythonilla

Tehdään Pythonilla simulaatio, jossa pelaaja aina vaihtaa valintansa. Tutkitaan aluksi sellaista erikoistapausta, jossa on kolme ovea ja kaksi autoa. Yritän tässä jäljitellä minun tapaani tuottaa ohjelmia, ensin yritän saada ohjelman toimimaan yksinkertaisella versiolla, sitten siirryn monimutkaisempaan tapaukseen. Pyrin myös välttämään kovin pitkiä, vaikeasti luettavia koodirivejä. En myöskään pyri tässä mahdollisimman tehokkaaseen koodin. Tämä on tarkoitettu opiskelumateriaaliksi opettajille ja ohjelmoinnista kiinnostuneille koululaisille ja opiskelijoille.

Koodi

Alla olevat kuvankaappaukset ovat Spyder ohjelmointiympäristön editorin ja konsolin kuvia. Eli kuvassa näkyy ohjelma ja sen tuotos.

Jos olet lukenut edellisen tarinan ja ymmärtänyt sen, niin koodi taitaa olla aika itsestään selvä. Muutamia kommentteja silti. 

Rivit 1-7: Spyderin tuottamaa metatietoa, tämä on ”turhaa”. Toki rivi 2 takaa, että ääkkösten pitäisi toimia.

9-10: Random kirjaston funktiot, shuffle sekoittaa listan ja randint arpoo kokonaisluvun.

13: Luodaan ovet, nollat vuohia ja ykköset autoja eli voittoja.

16: Sekoitetaan ovet-lista.

20: Arvotaan luku väliltä 0, …, 4. Tässä pitää muistaa, että Pythonissa listan ensimmäisen jäsenen järjestysluku on 0. Funktio len(lista) tulostaa lista pituuden eli sen jäsenten lukumäärän. 

28: pop-metodi poistaa olion listasta ja antaa sen tulosteena.  Jos lista  = [13, 42, 666, 42], niin lista.pop(1) antaa tulokseksi luvun 42 ja samalla listasta katoaa jäsen 42, eli nyt lista on [13, 666, 42].

32: remove-metodi poistaa ensimmäisen esiintymän syötteestään. Jos lista  = [13, 42, 42, 666, 42], niin lista.remove(42) muuttaa sen listaksi [13, 42, 666, 42].

37: Sekoitetaan jäljelle jääneet ovet uudestaan.

42: Valitaan ensimmäinen ovi. En enää jaksa arpoa jotain ovea ja sen jälkeen avata sitä, avaan eina ekan oven. Rivin 37 sekoittaminen takaa, että ovi on satunnainen. Saman olisi tietysti voinut tehdä jo rivillä 20, mutta siellä yritin noudattaa alkuperäistä reseptiä.

46-49 Päätöksentekoa voitosta.

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Alla pari suorituskertaa.

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Iterointia

Toistetaan peliä muutaman kerran ja lasketaan kuinka suuri osa tuottaa voittoja.

Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti
Kuva, joka sisältää kohteen teksti

Kuvaus luotu automaattisesti

Ongelmia

Palannen yleiseen ongelmaan lähiaikoina. Nyt varmaankin valistunut lukija pystyy itsekin tuottamaan oman ratkaisunsa tämän kaltaisiin ongelmiin.

1 Jos vuohia on x kpl ja autoja y, niin määritä P(x, y).

2 Milloin P(x, y) > ½? Millainen tasoalue on kyseessä?

3 Kun sinulla on lauseke P:lle. Miten esittäisit sitä fiksuimmin kuvaajana?

4 Etsi pilkkuvirhe artikkelista.

koodi colabissa

täshätää

Jos edellä oleva linkki ei toimi, niin koita toisella selaimella.