Java program memória használatának mérése

Három különböző megközelítésben generálunk szövegeket és töltjük bele ezeket generikus listába. Olyan környezetet építünk, amely képes tesztelni/mérni a Java program/környezet memória használatát előtte/utána. A tárigény (memória, háttértár, feldolgozandó adatok mennyisége, adatforgalom) fontos eleme a hatékonyságnak. Gyakran előfordul, hogy a tárigényt csökkenteni kell egy program tervezése, implementációja vagy továbbfejlesztése során.

Feladat

A Java program előállít 100000 db 20 hosszúságú szöveget véletlen kiválasztott angol ábécé-beli betűkből. A szövegeket generikus listába tölti be. A program méri az általa felhasznált memória méretét/nagyságát úgy, hogy a műveletek előtti és utáni eredményekből különbséget számol. Egyszerű következtetéssel, becsléssel nagy mennyiségű adatra/memóriaterületre számíthatunk, így érdemes megabájt mértékegységet használni.

Közös konstansok

  • final int MIN_LIMIT=(int)'a';
    97, a kis ‘a’ betű, a „legkisebb” generálható véletlen betű/karakter ASCII kódja
  • final int MAX_LIMIT=(int)'z';
    122, hasonlóan a felső korlát
  • final int STRING_LENGTH_LIMIT=20;
    a véletlenszerűen generálandó szövegek hossza
  • final int STRING_COUNT=1000000;
    a véletlenszerűen generálandó szövegek száma, amik generikus listába kerülnek

Három különböző módszer

  • method1():
    Az első módszer esetén String típusú szövegobjektumok keletkeznek úgy, hogy karakterenként kerülnek összefűzésre (konkatenáció) a += művelettel (operátorral). A véletlen karakterek sorszámaira int2char típuskényszerítés szükséges explicit módon (char). A vezérlés egymásba ágyazott ciklusokkal történik.
  • method2():
    A második módszer esetén StringBuilder típusú szövegobjektumok keletkeznek. Szintén karakterenként generálva. Összefűzésüket az append() metódus végzi el. A típuskényszerítés és a vezérlés megegyezik az előző módszerrel.
  • method3() :
    A harmadik módszer során a StringBuilder típusú szövegobjektumokból a Stream API beépített funkcionális műveletei állítják elő a generikus listát. A vezérlés egyetlen ciklusból áll.

Java forráskódok

Íme az első módszert megvalósító metódus. Futtatása 620 MB memóriát igényel:

Ez a második módszer metódusa, amely futása során 235 MB memóriát használ:

A harmadik módszer metódusa. 494 MB „memóriaterületbe kerül” lefuttatni:

A metódusok hívása

Eredmények

A tesztkörnyezet az alábbi eredményeket írta ki konzolosan:

Más nézőpontok

  • Az is mérhető, hogy a program futása közben hány darab objektum keletkezik, melyik mennyi ideig „él”, melyik mennyi helyet foglal. Ez részletesebb képet nyújthat, összevetve a fenti globális helyfoglalással.
  • Figyelhető, hogy az automatikus szemétgyűjtő (Garbage Collector) milyen gyakran fut. Némileg befolyásolható, paraméterezhető a tevékenysége.
  • A forráskód bonyolultsága összefüggésben van annak karbantarthatóságával. Fontos lehet, hogy milyen könnyen dokumentálható, továbbfejleszthető.
  • A memóriafogyasztás szempontjából „túloptimalizált” program verzióváltás(ok) esetén több tesztelést, módosítást igényelhet. Ha egyáltalán valaki hozzá mer nyúlni. 😉
  • A memóriahasználat mérése során figyelembe kell venni, hogy a Java programon kívül Java futtatókörnyezet (JRE) is működik az operációs rendszeren, aminek szintén van erőforrásigénye.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

Bemutattunk többféle módszert, illetve teszteredményeket. Részletes magyarázatot/indoklást most nem adunk a szakmai blogban. A Java SE szoftverfejlesztő tanfolyam szakmai moduljának 17-28. óra Objektumorientált programozás alkalmain természetesen széles körű áttekintést adunk a témakörrel kapcsolatosan, valamint más módszereket is bemutatunk. A hatékonyság klasszikus dimenziói: időigény, tárigény, bonyolultság. Több esettanulmányunk is van, amely egy-egy algoritmus lépésszámát méri, memória- és/vagy sávszélesség igényt mér, illetve elvi és/vagy koncepcionális bonyolultságot próbál meghatározni. Ezek közül többször redukálunk, csökkentünk tipikusan lépésszámot, memóriaigényt.

Egy matematika érettségi feladat megoldása programozással 2022

érettségi logó

érettségi logóA 2022-es középszintű matematika érettségi feladatsor eléggé egyszerű volt, de azért a 6. feladata inspirált arra, hogy a programozás eszköztárával oldjuk meg ezt a feladatot. Szükséges hozzá a megszámolás programozási tétel. Többféle megoldás/megközelítés (iteratív és rekurzív) is előkerül. Érdekes belegondolni, hogy mennyire más lehetne a problémamegoldás, ha programozhatnánk a matematika érettségi vizsgán. A teljes feladatsor a megoldásokkal együtt letölthető az oktatas.hu-ról.

6. feladat

Egy feleletválasztós teszt 5 kérdésből áll, minden kérdésnél négy válaszlehetőség van. Hányféleképpen lehet az 5 kérdésből álló tesztet kitölteni, ha minden kérdésnél egy választ kell megjelölni?

1. megoldás

Rögtön tudjuk, hogy ez kombinatorika, n elem k-ad osztályú ismétléses variációja, amelynek paraméterei: n=4, k=5. A hatványozás azonosságainak ismeretében fejből is tudjuk a megoldást: 45=210=1024. A Java forráskód elvégzi a hatványozást. A Math.pow() függvény általánosabb, mint amire most szükségünk van. Fogad double valós paramétereket és double típusú értékkel tér vissza. Ezért hasznos az (int) explicit típuskényszerítés.

