szimuláció - címke - Oldal 2 a 2-ből

Naprendszer szimuláció – elméleti háttér

2023. december 28.2023. január 8. Szerző: Friedel Attila

Naprendszer szimulációt terveztünk és valósítottunk meg Java nyelven, amit három részből álló blog bejegyzés sorozatban mutatunk be (ez az 1. rész):

Naprendszer szimuláció 1. rész – elméleti háttér
Naprendszer szimuláció 2. rész – objektumorientált tervezés
Naprendszer szimuláció 3. rész – megvalósítás Java nyelven

A Naprendszer szimuláció elméleti háttere

A Naprendszer szimulációhoz elengedhetetlen, hogy ismerjük a homogén koordinátákat, az elemi műveletek egységes megvalósításához szükséges transzformációs mátrixokat, a tömegvonzás elvét és az implementációhoz szükséges MVC modellt.

Homogén koordináták

Számítógépes algoritmusokkal egyszerű a térbeli transzformáció megvalósítása, ha homogén koordinátákat használunk. Segítségükkel az affin transzformációk egységesen kezelhetők. A cél egy egységes matematikai formalizmus alkalmazása. A pontok az égitestek középpontjait fogják jelölni. Legyen a P pont 3D-beli koordinátái: P=(x, y, z). Szükséges egy konstans érték. Ha w≠0, akkor a P pont koordinátái: P=(w·x, w·y, w·z, w). Ha w=1, akkor a P pont normalizált homogén koordinátái: P=(x, y, z, 1). A pontnégyes kijelölése kölcsönösen egyértelmű.

Transzformációk

Koordináta transzformáció során az ábrázolandó grafikus objektum pontjaihoz (tárgypontokhoz) új koordináta-rendszert rendelünk hozzá. Az objektum nem változik (nem torzul, nem változtatja meg az alakját), csupán a nézőpont változik meg. Például: a koordináta-rendszer eltolása, elforgatása, a koordinátatengelyek felcserélése, tükrözése, és a léptékváltás (nagyítás, kicsinyítés, összenyomás, széthúzás), elforgatjuk az ekliptika síkját a szimulált Naprendszerben.

Pont transzformáció esetén a tárgypontokhoz hozzárendeljük azok egy adott szempont szerinti hasonmását. Például: 3D-s tárgyak leképezése 2D-s képre, objektumok eltolása, forgatása, mozgatása, égitestek mozgatása tömegvonzás alapján. Affin transzformációk (egybevágósági és hasonlósági transzformációk) alkalmazása esetén pont képe pont, szakasz képe szakasz, felület képe felület, valamint metsző térelemek eredeti metszésvonala megegyezik azok leképezett metszésvonalával.

A számítógépes grafika területén az affin transzformációk általános alakja (mátrixosan):

A pont a B=(b_x, b_y, b_z) vektorral eltolható. A pont – a T=(t₁₁, t₁₂, …, t₃₃) mátrixot használva – adott szöggel elforgatható, skálázható, tükrözhető. A számítógépes grafikában ezt a transzformációs mátrixot a homogén koordinátákkal alkalmazva, az összes geometriai transzformáció hatékonyan megvalósítható, visszavezethető mátrixok szorzására. Mindezt saját magunk is implementálhatjuk, de része a DirectX és OpenGL rendering pipeline-jának is.

Más módon is lehetne: egyenes és ehhez tartozó szög párossal is dolgozhatnánk.

A tömegvonzás elve

A tömegvonzás bármely két égitest között meghatározott, függ a gravitációs állandótól és az égitestek tömegétől egyenes arányban, az égitestek (tömeg)középpontjainak távolságától fordított arányban. Ez a Newton szerinti értelmezés, amelynek képlete:

A hatás-ellenhatás törvénye miatt a vonzás – egymás felé való gyorsulás – kölcsönös, a gyorsulás az égitestek tömegével fordítottan arányos, sosem nulla. A Naprendszerben a bolygók a Nap körül keringenek, és a bolygóknak lehetnek holdjaik. Egységesen kezelve: égitestek.

A tömegvonzásnak más elméleti megközelítései is vannak: Einstein gödör-modellje, Kepler törvényei, illetve differenciál-egyenletrendszer, integrálszámítás is használható a közelítő képlet helyett (csak ideális modell esetén pontszerű az égitest és gömbszimmetrikus azok tömegeloszlása), illetve ismeretes többféle értelmezés a rendszer/modell stabilitására: Lagrange pontok, Lyapunov stabilitás.