Másképpen: négy elemű halmazból öt elemet kiválasztunk és ezeket sorba rendezzük (permutáljuk) és egy elemet egy csoportban akár ötször is felhasználhatunk. Számít a sorrend. A lehetséges variációk száma: 1024.

2. megoldás

Ha hasznos lenne egy általános metódus az ismétléses variáció kiszámítására, akkor ez egy tipikus megoldás lehet erre. Kiegészítendő még a két paraméter előjelének ellenőrzésével.

3. megoldás

Ha a megértést segíti, akkor a teljes leszámolás (brute force) módszerével, egymásba ágyazott ciklusokkal könnyen kiírathatjuk a konzolra az 1024 db különböző válaszlehetőséget. A k-val kezdődő sorszámozott ciklusváltozók jelölik az öt kérdést, azon belül az 'a'-tól 'd'-ig karakterek adják a válaszlehetőségeket. Eredményül ezt kapjuk (görgethető):

4. megoldás

Ha csak a végeredmény szükséges, akkor ez az iteratív megoldás a megszámolás programozási tétellel előállítja azt.

5. megoldás

Ez egy rekurzív megoldás. Ciklus helyett a metódus önmagát hívja meg, így valósul meg az ismételt utasításvégrehajtás. A válaszlehetőségek összefűzésével (konkatenáció) előállított válasz akkor megfelelő, ha annak hossza öt. Ez esetben kiíródik a válaszlehetőség a konzolra (mintegy mellékhatásként). Ugyanazt az eredményt kapjuk, mint a 3. megoldásnál.

6. megoldás

Szintén, ha csak a végeredmény szükséges, akkor ez a mellékhatással rendelkező rekurzív metódus előállítja azt. A mellékhatás most az, hogy a metódus eljárás és nem függvény és szükséges hozzá a db osztályváltozó (ami a metódushoz képest globálisnak is tekinthető).

7. megoldás

Ez a megoldás a válaszlehetőségeket megfelelteti n alapú számrendszerben k számjegyből álló számoknak. A kétdimenziós tömbben számokat tárol, így:

  • 1,…,1,1 → 0…0000
  • 1,…,1,2 → 0…0001
  • 1,…,1,n → 0…001(n1)
  • 1,…,2,n → 0…001(n1)
  • n,…,n,n → (n1)...(n1)

Végül a kiíró ciklus ezeket a számokat karakterekké alakítja ( 'a' ASCII kódja 97) és fordított sorrendben írja ki, hogy ugyanazt az eredményt kapjuk, mint a 3. megoldásnál.

Továbbfejlesztési lehetőségek

  • A 2. megoldáshoz: teszteljük le a lehetséges túlcsordulást és az int típus helyett szükség esetén használjunk long típust!
  • A 3. megoldáshoz: építsünk kétdimenziós tömb adatszerkezetet, amiből később az i-edik válaszlehetőség megadható!
  • Előzőhöz: állítsuk elő lexikografikus sorrendben az i-edik válaszlehetőséget adatszerkezet felépítése nélkül!
  • A 6. megoldáshoz: valósítsuk meg a rekurzív gondolatmenetet mellékhatás nélkül!
  • Teszteljünk: mennyi idő alatt hajtódik végre a 4. és a 6. megoldás? Mekkora paraméterekkel érzékelhető, hogy a rekurzió jóval lassabban fut?
  • A 7. megoldáshoz: cseréljük le az egésztömb adatszerkezetet karaktertömbre!

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

Ajánljuk matematika érettségi feladat címkénket, mert a témában évről-évre blogolunk.

A feladat a Java SE szoftverfejlesztő tanfolyam szakmai moduljának 5-8. óra: Vezérlési szerkezetek, valamint 21-24. óra: Objektumorientált programozás 1. rész alkalmaihoz kötődik.

KSH táblázatból dolgozunk

KSH-logo

KSH-logoA Központi Statisztikai Hivatal honlapján elérhető STADAT táblákból könnyen kinyerhetjük a nekünk szükséges adatokat. A témastruktúrába sorolt online és XLS exportként is böngészhető táblázatokban megtalálhatjuk logikusan csoportosítva összesítve az adatokat régiónként (megyénként), évenként, százalékosan. Az XLS fájlformátum Java nyelven a JExcel API-val hatékonyan feldolgozható. Lássunk erre egy példát!

Feladat

A KSH 2.1.2.35. táblázatából gyűjtsük ki a 19 magyar megyére + Budapestre vonatkozóan a gazdaságilag aktívak létszámát és az első évet alapnak tekintve adjuk meg évenként a változást százalékosan!

Tervezés

A KSH témastruktúrában a táblázat elérési útja:

  • 2. Társadalom,
  • 2.1. Munkaerőpiac,
  • 2.1.2. A munkaerőpiac alakulása Magyarországon (1998–2018) -> Területi adatok,
  • 2.1.2.35. A 15–64 éves népesség gazdasági aktivitása megyénként és régiónként (1998–2018)

Online böngészhető táblázat:
https://www.ksh.hu/docs/hun/xstadat/xstadat_hosszu/mpal2_01_02_35.html.

Letölthető táblázat (XLS formátumban): https://www.ksh.hu/docs/hun/xstadat/xstadat_hosszu/xls/h2_1_2_35.xls.

A táblázat A oszlopában szerepelnek a régiók, megyék, időszakok (vegyesen, szövegként) és a D oszlopában a gazdaságilag aktívak (ezer fő, valós számként). A fejlécet nem szabad feldolgozni. 1998-tól 2018-ig 546 sorból áll az adatsor. A csoportosítás 26 régiót és megyét tartalmaz, amiből a 6 régiót (például: Közép-Dunántúl) ki kell hagyni.

A megyékre vonatkozóan 440 sort kell feldolgozni. Ebből az első sor a megye (vagy Budapest) neve, a többi (2019-ben 21 db) sorban találhatók az adatok (időszak). Olyan algoritmusban érdemes gondolkodni, ami a jövőben is működik. Ha csoportváltást alkalmazunk, akkor nem számít, hogy megyénként minden évben egy sornyival több adat lesz majd. A KSH táblázatok szerkezete nagyon ritkán változik, így bátran írható rájuk testre szabott forráskód (ezeket nem kell évente frissíteni).

Az évenkénti változást százalékosan nem tartalmazza a táblázat, ezt nekünk kell kiszámítani. A valós számok formázását érdemes egységesíteni, például a gazdaságilag aktívak létszámát 3 tizedesre, a változást 2 tizedesre kerekítve.

A belső adatábrázolást érdemes átgondolni. Hasznos, ha az időszakhoz tartozó három összetartozó adatot egyetlen Data POJO-ba fogjuk össze ( String period, double active és double change). Ezeket generikus listába szervezve ( ArrayList<Data> list) könnyen hozzájuk rendelhető a megye ( String county) és ezek együtt alkotják a Region POJO-t. A Region és Data kapcsolati fokszáma: 1:N. 2019-ben N=21 .

Részlet a megoldásból

A JExcel API használatához a Java projekthez hozzá kell adni a jxl.jar fájlt. A XLS fájl olvasható közvetlenül a webről is, de egyszerűbb helyi fájlrendszerbe mentett változatból dolgozni ( ./files/h2_1_2_35.xls). A megyék nevében található ékezetes karakterek miatt ügyelni kell a megfelelő karakterkódolásra ( Cp1252). A munkafüzet azonosítását követően hivatkozni kell a feldolgozandó munkalapra ( 2.1.2.35.). Az adatfeldolgozás során kihagyott régiókat (kivételeket) érdemes listába gyűjteni ( skipRegionList). A csoportváltást a két egymásba ágyazott ciklus valósítja meg. Ügyelni kell az adatok formátumának ellenőrzésére.

Eredmények

Például Somogy megyére az alábbi adatokat kapjuk eredményként (XLS formátumban, Excel-be betöltve, tipikus háttérszín kiemeléssel: szélsőértékek a C oszlopban, negatív értékek a D oszlopban):

KSH-result

További programozható feladatok

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java SE szoftverfejlesztő tanfolyam tematikájához kötődik (ha az XLS fájlt a helyi fájlrendszerből érjük el), és a Java EE szoftverfejlesztő tanfolyam tematikájához kapcsolódik (ha az XLS fájl tartalmát közvetlenül a webről olvassuk).

Kommunikáció a Mars és a Föld között

Mentőexpedíció

MentőexpedícióBevezető, avagy a szomszéd messze van

Képzeljünk el egy helyzetet, amikor egyik barátunkat, családtagunkat felhívjuk telefonon, és videótelefonálást folytatunk vele, mobiltelefon segítségével egy látványos helyről. A mai technológia segítségével ennek a lehetősége már bárki számára hozzáférhető áron rendelkezésre áll. Ráadásul a kommunikáció szinte tökéletes, láthatóan késleltetés nélküli. Ám tételezzük fel, ha ezt a kommunikációs tevékenységet a Föld két távolabbi pontja között végezzük, mondjuk Magyarországról folytatunk videótelefonálást a 18000 km-re fekvő Új-Zélandra. A helyzet minimális szinten megváltozik, hiszen a nagy távolság következtében a fizikai törvényei itt már emberi léptékben is érzékelhető korlátot szabnak a kommunikáció sebességének. Persze nyugodtan mondhatnánk azt, hogy na és? Joggal, hiszen az átlagember számára fel sem tűnik, hogy az általa halott beszéd, és az általa látott kép a valóságban kevesebb, mint egy másodperc késéssel érkezik meg a küldőtől a fogadóhoz.

Ha ezt elképzeltük, és megvan a 18000 km-nyi távolság és a közel 1 mp-es késleltetés, ugorjunk egy nagyobb léptékre, melynek apropójaként hívjuk fel barátainkat telefonon a Marson. Most csak egy egyszerű példa kedvéért, eltekintve a légköri jelenségektől, a műholdak aktuális helyzetén át, a napszél tevékenységig minden más további hatástól, a Mars-Föld távolság átlagos értékével számolva. Legyünk türelmesek, hiszen a bolygók közti aktuális távolság függvényében, a fénysebesség korlátainak figyelembevételével a késleltetés meglehetősen nagy lesz. Fel fogják venni a telefont. Ne, még ne tegyük le! Igen, tudom, hogy már eltelt tíz perc, de várjunk még! Biztosan fel fogják venni a telefont. És ez a 12. percben meg is történik. A vonal végéről nem hallunk semmit? Nem csoda. Hiszen a mi jelentkezésünk 12 perc alatt ért a Marsra, és újabb 12 percet kell várni arra, hogy meghalljuk barátaink reagálását. Ugye, hogy nem is olyan egyszerű ez a bolygóközi kommunikáció?

Egy kis matematika az előzőekhez:

A Föld-Nap átlagos távolság 8,3 fényperc, ami 149,6 millió km-es távolságot jelent. Ezt alapul véve, és mivel tudjuk, hogy a Föld-Mars átlagos távolság 225 millió km, könnyen kiszámolható, hogy a két bolygó között a fény fotonjai 12,48 perc alatt teszik meg az utat. Tehát jelen technológiákkal (a két bolygó átlagos távolsága esetében) 12,48 perc alatt lehet adatot továbbítani a két égitest között. Érdekesség, hogy 2003-ban a Mars mindössze 56,3 millió km-re volt a Földtől. Gyors számtan: a távolság 3,12 fényperc. (Legközelebb 2287-ben lesz ilyen alkalom.) Azonban 2005-ben a vörös és kék bolygó mértani távolsága elérte a 402,3 millió km távolságot, azaz a 22 fénypercet. További gondolatébresztőként megemlítendő, hogy minden évben van egy két hetes időablak, amikor a Mars a Nap mögé bújik, ezáltal a kommunikáció teljesen megszakad vörös szomszédunkkal. Ebből aztán kiderül, hogy adott dátumtól függően, a Mars és a Föld között általában 7 és 44 perc között zajlik le egy „kérdés+válasz” jellegű kommunikáció.

A Mentőexpedíció című film