Az MVC modell

A klasszikus megközelítés szerint a szoftveres alkalmazások három, egymástól jól elkülöníthető szereppel rendelkező egységből állnak: modell (model), nézet (view), vezérlő (controller). A Java nyelv Swing komponensei az MVC architektúra szerint működnek.

A vezérlő reagál az érkező eseményre, hozzáfér a modell adatszerkezeteihez, azaz igénybe veszi a modell szolgáltatásait, valamint frissítheti a nézetet. A nézet a vezérlő frissítési kérésére a közvetlenül megkapott adatok alapján, vagy a modelltől elkért adatok alapján frissíti saját magát. A vezérlő határozza meg az alkalmazás, komponens, program működését. Egy modellt több nézet is használhat. A modell közvetlenül is üzenheti a nézetnek, hogy megváltozott. A nézet adja a látványt, amelyet angolul skin vagy „look and feel”-nek neveznek.

Letöltés szimuláció

2023. július 26.2022. június 15. Szerző: Kaczur Sándor

Letöltési folyamatot szimulálunk. A paraméterek rugalmasan beállíthatóak. Előre beállított mennyiségű adatot, párhuzamos szálakon/folyamatokon keresztül töltünk le, miközben mérjük az eltelt időt. A folyamatok állapota lehet inaktív, aktív és befejezett. Az aktív folyamatok esetében megjelenő százalék fejezi ki, hogy a folyamat hol tart a rá jutó részfeladat végrehajtásával. Összesített formában követhetjük a hiányzó és a letöltött adat mennyiségét MB-onként és százalékosan is. A folyamat szimulációjához grafikus felületű Java kliensprogram készült, egyszerű GUI komponensekkel (nyomógomb, címke, folyamatindikátor, másképpen JButton, JLabel, JProgressBar swing komponensek).

Az alábbi animáció bemutatja a letöltés szimulációját:

A konkrét paraméterek: 128 MB-nyi adatot töltünk le 256 párhuzamos szálon/folyamaton keresztül, így egy-egy részfeladat 0,5 MB-nyi adat letöltését jelenti. Minden értéket/mérőszámot egész számként ábrázolunk, akár százalékhoz tartozik, akár mértékegységként MB vagy s. A változások – és egyben a frissítés is – 5 ezredmásodpercként történnek a GUI-n.

A Java SE szoftverfejlesztő tanfolyamunkon, a szakmai modul Objektumorientált programozás témakörét követő 29-36. óra Grafikus felhasználói felület alkalmain már tudunk egyszerűbb szimulációs programot tervezni, kódolni, tesztelni. A Java EE szoftverfejlesztő tanfolyamunkon, a szakmai modul 5-8. óra Szálkezelés, párhuzamosság alkalommal többféle elosztott stratégiát ismertetünk, és a 17-24. óra Socket és RMI alapú kommunikáció alkalommal pedig megvalósíthatjuk többféle protokoll szerint a hálózati kapcsolatot, letöltést/feltöltést.

Elosztott alkalmazások esetén többféleképpen is modellezhető és kialakítható a rendszer architektúrája. Elosztott lehet maga a hálózat, a számítási folyamat, az algoritmus. Elosztott objektumok kommunikálhatnak egyenrangúnak tekinthető P2P szerepkörben vagy szerver/kliens oldalon, és több dolog/elem/hardver/szoftver/komponens együttműködéseként is megvalósulhat elosztott alkalmazás. A hálózati kommunikáció folyamatát valamilyen protokoll határozza meg, amit minden komponens ismer és így meghatározott szabályrendszer szerint működik.

Hardver szinten elosztottak a többprocesszoros rendszerek. Szoftveresen elosztott például egy moduláris vállalatirányítási rendszer, illetve a mobilalkalmazások többsége. Tipikus háromrétegű webalkalmazás esetén külön szerver nyújtja az adatbázishoz kapcsolódó szolgáltatásokat, a felhasználó számítógépén található a böngészőben futó/megjelenő kliensprogram/weboldal és a kettő között a felhő rétegben lehet a funkcionálisan elosztott alkalmazáslogika (például validálás, titkosítás, tömörítés, autentikáció, autorizáció).

A vezérlést megvalósító részlet a Java forráskódból:

private void processControl() {

if(processList.isEmpty()) {

timer.stop();

return;

}

int index=(int)(Math.random()*processList.size());

int oldValue=processList.get(index).getValue();

int increase=(int)(Math.random()*3+1)*10; //5, 10, 15

increase=oldValue+increase<=MAX ? increase : MAX-oldValue;

downloadedSumPercent+=increase;

int newValue=oldValue+increase;

processList.get(index).setValue(newValue);

if(newValue==MAX)

processList.remove(index);

int openProcessCount=0, inactiveProcessCount=0;

for (JProgressBar pb : processList) {

int v=pb.getValue();

if(v==MIN)

inactiveProcessCount++;

if(MIN<v && v<MAX)

openProcessCount++;

}

lbInactiveProcessCount.setText(""+inactiveProcessCount);

lbOpenProcessCount.setText(""+openProcessCount);

lbClosedProcessCount.setText(""+

(PROCESS_COUNT-(openProcessCount+inactiveProcessCount)));

int downloadedData=

(int)((double)downloadedSumPercent/(PROCESS_COUNT*MAX)*DATA);

lbMissingData.setText(""+(DATA-downloadedData));

lbDownloadedData.setText(""+downloadedData);

pbProcess.setValue((int)((double)downloadedData/DATA*100));

elapsedTime+=5;

if(elapsedTime%1000==0)

lbElapsedTime.setText(""+elapsedTime/1000);

}

A szimuláció elvi szinten:

a folyamatok generikus listában vannak,
időzítő által meghatározottan, gyorsan és ismétlődve történnek az időzített lépések,
ha egy folyamat befejeződik, akkor kikerül a generikus listából,
ha a folyamatok generikus listája kiürült, akkor vége a szimulációnak,
ki kell választani véletlenszerűen egy folyamatot, léptetni kell véletlenszerűen, amíg be nem fejeződik,
folyamatosan nyilván kell tartani a szükséges adatokat a háttérben,
folyamatosan frissíteni kell a felhasználói felületet.

Haladóbb megközelítésben másképp is lehetne: a számítási műveletek redukálhatóak lennének, ha lenne egy – minden olyan adat karbantartásáért felelős – modellobjektum, amelynek adatai hozzá lennének rendelve a GUI komponensekhez. Aki már sejti, annak megerősítem, hogy igen, ez observer (megfigyelő) tervezési minta.

A feladat könnyen általánosítható, például:

Egy keresési feladatot oldjunk meg az állományrendszerben! Kereshetünk egy konkrét nevű fájlt, adott kiterjesztésű fájlt, joker karakterekkel paraméterezett nevű fájlt/mappát, adott méretű állományt, adott dátum előtt létrehozott fájlt… Az állományrendszer bejárása rekurzív módon történik. A gyökérben lévő mappánként külön, esetleg második szinten lévő mappánként külön indíthatók szálak, párhuzamos folyamatok. Ha egyetlen találat elegendő, akkor bármelyik szál pozitív visszajelzésére minden szál leállítható. A feladatnál nagy eséllyel nagyon különböző méretű mappákon és eltérő mélységű mappaszerkezeteken kell végighaladni, így erre érdemes lehet optimalizálni, de ez már nagyon más szintje ennek a problémának.
Active Directory szerkezetben keressünk elérhető nyomtatókat a hálózaton!
Elosztott számítási hálózatként működik/működött a SETI@home. Koncepciójának lényege, hogy egy hatalmas feladatot nem nagyon drága szuperszámítógépeken, hanem olcsó gépek ezrein, százezrein, vagy akár millióin végeztetjük el, amelyek jelentős szabad kapacitással (pl. processzoridővel, átmeneti tárhellyel) rendelkeznek és egyébként is csatlakoznak a világhálóra.
Hasonlóan elosztott működésű a torrent protokoll. A kliensek/szálak az állományokat több kisebb darabban/szeletben töltik le, természetesen párhuzamosítva. Minden csomópont megkeresi a hiányzó részhez a lehető leggyorsabb kapcsolatot, miközben saját maga is letöltésre kínálja fel a már letöltött fájldarabokat. A módszer nagyon jól beválik nagyméretű fájloknál, például videók esetében. Minél népszerűbb/keresettebb egy fájl, annál többen vesznek részt az elosztásában, ezáltal a letöltési folyamat gyorsabb, mintha mindenki egy központi szerverről töltené le ugyanazt (hiszen az informatikában minden korlátos, a sávszélesség is).
A képtömörítést végző algoritmusok is lehetnek elosztottak, ezáltal párhuzamosíthatóak. Például ha felosztjuk a képet 16*16-os méretű egymást nem átfedő részekre, akkor ezek egymástól függetlenül tömöríthetők.
A merevlemezek esetén korábban használatos defragmentáló szoftverek felhasználói felülete emlékeztet a mintafeladat ablakára.