A fenti bevezetőből kiindulva, vegyük górcső alá az Andy Weir 2011-es A marsi című regénye alapján készült 2015-ös Mentőexpedíció című filmet. Aki nem ismerné, annak röviden annyit érdemes tudnia, hogy egy kutatócsoport heves időjárási tevékenység miatt menekülni kényszerül a Marsról. A csapat egy ember híján sikeresen eljut a felszállásra kész űrhajóig, amellyel feljutnak a űrben keringő Hermes anyahajóra. Később a Marson hagyott űrhajósról kiderül, hogy a viharos erejű szelet túlélte, bár ő maga, és űrruhája is megsérült. A következő jelenetekben Mark Watney űrhajós számára realizálódik, hogy egyedül maradt a bolygón, a következő küldetés pedig négy év múlva érkezik. Tehát három fő feladata van:

  • Egy ember számára lakhatatlan bolygón, a rendelkezésre álló eszközökből biztosítania kell az életben maradásához szükséges feltételeket, mint amilyen az élelem, a víz, és az oxigén. Ez megoldhatónak tűnik, hiszen főhősünk botanikus. Növénytermesztéssel létrehozható egy alacsonyszintű ökológiai körforgás.
    Megjegyzés:
    Fontos megemlíteni, hogy a marsi talaj a nagy hőingadozások miatt rendkívül porózus, továbbá olyan anyagokat tartalmaz (például földpátok, piroxének, olivinek), amik a vízzel vegyülve az emberi szervezet számára méregként hatnak. Például a marsi por belélegzése során, a tüdőben található nedvességgel érintkezve gáz formájában, vagy a véráramba jutva halált kiváltó vegyületek jöhetnek létre. Ehhez képest Mark, ránézésre több száz kg-nyi marsi talajt a lakrészbe talicskáz, és vizzel öntöz. Az ehhez szükséges vizet, az egyik űreszközben található hidrogén elégetésével nyeri, a marsi talajt pedig emberi végtermékkel trágyázza, miközben a növények oxigént termelnek. Ez filmben jól néz ki, de fent már kifejtettem, hogy a marsi talaj az emberi szervezet számára veszélyes lehet. További kérdést vet fel, hogy az emberi végtermék vajon megfelelő tápanyagokat rejt-e, a burgonya növekedéséhez. Ezen kívül az is kérdés, hogy az a szobányi növény termel-e elegendő oxigént. Mindenesetre főszereplőnk ezen feladatát megoldotta.
    Természetes, hogy ha minden kihívást figyelembe vettek volna a filmkészítők, akkor vagy nem készül el a film, vagy megválaszolják a NASA, valamint más űr- és bolygókutató vállalatok kérdéseit.
  • Második feladataként meg kell oldania, hogy a marsjáró roverrel eljusson a 3200 km-es távolságban fekvő Schiaparelli-kráterhez, ahová négy évvel később érkezik a következő küldetés legénysége.
    Probléma:
    Ez számos problémát vet fel, főleg mert a marsjáró egy feltöltéssel elérhető hatótávolsága csak 35 km, ráadásul a járgány fűtése rögtön elviszi a rendelkezésre álló energia felét. Ezen hátrányok meglehetősen érdekesek annak tükrében, hogy a mai járművek akár 350 km-es távolságot is könnyűszerrel megtesznek, a marsjáró légmentes kialakítása és megfelelő szigetelő anyagok használata révén pedig a fűtésre fordított energia jelentősen csökkenthető. Főleg ha elképzeljük milyen fejlesztések zajlanak le a 2030-as évekig. Tény persze, hogy a laza marsi talajon, egy teherautó méretű, nyolckerekű járművel közlekedni több energiát igényel, mint egy kisebb négy kerekű járművel haladni az aszfaltozott úton, azonban arról se feledkezzünk el, hogy a Mars felszíni tömegvonzása harmada a Föld felszíni tömegvonzásának. Mindenesetre a filmbeli főhősünk a fűtés problematikáját a radioizotópos termoelektromos generátor segítségével oldotta meg, a marsjáró hatótávját pedig egy másik, amúgy megsérült marsjáró akkumulátorainak felhasználásával duplázta meg. Így a mozi szerint 70 km távolságra tud eljutni egyetlen feltöltéssel. Ekkor kipakolja a napelem cellákat, és újratölti az akkumulátorokat.
  • Továbbá fel kell vennie a kapcsolatot a Földdel. Ez utóbbinak nem lenne akadálya, azonban a vihar tönkretette a kommunikációs berendezéseket, valamint az antennát is. A filmtől elvonatkoztatva egy ilyen eset vélhetően nem történhetne meg, ugyanis a tartalék rendszer rendelkezésre állna (dobozokban földbe ásva, dobozokban bent a lakrészben, vagy bármi más módon, amit a szakemberek alkalmasnak találnak erre a célra). A kommunikáció a Földdel gyakorlatilag életfeltétel. Máskülönben az is igaz, hogy a tartalékrendszerek Marsra szállítása extra költségekkel járna.

A film tartalma, valamint a kialakult problémák ismertetése után merüljünk bele a részletekbe, valamint az érdekes, ismert és még ismeretlen fogalmakba!

A sol fogalma

A történet teljes egésze alatt többször elhangzik egy csillagászati fogalom, ez pedig a sol. A sol tulajdonképpen a szoláris nap rövidítése, azonban használata némi bonyodalmat okoz, hiszen a sol-t, mint mértékegységet a NASA 1976-ban az első Viking űrszonda landolásakor, a marsi napok múlásának mérésére vezette be házi használatra. Jelenleg a sol egy hivatalosan nem elfogadott időegység, azonban általánosan elfogadható, hogy 1 sol esetében 1 szoláris marsi nap hosszáról beszélhetünk.

Kiegészítés:

Noha logikus lenne olyan egyértelműsítő fogalmakat bevezetni, hogy 1 földi sol, vagy 1 marsi sol, ennek ellenére az egyébként sem hivatalos időegységet ne bonyolítsuk tovább! Összehasonlításképpen 1 földi szoláris nap ~24 óra 3,5 percnek, 1 (marsi) sol pedig ~24 óra 39,5 percnek felel meg. Ez azt jelenti, hogy a Marson egy általános értelemben vett nap hossza több, mint fél órával tovább tart. További gondolatébresztő érdekesség, hogy a Földön a szoláris nap ritkán használatos. A Földön a csillagnapot szoktuk használni, ez pedig közel azonos – 0,008 s az eltérés – a Föld tengely körüli megfordulásának idejével, ami ~23 óra 56 perc. A csillagnap során azt figyeljük meg, hogy – a Földről nézve – az égbolton a távoli csillagok, mennyi idő alatt tesznek meg egy teljes fordulatot. A Föld csillagokhoz mért óriási távolsága miatt a Föld Nap körüli pályán történő mozgása egy nap alatt szinte elhanyagolható tényező. A szoláris nap esetében viszont ezzel a tényezővel is számolni kell, hiszen a Föld-Nap távolság rendkívül kicsi. Mialatt a Föld megfordul a saját tengelye körül, a Nap körüli pályán egy másik pozícióba kerül, ez utóbbi pedig már jelentősen befolyásolja a szoláris nap hosszát.

Részecske szinten a Marsig tartó út hossza

A filmben többször is elhangzanak változó utazási adatok arról, hogy mennyi idő alatt lehetséges eljutni a Földről a Marsra, illetve vissza. A jelenlegi technológiákkal ez jellemzően 5 és 10 hónap között változhat, attól függően, hogy éppen milyen a bolygók egymáshoz viszonyított aktuális állása. Az sem mindegy, hogy mekkora energiabefektetéssel szeretnénk elérni a vörös bolygót. Erre a megfelelő indítási ablak 26 havonta alakul ki, ami azt jelenti, ekkor áll rendelkezésre néhány olyan nap, amikor hatékonyan el lehet érni a Marsot. 2018-ban az InSight űrszonda nagyjából 5,5 hónap alatt jutott el a szomszédos égitestre, a kilövéstől a leszállásig számolva.

Részletek:

Itt fontos megemlíteni a Hohmann-pályát, mint pályamódosító görbét. Ennek lényege nagyjából úgy néz ki, hogy a Marsra történő utazás során, a Föld körüli pályát a rakétahajtóművek megfelelő ideig történő begyújtásával elhagyjuk. Ezzel a kör alakú pályát egy elliptikus pályára cseréljük le. A gyorsításnak olyan mértékűnek kell lennie, hogy a Nap körüli marsi pályát elérjük. Amikor ez megtörténik, a rakétahajtóműveket ismét be kell gyújtani annak érdekében, hogy az ellipszis alakú pályáról rá álljunk a Mars keringési pályájára. És itt jön képbe a megfelelő indítási ablak, ugyanis a Földről akkor kell elindulni, amikor az ellipszis pálya csúcspontjára érkezve, a Mars még éppen nem érkezett meg. Fontos tudni, hogy a Mars majdnem kétszer annyi idő alatt kerüli meg a Napot, mint a Föld. Tehát a Mars a külső pályán lassabban halad. Ez azt jelenti, hogy ha kicsúszunk az indítási ablakból, akkor a Mars pályáját elérve, a vörös bolygó már mögöttünk lesz. Így gyakorlatilag hónapokig keringhetünk a Nap körül, miközben nem kevés energiát ölünk bele a lassításba, és számos pályakorrekcióba, hogy a Mars utolérjen minket. Korábbi indulás esetén pedig pont azért kell a több energia, hogy hamarabb elérjük a Marsot, majd a nagy sebesség miatt, a találkozóhoz le is kell lassítani.

Kapcsolatfelvétel a Földdel: a hardver környezet kialakítása

Miután főhősünk realizálta, hogy egyedül maradt a Mars felszínén, és a következő küldetés csak négy évvel később érkezik, elkezd azon töprengeni, hogyan biztosítsa maga számára az életben maradáshoz szükséges feltételeket. Ezeket a fentiekben már ismertettem. Már csak kapcsolatba kellene lépnie a Földdel. Ekkor születik meg Mark fejében az ötlet, hogy felkutassa a Pathfindert, mely a marsjáróval immáron elérhető távolságba került. A Pathfinder űrszonda megtalálása kommunikációs csatornát nyit a NASA felé. Csupán annyit kell tennie, hogy kiássa, és a vélhetően elhasználódott, tönkrement akkumulátor kazettát kicserélje. A Pathfinder űrszonda a Discovery program második küldetésében vett részt 1997-ben. Feladata a légkör elemzése volt, továbbá magával vitte a kis Sojourner rovert is, mely a kövek vizsgálatát végezte. Felmerül a kérdés, hogy a főhős honnan ért ilyen sok mindenhez, hiszen botanikus. Az igazság az, hogy egy Marsra juttatott embernek nagyon sok mindenhez kell értenie. Kicsiben például egy weblap készítő szakembernek nem árt ha a kódolás mellett vannak grafikai ismeretei is. Egy katonai repülőgép pilótájának sem csak a gépet kell tudnia vezetni, de ahhoz is kell értenie, hogyan éljen túl egy ellenséges területre történő lezuhanást. Lényeg, hogy ha az ember egy adott szakterületen dolgozik, akkor a rá váró kihívásokra gyorsan tudjon reagálni. Feltételezhető, hogy a Marsra utazó személyek egy nagyjából 15-25 éves korban lévő, nagy létszámú, de már erősen megszűrt halmazból kerülnek ki, akiknek a kiválasztásuk után még akár 15-20 évnyi tanuláson és fejlődésen kell átesniük, hogy alkalmassá váljanak egy marsi kutató misszióban betölthető szerepre. A NASA jelenleg már futtat ilyen programot.

Magyar vonatkozás a filmben:

A film 48. percének 18. másodpercében, a háttérben lévő polcon egy Rubik-kocka látható.

Kapcsolatfelvétel a Földdel: a megvalósítás

Szóval megvan a Pathfinder, és sikerül működésre bírni. Eközben a NASA a műholdak segítségével felfedezte, hogy az űrhajós életben van, és mozgását folyamatosan követte. Mivel ennek művelete prioritásba került, ezért a NASA a Mars körül keringő műholdak pályáját úgy módosította, hogy az eredeti 41 óránként lezajló 17 perces szünet helyett legfeljebb 4 percig tartson egy szünet. Miután a Földön kiderült, hogy Mark a Pathfinder segítségével szeretné felvenni a kapcsolatot a Földdel, a NASA egyből a JPL-t hívta segítségül. A JPL a Jet Propulsion Laboratory, amit Kármán Tódor alapított, és ő volt az első igazgatója is. Rakétafejlesztő központnak indult, ám napjainkban fő területe a bolygókutató eszközök fejlesztése, és üzemeltetése, így a feljuttatott űreszközök kapcsolati csatornájának végpontján is ők vannak. Az ő termékük többek között a Pathfinder is. A Pathfinder orbitális egység nélkül, közvetlenül kommunikál a Földdel. Ez látható is a filmben akkor, amikor Mark az irányított antennát a Föld felé fordítja. Időközben a Földön a JPL kihozza a raktárból a Pathfinder másolatát, majd a két eszközt szinkronizálja egymással. A marsi szonda üzembe helyezése lehetővé teszi Mark számára, hogy elküldje magáról az első fotót, maga elé tartva egy táblára írt kérdéssel:

„Veszitek az adást?”

A fentiekben már említettem, hogy a Föld-Mars távolság miatt az adatok továbbítása sok időt vesz igénybe, azonban nagyobb probléma, hogy a kamera segítségével Mark ugyan tud hosszú szöveges üzeneteket, kérdéseket fotózott formában továbbítani a Földre, azonban a Pathfinder nem képes arra, hogy a Földről érkezett válaszokat bármilyen formában is megjelenítse. Viszont a JPL képes arra, hogy távolról irányítsa az űrszonda kameráját. Ezt használja ki Mark azzal, hogy első üzenetében egy eldöntendő kérdést tesz fel. Egymástól távol, egy IGEN és egy NEM táblát cövekel le a talajba, ő pedig beállt közéjük, egy harmadik táblával a kezében, amin a kérdés szerepel. A JPL pedig válaszként a kamera fejét a megfelelő tábla irányába fordítja.

Mentőexpedíció

A filmből sajnos nem derül ki, hogy a fotót a Pathfinder mi alapján készítette el pont abban a szögben. A fotó valószínűleg automatikusan készült. Ez azt is feltételezi, hogy a Pathfinder folyamatosan készítette a fotókat, és küldte azokat a JPL részére. Ami viszont biztos, hogy az űrszonda rövid idő alatt több fotót is készít, ezeket küldi el a megfelelő paraméterekkel a JPL-nek, a földi vevőegység pedig a képeket panorámaképként összeillesztve jeleníti meg.

Kapcsolatfelvétel a Földdel: „hexadeci segít a bajban”

A kapcsolatfelvétel sikeressége után a kommunikáció fejlesztése a cél.  Ezen nyilván mind a két oldalon dolgoznak, ám első körben főhősünk ötlete lendít egyet az ügyön. Az eldöntendő kérdésekkel a JPL nem tud megfelelő válaszokat adni, hiszen korlátot szab, hogy csak a kamera fejének mozgatásával tudnak üzenetet küldeni. Mark kitalálja, hogy a JPL-nek hexadecimális ASCII kódrendszerben kell válaszolnia a kérdésekre. Ez azt jelenti, hogy a Pathfindert az angol ábécé 26 betűjét, illetve további 10 számjegyet, esetleg írásjeleket tartalmazó táblák helyett csupán 16 táblával kell körbe rakni. Tíz tábla a számjegyeknek, további hat tábla pedig a betűknek A-tól F-ig. Ezzel, valamint az ASCII kódtábla segítségével két hexadecimális helyiértéken 256-féle szimbólum jeleníthető meg, úgy mint az angol ábécé kis- és nagybetűi, számok, írásjelek, illetve jelen esetben kevésbé fontos vezérlőkódok. Így minimális mennyiségű tábla kihelyezésével megfelelő kommunikáció érhető el, hiszen ha túl sok tábla kerülne kihelyezésre, úgy nehezebben lehetne észrevenni, hogy az űrszonda forgatható kamerája melyik tábla irányába néz.

Mentőexpedíció

A film ugyan nem mutatja, de feltételezhető, hogy a Pathfinder valamilyen időközönként, talán egy változáskövető/szinkronizáló algoritmus segítségével folyamatosan fotókat küld a JPL részére. Az ottani mérnökök a képek alapján így hamar rájönnek, hogy Mark milyen módszerrel szeretné fejleszteni a kommunikációt. Ennek révén a JPL csapata is ugyanazokkal a táblákkal bástyázza körbe az űrszonda másolatát, majd ennek elkészülte után azonnal el is küldik az első üzenetüket.

Mentőexpedíció

Filmbeli baki?

A film 52. percének 12. másodpercében, amikor Mark az első Földről érkezett ASCII üzenetet dekódolja papíron, az ASCII kódok második sorának végén egy kérdőjel látható. A valóságban ott nem kérdőjelnek kellene lennie, hanem 3F-nek. A kérdőjelnek pedig a 3F alatt kellene lennie, ugyanis a „?” ASCII kódja 3F. Az megint egy másik kérdés, hogy amikor a Pathfindert körbe rakja táblákkal, akkor az egyik táblán van egy kérdőjel, illetve a JPL központjában a pizzás dobozra felvázolt terv is számol egy kérdőjel karakterrel. Persze innen nézve nincsen szó bakiról, ám kérdés, hogy vajon miért kellett azt a plusz kérdőjel táblát elhelyezni.

Mentőexpedíció

Kapcsolatfelvétel a Földdel: chateljünk a Föld és a Mars között