Fontos szem előtt tartani, hogy a grafikus megjelenítés csupán a szimulációhoz tartozó – annak megértéséhez szükséges – reprezentáció, így teljesen független lehet a folyamatok valós működésétől.

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

Skandináv lottó demóprogram

2023. augusztus 4.2021. augusztus 17. Szerző: Kaczur Sándor

Skandináv lottó (heteslottó) demóprogramot tervezünk és írunk meg Java nyelven. Lépésenként mutatja meg, hogy mi történik a háttérben: hogyan állítja elő véletlenszerűen a lottószelvényt.

Az emlékezet egy logikai tömb. Ebben 36 elem van. A nulladik elem nem számít, és legyen a többi elem (1-35-ig indexelve) kezdetben mind hamis. A cél: legyen a tömbben pontosan 7 db igaz érték. Másképpen: a logikai tömb a lottószelvényen megjátszható számok kiválasztottságát jelöli, igen vagy nem. A heteslottó-szelvény 7 db 1 és 35 közötti különböző egész számból áll.

Mindig 1 és 35 közötti egész véletlenszámot tippelünk. Kezdetben jóSzámDb=0. Az első tipp biztosan jó és jóSzámDb=1. A többi tipp esetén vizsgálni kell, hogy már kiválasztott-e. Ha igen, akkor nincs teendőnk. Ha nem, akkor meg kell jegyezni (kiválasztottá kell tenni, azaz igazzá kell állítani a logikai tömbben) és a jóSzámDb++ (növelhető). Mindezt ciklusban ismételjük, amíg a jóSzámDb<7 feltétel teljesül (másképpen: amíg nincs elegendő kiválasztott szám a szelvényen). Mindez biztosítja az egyediséget, különbözőséget. Ha jóSzámDb==7, akkor kiírjuk a lottószelvényre kerülő számokat az alapján, hol (melyik indexen) van a logikai tömbben igaz érték.

Tekintsük át az alkalmazott módszer hátrányait és előnyeit. Hátrány, hogy 36 logikai érték szükséges ahhoz, hogy 7 különböző számot előállítsunk. Előny, hogy egyszerű az algoritmus (nem kell keresés és megszámolás programozási tétel) és nincs szükség rendezésre sem, mert a szakterületre jellemző „emelkedő számsorrend” a logikai tömb bejárásával önkéntelenül is adódik. Hangsúlyozzuk, hogy ez csupán egyetlen módszer a nagyon sok izgalmas közül, amikkel generálható egy véletlenszerű lottószelvény.

A megvalósítás, Java forráskód egyszerű. Íme egy függvény, amely visszaadja azt kiválasztottságot jelölő logikai tömböt, amiből megfelelően indexelve kiíratható a véletlenszerűen generált lottószelvény:

private static Boolean[] heteslottoSzelveny() {

Boolean[] logikaiTomb=Stream.generate(()->Boolean.FALSE).

limit(1+35).toArray(Boolean[]::new);

int joSzamDb=0;

while(joSzamDb<7) {

int tipp=(int)(Math.random()*35+1);

if(!logikaiTomb[tipp]) {

logikaiTomb[tipp]=true;

joSzamDb++;

}

return logikaiTomb;

}

Egy demóprogram, szimulációs program, oktatóprogram esetén nem is a konkrét feladat megoldása a cél/probléma. Sokkal inkább a lépésenkénti bemutatás, sok-sok konzolos kiírással vagy grafikus szemléltetéssel. Sokszor időzítővel késleltetjük, lassítjuk, gyorsítjuk a folyamatot, de előfordul az is, hogy rengetegszer megismételjük a tevékenységet és a kapott adatokat elemezzük, következtetünk belőlük. Most például a ciklust ki kell cserélni olyan léptetésre, ami a felhasználó kattintásához kötődik. Ha kéri a következő tippet a lottószelvényre, akkor megkapja. Ha nem kattint, akkor nem kapja meg. Az is egy csalás/lehetőség lenne, hogy a háttérben nem is logikai tömb adatszerkezet van, csupán a vizualizáció miatt tűnik annak.

Az elkészült demóprogram megvalósítja a fenti algoritmust. Az alábbi képernyőképeken végiglapozható a demóprogram működése. Nem is az algoritmus megvalósítása a kihívás és a cél, hanem a folyamat lépésenkénti megjelenítése. Java swing grafikus felület készült el.

A demóprogram Start állapottal indul. Olyan a lépésenként tesztesetek sorozata, hogy a lottószelvény nem sikerül rögtön elsőre. Az egyik szám már előfordult korábban. A demóprogram Stop állapottal ér véget. A demóprogram pénztárszalagszerűen időnként jelzi, hol tart éppen. A demóprogram képes egymás után több lottószelvényt is előállítani és az emlékezete egyetlen szelvényre korlátozódik.

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 Java SE szoftverfejlesztő tanfolyamunkon, a szakmai modul Objektumorientált programozás témakörét követő 29-36. óra Grafikus felhasználói felület alkalmain már tudunk egyszerűbb szimulációs programot tervezni, kódolni, tesztelni. A Java EE szoftverfejlesztő tanfolyamunkon, a szakmai modul 33-40. óra Java Server Pages alkalmain már a program böngészőben futó változatát is el tudjuk készíteni.

Hóesés szimuláció

2023. augusztus 4.2019. december 18. Szerző: Balogh Péter

Hóesés szimulációt tervezünk és valósítunk meg Java nyelven. A téma igazi örökzöld. Elvileg minden télen aktuális. 😉 A grafikus felülethez és az eseménykezeléshez a swing gyűjteményt használjuk. Adott egy téglalap alakú terület amelyen – méretéhez igazodva – több száz hópehely mocorog. A területet önállóan programoztuk le – azaz ez alkotja a teljes GUI-t –, de lehetne egy nagyobb kép része is. Többféleképpen is beépítünk véletlenszerűséget a szimulációba. Tervezünk is, hiszen az sosem árt. 😉

Többnyire beépített komponenseket, elemeket használunk, de van saját, örökítéssel testre szabott komponensünk is:

A szimuláció a Window osztályból példányosított felületen működik, amely JFrame utód. Nem átméretezhető és látható.
A területet JPanel típusú pnTransparentWindow alkotja. Mérete 300*200 pixel. Színe a szürke egyik árnyalata. Ezen mozognak a hópelyhek.
A hópehely Snowflake típusú JPanel utód. Mérete 2*2 pixel. Színe fehér. Saját swing-es Timer biztosítja az eseménykezelését. A szimulációban 600 hópehely szerepel.

Az elkészült szimuláció

A teljes forráskódból íme a hópehely megvalósítása

public class Snowflake extends JPanel {

private Rectangle rectangle=null;

private Dimension size=new Dimension(2, 2);

private int delay=(int)(Math.random()*5+1)*50

private Timer timer=new Timer(delay, (ActionEvent e) -> {

move();

});

A hópehelynek „tudnia kell” hol van, azaz mekkora területen mozoghat, ez a rectangle. A hópehelynek van size mérete. A hópehely saját magát mozgatja a területen a timer segítségével. Az időzítés várakoztatására/késleltetésére vonatkozó delay értéke véletlenszerűen 50, 100, …, 250 milliszekundum lehet. Másképpen: a szél által össze-vissza fújt hópelyhek között lehetnek lassabban és gyorsabban mozgók is. Az eseményobjektumhoz lambda kifejezés rendeli hozzá a reakciót jelentő, mozgást megvalósító move() metódus meghívását, amely így adott időközönként bekövetkezik.

public Snowflake(JPanel pnTransparentWindow) {

rectangle=pnTransparentWindow.getBounds();

setPreferredSize(size);

int x=(int)(Math.random()*rectangle.width);

int y=(int)(Math.random()*rectangle.height);

setBounds(x, y, size.width, size.height);

setOpaque(true);

setBackground(Color.WHITE);

timer.start();

}

A hópelyhet a konstruktora hozza létre. Átveszi azt a pnTransparentWindow területet, amelyre később rákerül a Window példányosítása során. A gyengébb setSize() metódus helyett az erősebb setPreferredSize() metódus állítja be a méretet. Véletlenszerű x és y pozícióba kerül ki/fel a területre. A setBounds() örökölt metódus beállítja a pozícióját és méretét. Erre épít a fogadó oldalon az abszolút helyzet, külön elrendezésmenedzser nélkül. Végül a hópehely átlátszó, fehér és elindítja saját időzítőjét a timer.start() metódushívással.

Az időzítés/várakoztatás véletlenszerűsége után íme a második véletlenszerűség a szimulációban. A hópehely mozgása során a szél által össze-vissza fújva eltérő eséllyel/valószínűséggel mozog 8 lehetséges irányba az alábbiak szerint:

5-5% eséllyel felfelé, azon belül jobbra vagy balra (átlósan),
10-10% eséllyel jobbra vagy balra,
20-20% eséllyel lefelé, azon belül jobbra vagy balra (átlósan),
30% eséllyel lefelé, függőlegesen,
felfelé, függőlegesen nem mozog.

Az esélyek összege 100%. Másképpen kulcsszavakban: 1 = biztos esemény (teljes eseménytér, nincs más lehetőség), egymást kizáró események, geometriai valószínűség. A képen középen lévő hópehely a 8 szomszédja közül a 7 szóba jöhető közül valamelyikre adott eséllyel mozog. A geometriai valószínűséget az ábra alapján az óramutató járásával megegyezően leképeztük az 1..100 intervallumra:

public void move() {

Point location=getLocation();

int tip=(int)(Math.random()*100+1); //1-100

if(1<=tip && tip<=5)

location.translate(size.width, -size.height); //jobbra fel

else if(6<=tip && tip<=15)

location.translate(size.width, 0); //jobbra

else if(16<=tip && tip<=35)

location.translate(size.width, size.height); //jobbra le

else if(36<=tip && tip<=65)

location.translate(0, size.height); //le

else if(66<=tip && tip<=85)

location.translate(-size.width, size.height); //balra le

else if(86<=tip && tip<=95)

location.translate(-size.width, 0); //balra

else //96<=tip && tip<=100

location.translate(-size.width, -size.height); //balra fel

if(rectangle.height<location.y)

location.translate(0, -(int)location.getY());

setLocation(location);

}

A move() metódus megvalósítja a fenti tervnek megfelelően a hópehely mozgatását. Első lépésben tudni kell a jelenlegi/kiinduló location helyét (a bal felső csúcs, elkérjük). Ezután véletlenszerű esély/ tip generálódik. Az első elágazásban a hópehely translate() metódusával eltoljuk az előbb elkért pontot. Az eltolás relatív. Az utolsó elágazásban kompenzálunk, ha a hópehely alul kilépne a területről. Ekkor felül újra belép a területre. Végül beállítjuk a hópelyhet megvalósító komponenst a manipulált location helyre.

Takarékosak vagyunk: ezzel a megoldással „újrahasznosítjuk” a hópelyheket. Csak annyi van belőlük, amennyi szükséges. Nem kell őket folyamatosan megszüntetni és újra létrehozni. Nem mozognak feleslegesen. Nem mozognak olyan területen, ahol nem láthatóak.

Ötletek továbbfejlesztésre

A hópelyhek színe lehetne véletlenszerű a fehér és a középszürke között. Ezzel a nézőtől való távolságot, esetleg a kép élességét lehetne modellezni.
A szél nem feltétlenül szimmetrikus, vagy a hópelyhek mozgatását meg lehetne oldani jobbra és balra eltérő eséllyel is.
A terület lehetne más alakú, például trapéz, íves, kör, ellipszis.
Másképpen is vezérelhetnénk a szimulációt. Ahelyett, hogy most minden hópehelynek van saját időzítője, lehetne csak 5 db (lassabbak és gyorsabbak), amelyek közül véletlenszerűen kiválaszthatnánk, hogy melyik hatására mozgatjuk az adott hópelyhet. Fordítva is mehetne: az 5 db időzítőhöz előre hozzárendelhetnénk a hópelyheket. Ez így más-más felelősség, kommunikáció, üzenetküldés, vezérlés lenne az objektumok között. Hasznos tapasztalat lehet megvalósítani bármelyiket.
A terület lehetne egy nagyobb kép része. Például meghatározhatnánk egy tetszőleges átlátszóságot (színt vagy arányt) és többrétegű felületet megvalósítani képes JLayeredPane komponens elé vagy mögé is elhelyezhető lehetne a terület a grafikus felületen.
Aki kihívást keres: illessze a területet az alábbi hangulatos képre úgy, hogy a középső ablakok téglalap alakúak, a két szélső trapéz alakú vagy perspektivikus nézetű és a kör/ellipszis alakú tükörben pedig tükröződik valahonnan a hóesés látványa.
Még bátrabbaknak: a kandallóban lévő tüzet is lehet hasonlóan szimulálni. Itt már többféle fizikai paraméter is figyelembe vehető, például fényerősség, tükröződés. Egy 3D modellezett térben a sugárkövetés (Ray Tracing) algoritmus is megvalósítható. A hópelyheknél lehetne az egyszerű mozgástól eltérő más fizikát is programozni: rugalmas ütközéssel összetapadhatnának vagy rugalmatlan ütközéssel lepattanhatnának egymásról és mindez hathatna a sebességükre is.

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

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

2023. augusztus 4.2017. május 11. Szerző: Kaczur Sándor

A 2017-es középszintű matematika érettségi feladatsor 12. feladata inspirált egy Java program megírására. Szükséges hozzá néhány programozási tétel: sorozatszámítás, megszámolás, valamint adatszerkezetként ideális egy kétdimenziós tömb. É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.

12. feladat

Egy kockával kétszer egymás után dobunk. Adja meg annak a valószínűségét, hogy a két dobott szám összege 7 lesz! Válaszát indokolja!

Matematikai megoldás

A feladat nagyon egyszerű. Két megoldást ismertet a javítási-értékelési útmutató:

Összesen 6 * 6 = 36-féleképpen dobhatunk. Hat olyan dobáspár van, amelyben 7 az összeg: (1; 6), (2; 5), (3; 4), (4; 3), (5; 2) és (6; 1). A keresett valószínűség 6/36-od, vagyis egyhatod.
Bármennyit is dobunk elsőre, ezt a második dobás egyféleképpen egészítheti ki 7-re. Így a második dobásnál a hat lehetséges értékből egy lesz számunkra kedvező. A keresett valószínűség egyhatod.

Közelítő megoldások szimulációval

Egy alkalom két kockadobást jelent egymás után. A dobások sorrendje nem számít (alkalmanként és összességében sem). Minél több alkalommal végezzük el a kockadobásokat, annál jobban megközelítjük a fenti valószínűséget (várható értéket, bővebben: nagy számok törvénye). Az egyhatod közelítő értéke a Java double adattípusával 0.16666666666666666.

1. megoldás

Ha nem akarunk emlékezni a dobásokra, összegükre, csupán megszámolnánk, hogy hány olyan dobáspár van, amelyben 7 az összeg, akkor ehhez mindössze egy számláló ciklus kell, aminek a ciklusmagjában két véletlen kockadobás összegét előállítjuk és növelünk egy számlálót/gyűjtőt, ha az éppen 7. Az eredményt a számláló és a ciklus lépésszámának hányadosa adja meg. Például meghívhatjuk a metódust így: kockadobas1(5000); és kaphatjuk eredményül ezt: 5000 alkalomból 7 összegként 836 alkalommal fordult elő. Valószínűség: 0.1672 . A metódus kivételt dob, ha értelmetlen a paramétere. Íme a metódus Java forráskódja:

static void kockadobas1(int alkalomDb) {

if(alkalomDb<=0)

throw new IllegalArgumentException("Hiba: alkalomDb<=0");

int osszeg7db=0;

for(int i=1; i<=alkalomDb; i++) {

int dobas1=(int)(Math.random()*6+1);

int dobas2=(int)(Math.random()*6+1);

if(dobas1+dobas2==7)

osszeg7db++;

}

System.out.println(

alkalomDb+" alkalomból 7 összegként "+

osszeg7db+" alkalommal fordult elő. Valószínűség: "+

((double)osszeg7db/alkalomDb));

}

2. megoldás

Ha egy 13 elemű egész típusú tömböt használhatunk emlékezetként. Kezdetben 2-től 12-ig indexelve nullázzuk ki, így csoportos gyűjtést tudunk megvalósítani. A nullázás most inicializáló blokkal történt, mert nem sok eleme van a tömbnek (sok elemnél inkább használjunk erre ciklust). A tömb első két elemét nem használjuk semmire. Mi történik a ciklusban? Például dobas1=3 és dobas2=4 esetén a dobasDbTomb[7] elemét növeli (mindegy mi volt ott korábban, de inkrementálódjon). Most több adatot tárolunk, mint amiből megválaszolható a feladatban megfogalmazott konkrét kérdés, de ezt tekinthetjük strukturális tartaléknak.

static void kockadobas2(int alkalomDb) {

if(alkalomDb<=0)

throw new IllegalArgumentException("Hiba: alkalomDb<=0");

int[] dobasDbTomb={-1, -1,

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

for(int i=1; i<=alkalomDb; i++) {

int dobas1=(int)(Math.random()*6+1);

int dobas2=(int)(Math.random()*6+1);

dobasDbTomb[dobas1+dobas2]++;

}

System.out.println(

alkalomDb+" alkalomból 7 összegként "+

dobasDbTomb[7]+" alkalommal fordult elő. Valószínűség: "+

((double)dobasDbTomb[7]/alkalomDb));

}

Hasonló, egydimenziós tömbbel történő belső adattárolást megvalósító elosztott alkalmazásról blogoltunk már: Kockadobás kliens-szerver alkalmazás.

3. megoldás

Ez az igazi szimuláció, swing GUI grafikus környezetben, ahogyan az alábbi képernyőképen látható. A megvalósítás kétdimenziós tömböt használ adatszerkezetként. Álljon 7 sorból és 7 oszlopból és legyen i a sor- és j az oszlopindex. A tömb [0][0]-dik elemét nem használjuk semmire. Az első oszlopába ( j=0 és i>0) bekerülhetnek a dobókockán előforduló számok 1-től 6-ig. Hasonlóan az első sorba ( i=0 és j>0) is. Ezek a dobott számok alapján indexek lesznek és az ábrán zöld hátterű cellákba kerültek. A tömb többi eleme kezdetben 0 (nulla), ezek az ábrán fehér hátterű cellák. A szürke hátterű cellák (mellékátló) esetén a dobott számok összege 7 és jól látszik, hogy ez hatféleképpen fordulhat elő a 36-féle eset közül. Például a 2. sor 5. oszlopában lévő szám mutatja, hogy a 10000 alkalomból 274-szer fordult elő az, hogy a dobáspár a (2; 5) lett. A tömb két indexe felcserélhető lenne, mert ez a mellékátlóban lévő számok összegét nem befolyásolja.

A programban kiválasztható néhány alkalomból amit szeretnénk, és a Dob nyomógombra kattintva indul el időzítővel a folyamat. Várakoztatás/menet közben piros színnel kiemelve látszik/megfigyelhető, hogy az éppen aktuális dobás hol növeli az értéket/előfordulást/darabszámot. A képernyőképen befejeződött állapot látható. Az eredményt a szürke cellákban lévő számok összegének és az alkalmak számának hányadosa adja meg. Ezt a háttérbeli kétdimenziós tömbben összesítéssel az alábbi Java forráskód-részlet adja meg:

int osszeg7db=0;

for (int i = 1; i <= 6; i++)

osszeg7db+=dobasTomb[i][7-i];

String eredmeny=alkalomDb+" alkalomból 7 összegként "+

osszeg7db+" alkalommal fordult elő.";

Most lényegesen több adatot tárolunk, mint ami a konkrét válaszhoz kell, de cserébe jól érzékeltethető a csoportos gyűjtés/megszámolás működése. A program grafikus felhasználói felületének felépítését és az eseménykezelés megvalósítását most nem részletezzük.

Eszünkbe juthatna, hogy a program miért dob kétszer 1 és 6 közötti számot egymás után és ezt összegzi, amikor egyetlen 2 és 12 közötti dobással (véletlenszám generálással) megkaphatnánk a dobáspár összegét. Hiszen két db 1 és 6 közötti szám összege mindig 2 és 12 közötti szám. Jó lenne ez az ötlet/megvalósítás? Igen? Nem? Miért? A hozzászólásokhoz várjuk az indoklást.

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

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 17-28. óra: Objektumorientált programozás alkalmaira épülő 29-36. óra: Grafikus felhasználói felület alkalmaihoz kötődik.