A kommunikáció újabb szintre emelésének egyik momentuma, amikor a NASA által megadott módon, a marsjáró operációs rendszerét úgy frissítik, hogy az kommunikálni tudjon a Pathfinderrel. Ennek egyik érdekessége, hogy a marsjárót a NASA fejlesztette, a Pathfindert viszont a JPL. Ebből is látható, hogy a szabványok használata mennyire megkönnyíti a rendszerek közti átjárhatóságot, hiszen főhősünknek csupán egy rövid kóddal kell módosítania a marsjáró operációs rendszerét, így az használni tudja az űrszonda rádiófrekvenciáját. (Más kérdés, hogy egy ilyen minialkalmazás miért nincs eleve beépítve a marsjáróba?) Továbbá a rendszer valószínűleg egy egyedi fejlesztésű Linux alapú operációs rendszer, mely úgy került megírásra, hogy az operációs rendszer a marsjáróból is módosítható legyen. További érdekesség, hogy a szoftver módosítása a film 54. percében mutatott képek szerint hexadecimális gépi kóddal történik. Tulajdonképpen a módszer lehetséges, azonban a NASA-nak – a JPL-en át – a hagyományos ASCII kódtáblázat segítségével kell ezt lekommunikálnia, ami egy meglehetősen hosszadalmas folyamat lehet.

Mentőexpedíció

Érdekesség még az is, hogy miközben Mark módosítja az operációs rendszert, az életben maradásához szükséges levegőt nem a marsjáróból vételezi, hanem a szkafanderéből. Űrhajós sisakja végig a fején van. Feltételezhető, hogy az operációs rendszer módosítása után egy önellenőrző tesztet is futtatni kell. A rendszer újraindítása a jövőben már nem biztos, hogy feltétel lenne.

Filmbeli baki?

A történetben az hangzik el, hogy az operációs rendszer módosítása után a NASA ráállíthatja a marsjárót a Pathfinder rádiófrekcenciájára. Ez nyilván nem lehetséges, hiszen ahhoz, hogy Mark kommunikálni tudjon a marsjáró segítségével a Földdel, előbb szükség van az űrszonda – mint adattovábbító eszköz – közbeiktatására. Vagyis a NASA nem tud kommunikálni közvetlenül a marsjáróval, így közvetlenül nem is tud segíteni az űrszondával történő összeköttetés létrehozásában. Ellenkező esetben a kapcsolat már korábban élt volna, valamint nem a JPL folytatna kommunikációt az űrhajóssal, hanem a NASA.

A kapcsolat létrejötte után, immáron egy chat felületen zajlik a beszélgetés a JPL és Mark között. Feltételezhető, hogy a marsjáró már eleve rendelkezett valami szöveges üzenetek fogadására és küldésére alkalmas programmal. Innentől már sokkal könnyebb a kommunikáció, bár még mindig nem annyira, mint ahogyan az a filmben látszik. Ahogy nézzük az eseményeket, úgy érezzük, mintha csak a Földön chatelnének egymással. Azonban a valóság még mindig az, hogy egy kérdés-válasz kör 32 percig tart. Tehát, amikor Vincent megkérdezi a JPL-t, hogy a társai hogyan fogadták a hírt életben maradásáról, az üzenet elküldése után legalább 32 percet vár a válaszra. Mivel válasz nem érkezett, ezért egy újabb üzenetet küld el korábbi érdeklődését illetően, melynek a válaszára ismét legalább 32 percet vár. Gondoljunk csak bele, hogy ez mennyire idegtépő lehet, továbbá arról se feledkezzünk meg, hogy még itt a Földön zajló kommunikáció esetében is mennyire egyszerű egymás „szavába” vágni, hát még ilyen késleltetéssel rendelkező üzenetváltás esetén.

Az ellátmány-küldetés

Az első beszélgetések során Mark megtudja, hogy a NASA egy ellátmány-küldetést állít neki össze. Ez annyit jelent, hogy a JPL rohamtempóban megtervez és megépít egy teherszállításra alkalmas űrszondát, melyet eljuttatnak a Marsra. Érdekesség, hogy ekkor a bolygók rossz állása miatt az utazás megtételére kilenc hónap áll rendelkezésre.

Érthetetlen?

Bár az ellátmány-küldetés elkészítését az ideális hat hónap helyett a NASA csupán három hónapra rövidítette, mégsem készült egy probléma esetén azonnal indítható tartalékpéldány. Abban az esetben, amikor egy űrhajós egy idegen bolygó felszínén ragad, és ellátmány-küldetést kell számára eljuttatni, erősen kétséges, hogy a valóságban is csak egyetlen hajóval számolnának. Sokkal valószínűbb, hogy más űrügynökségek segítségét is igénybe vennék, és szükség esetére építenének még egy, vagy kettő redundáns példányt. Annál is inkább mert hasonló eset nem egyszer már a valóságban is megtörtént. Amikor a Nemzetközi Űrállomásra (ISS) indult ellátmány-küldetés, az néhány esetben kudarcba fulladt (2014: Orb-3, 2015: Progressz M–27M,  SpaceX CRS-7). Ez azonban nem jelentett veszélyt az űrben tartózkodók életére, mert minden esetben rendelkeznek annyi tartalék élelmiszerrel és más szükséges erőforrásokkal, hogy egy ilyen balul elsült küldetés ne okozzon közvetlen életveszélyt.

A jövő: kvantumkommunikáció

A kommunikáció sebességének felgyorsításán talán épp a modern fizika segíthet a jövőben. A részecskék kvantum-összefonódásának jelensége meglehetősen biztató eredményekkel kecsegtet.

További részletek:

2017 nyarán kínai kutatóknak sikerült adatot továbbítani 1200 km-es távolságba késleltetési idő nélkül. Ez gyakorlatilag a sci-fi történetekben fellelhető teleportálásnak feleltethető meg. Amennyiben ez a mindennapi gyakorlatban is megvalósulna, az szinte olyan lenne az emberiség számára, mint a tűz birtokba vétele, a fémeszközök használatának kezdete, a kerék feltalálása vagy a csavart kötél alkalmazása. Az információ késleltetés nélküli átvitelénél gyorsabb megoldás gyakorlatilag nem létezhet (leszámítva az időben visszaküldött információt, de ez már sokkal mélyebben az elméleti fizika asztala).

A kvantumkommunikáció a kvantum-összefonódás alapjain nyugszik. Ez annyit jelent, hogy egy részecskepár – például foton vagy neutron – két részecskéje között olyan jellegű kapcsolat van, hogy az egyik állapotának megváltozása akkor is hatással van a párjára, amennyiben közöttük több millió fényévnyi távolság van. Tehát ha a részecskepárokat szétválasztjuk egymástól, és két különböző helyre visszük őket, a közöttük fennálló kapcsolat ebben az esetben sem szakad meg. Amennyiben az egyik részecskében változást idézünk elő, arra a másik részecske – függetlenül a távolságtól – azonnal reagál, így az információ átadás azonnali, szám szerint 0 ms.

2019 szeptemberében a Google és a NASA kutatóinak sikerült egy olyan kvantumszámítógépet megépíteni, amely a betáplált feladatot 3 és fél perc alatt végezte el, szemben a mai hagyományos számítógépek tízezer évig tartó számítási idejével. Sajnos a hírt érdemes fenntartással kezelni, mert a NASA webhelyén közzétett cikket végül törölték.

A blog bejegyzés írása közben a hangulatról az AMAZING SPACE TRAVELING ~ Ambient Music ~ Background Music gondoskodott.

A blog bejegyzés képei az említett Mentőexpedíció (2015) című filmből származnak.

ASCII művészet Java-ban

ASCII Art 4

ASCII Art 1Átte­kint­jük a ka­rak­ter­a­la­pú raj­zo­lás le­he­tő­sé­ge­it Java 2D gra­fi­ká­val, illetve a ka­rak­ter­fü­zé­rek kép­ként va­ló ke­ze­lé­sé­nek újabb le­he­tő­sé­ge­it is.

Az ASCII művészet jelentése és kezdete

Az ábécék betűiből/szövegeiből kialakított ábrák egyidősek lehetnek az írásbeliséggel. A technológiától függetlenül a karakterekből kialakított kép megjeleníthető: papír és penna vagy írógép, illetve számítógép és nyomtató vagy monitor segítségével.
Az ASCII művészet (ASCII art) tágabb értelemben a szövegalapú vizuális művészetre vonatkozik. Szűkebb értelemben véve a számítógépes grafika részterületének tekinthető. Az ASCII művészet számítógépet használ nyomtatható standard ASCII kompatibilis karakterekből álló képek készítéséhez és megjelenítéséhez. A képeken a képi elemek a nyomtatható karakterek, amelyek a pointilizmushoz hasonló optikai effektust mutatnak.
A művészeti ág indulása arra vezethető vissza, hogy a korai nyomtatókkal nem lehetett grafikát nyomtatni, a monitorokon nem lehetett grafikát megjeleníteni. Cégek, programok bannerjeinek, logóinak készítésére pedig akkor is volt igény. Ezek mellett például prezentációkhoz, kapcsolási rajzokhoz is használták az ASCII művészetet, valamint természetesen a korai e-mailekben is. A grafikus kártyák megjelenése előtti időkben pedig a videójátékok „grafikája” is ezzel a technikával készült.
Most nézzünk meg néhány lehetőséget saját programmal való képkészítésre.

ASCII képek rajzolása programozási alapismeretek tanulásakor

Saját programmal már az alapok tanulásakor készíthetők ASCII képek a vezérlő szerkezetek megismerése kapcsán. Az alábbi képek bemutatják a lehetőségeket.

ASCII Art 2

További sok-sok kép található az alábbi weboldalakon:

A 2D grafikával való szövegrajzoláshoz használható BufferedImage osztály

A BufferedImage osztály a java.awt.image csomag része. Az Image osztály utódja. Hozzáférhető képadat-puffert tartalmaz, colorModel-ből és képadatok raster-éből áll. A raster sampleModel-jében a sávok számának és típusainak illeszkedniük kell a színt és átlátszó (alpha) komponenseket megadó colorModel által megkívánt számhoz és típusokhoz. A BufferedImage típusú objektumnak van bal felső koordinátája (0, 0), ezért a létrehozásához használt raster-nek kell legyen minX=0 és minY=0 értéke. A BufferedImage osztály a raster fetch és set metódusaira, valamint a colorModel színmódosítási módszereire támaszkodik.

Szöveg képként megjelenítése karakterekkel a konzolon

A kép méretét beállítjuk. A Graphics2D osztály drawString() metódusával String-et képként jeleníthetünk meg. Bár elég „munkás”, de Java-ban gyakran BufferedImage példány létrehozásával oldjuk ezt meg, és a Graphics példányt attól kérjük el. A Graphics2D osztály karakterfüzérek rajzolásakor egyszerű mátrixszerű technikát használ. A String-et kirajzoló mátrixrészek nullától különböző értéket kapnak. A megjelenítendő terület értékét egyszerű adatként, például int-ként kell megadnunk, nem RGB színértékekkel. Ehhez a képtípust int-módba állítottuk: BufferedImage.TYPE_INT_RGB. Az ASCII képek alapötlete az, hogy a képmátrix nem nulla indexeihez hozzárendelt értékeket a kívánt művészi karakterrel helyettesítjük. A nulla értékű mátrixindexeknek szóközt adunk. A nulla integer-módban -16777216-tal egyenlő. Ezután a Java 2D grafika haladó renderelő beállításainak használatához kasztoljuk a Graphics objektumot Graphics2D példánnyá. Majd beállítjuk a kívánt renderelési paramétereket, végül meghívjuk a drawString() metódust egy karakterlánccal.

Íme az elkészült szöveg/képernyőkép:

ASCII Art 3

A karakterek cserélgetésével a pozitív képből könnyen kaphatunk inverz/negatív képet is. A generált/renderelt képet fájlban is tárolhatjuk, például a javax.imageio.ImageIO osztállyal és adott a lehetőség a kép méretének megadására, a rajta megjelenő szöveg betűtípusának beállítására, háttérszín és szövegszín alkalmazására is.

A Java BufferedImage osztály néhány lehetőségének áttekintése után jó szórakozást kívánunk az ASCII képek létrehozásához, a lehetőségek további tanulmányozásához. Aki nem programból szeretne karakterekből/szövegekből felépülő képeket készíteni, használhat online alkalmazásokat is, például az Image to HTML/ASCII-t.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java SE szoftverfejlesztő tanfolyam szakmai moduljának 21-24. óra: Objektumorientált programozás, 2. rész alkalmához kötődik.