Születésnap-paradoxon

Mennyi a valószínűsége, hogy n ember között van kettő, akiknek egy napon van a születésnapja? A meglepő a dologban az, hogy már 23 ember esetén a kérdéses valószínűség 1/2-nél nagyobb. Másképpen: már 23 ember esetén nagyobb annak az esélye, hogy megegyezik a születésnapjuk, mint az ellenkezőjének. Ez a 23 nagyon kevésnek tűnik. Ezért paradoxon.

Közismert néhány hétköznapi valószínűség. Íme néhány szabályos eset. A pénzfeldobás során 1/2 az esélye a fej és 1/2 az esélye az írás eredménynek (másképpen 50%-50%, azaz fifty-fifty). A kockadobás esetén 1/6 az esélye bármelyik számnak 1-től 6-ig. Két kocka esetén blogoltam már a dobott számok összegének alakulásáról, eloszlásáról: Kockadobás kliens-szerver alkalmazás.

Néhány egyszerűsítés

  • Az év 365 napból áll. Nem számítanak a 366 napos szökőévek.
  • A születések eloszlása egyenletes, azaz minden nap körülbelül ugyanannyian születnek. Nem számít, hogy hétköznap, hétvége, ünnepnap. Az áramszüneti városi legendák sem.
  • Nem vesszük figyelembe az azonos napon született ikreket. Persze ikrek születhetnek különböző napokon is.

Azonos születésnap valószínűsége grafikonon

Lássuk, hogyan alakul az azonos születésnap valószínűsége az emberek számától függően! Grafikonon ábrázolva:

A fenti grafikonhoz szükséges adatok könnyen előállíthatók az alábbi Java forráskóddal:

A fenti Google Chart típusú szórásgrafikon (Scatter Chart, korrelációs diagram) megjelenítéséhez adatpárok sorozata szükséges. Ezek a konkrétumok (70 db adatpár), görgethető:

Hasonló grafikon készítéséről szintén blogoltam már: Céline Dion – Courage World Tour.

Párok előállítása

Az emberek születésnapjainak összehasonlítása párokban történik. 23 ember esetén 23*22/2=253 pár van. Általános esetben n ember esetén (n*(n-1))/2 pár adódik. A levezetés részletei a források között megtalálható. 59 ember esetén 1711 pár adódik és szinte garantált az előforduló azonos születésnap, hiszen már 0,99 ennek a valószínűsége.

Az alábbi Java forráskód – rekurzív módon – előállítja a 23 konkrét esetre a párokat, az embereket 1-23-ig sorszámozva. Kombinációk:

A main() metódusban az i változó paraméterezhető és a konkrét eset könnyen intervallumra változtatható. Eredményül ezt írja ki a program a konzolra, görgethető:

Kísérleti ellenőrzés

Tekintsünk például 1000 esetet! Készítsünk Java programot, amely 23 db véletlen születésnapot generál! Legyen ez a születésnap sorszáma az évben (másképpen hányadik napon született az ember az évben). Ez lényegesen egyszerűsíti a megoldást, összevetve a dátumkezelésen alapuló megközelítéssel. Ajánljuk a szakmai blog dátumkezelés címkéjét az érdeklődőknek, ahol megtalálhatók a témához kapcsolódó Java forráskódrészletek részletes magyarázatokkal kiegészítve. Íme a többféle generikus listát és programozási tételt használó forráskód:

Érdemes elemezni, tesztelni a fenti forráskódot: milyen lépésekben, milyen adatszerkezeteket épít. Hasznos lehet lambda kifejezésekkel kiegészíteni, módosítani a programot. Részlet a program szöveges eredményéből:

A 12. sorban lévő számhármasok jelentése: esetszám 1-től, azonos nap, előfordulás száma. Például: a kísérlet során a 8. esetben az év 225. napja azonos 3 embernél. Természetesen nincs garancia arra, hogy az 1000 eset vizsgálatánál mindig 500-nál nagyobb kedvező esetet kapunk.

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 alkalmaihoz kötődik.

Források

Beszámoló: it-tanfolyam.hu STEM nyári tábor 2023

A STEM mozaikszó eléggé közismert: a tudományos-technológiai tudományágakat (természettudomány, technológia, mérnöki tudomány és matematika) foglalja egybe, interdiszciplináris megközelítésben. A STEM területén való elmélyedés során a hangsúly nem a mit tanulunk/tanítunk, hanem inkább a hogyan tanulunk/tanítunk. Nem azonnal ad kézzel fogható válaszokat, de kitartó próbálkozással – saját élménnyel – elérhető az eredmény.

Az it-tanfolyam.hu oktatói csapata 2023-ban először hirdetett STEM nyári tábort. Erről számolunk be röviden ebben a blog bejegyzésben. Tervezzük, hogy a jövőben rendszeresen fogunk szervezni STEM nyári tábort.

A STEM nyári tábor koncepciója

2023. nyarán 4 turnusban hirdettünk programozás fókuszú STEM nyári tábort:

  • 1. turnus: július 3-7-ig,
  • 2. turnus: július 10-14-ig,
  • 3. turnus: július 17-21-ig,
  • 4. turnus: július 24-28-ig.

Előzetes tudás- és igényfelmérést végeztünk, így alakítottunk ki 3 db csoportot, ezek: Java kezdő, Python kezdő, Python haladó. A kiinduló célcsoportot tanfolyamaink karrierváltó hallgatóinak gyermekei jelentették, akik mellé toboroztunk még. A korosztály a 16-20 éves diákok voltak a 11-14. évfolyamról. A 11-12. évfolyamosok közül sokan informatika, digitális kultúra érettségi előkészítő fakultációra jelentkeztek, jártak, járnak és ebből érettségiznek/érettségiztek. A már korábban érettségizett 13-14. évfolyamosok körülbelül fele az OKJ utód szakmajegyzékhez tartozó szakképzésben tanult.

Mindegyik turnus azonos tematikával valósult meg. Turnusonként 3 db párhuzamos, 10-12 fős csoportokat indítottunk. Voltak közös elméleti programok, szakmai kirándulás, illetve külön-külön Java és Python nyelven megvalósuló gyakorlati programok, valamint projektbemutatóra is sor került. Igyekeztünk érinteni sokféle STEM területet: fizika, kémia, biológia, csillagászat, térinformatika, mesterséges intelligencia, szimuláció, játékprogramok, matematika, orvostudomány; mindegyiket a programozáshoz kapcsolva. Végeztünk tervezést, kódolást, tesztelést is. Belefért némi pályaorientáció is.

A STEM nyári tábor órarendje

Turnusonként 4 oktató kollégával és vendégelőadókkal hétfőtől-péntekig minden nap 8 és 18 óra között biztosítottuk a jelenlétet, felügyeletet. 40 órában szakmai programokat (elmélet+gyakorlat) kínáltunk. Reggelenként és késő délutánonként 1-1 órában offline, egyéni vagy csoportos játékok voltak kipróbálhatók. Ez mindösszesen 50 órát jelentett. Délelőttönként 20, 30 és 60 perces programokat terveztünk, délutánonként 120 és 240 perceseket. Szerdára szakmai kirándulást, gyárlátogatást ütemeztünk be. Íme az órarend áttekintő formában:

Íme az órarend naponként lapozható formában, benne a részletekkel:

Előzetes tapasztalataink

Előzetes tapasztalatainkat több forrásból merítettük, inspirálódtunk:

Köszönetnyilvánítás

Köszönjük résztvevő diákjainknak az aktivitást, a lelkesedést, a sok-sok elgondolkodtató kérdést, az offline kapott/szerzett élményeket, a pozitív visszajelzéseket.

Szeretnék köszönetet mondani együttműködő partnereinknek: LEGO Manufacturing Kft., REGIO Játékkereskedelmi Kft., Revolt Kereskedelmi Kft., Pannon Kincstár Humán Szakképző Központ.

Végül szeretnék köszönetet mondani minden oktató kollégámnak konstruktív részvételüként, kitartásukért a projekt teljes életciklusában. A tervezési, a szponzorszerző, a promóciós és a megvalósítási szakaszokban egyaránt 2023. április elejétől július végéig. Kiemelem korábbi és az aktuális projekthez kötődő tananyagfejlesztési tevékenységüket. A sikeresen lezárt projektünket augusztusban kipihenjük. 😉

Alkalmazottak életpálya modellje – mi lenne, ha…?

Kiss Balázs kolléga Alkalmazottak életpálya modellje – munkakör, fizetés jutalék blog bejegyzése inspirálta ezt a blog bejegyzést. Az Oracle HR sémában az értékesítési vezetők adható havi fizetése 10000 és 20000 között van, átlagfizetésük 12200. Az üzletkötők paraméterei hasonlóan: 6000, 12000, 8350. A pénznem USD. Mi lenne, ha…? Ha többféleképpen is kalkulálhatnánk jutalékokat fizetési modellek alapján. Vajon hogyan lehetne választani? Következzen kétféle fizetési modell az alkalmazottak jutalékaihoz kötődően.

Alkossunk egy fizetési modellt! Hogyan kalkuláljuk a jutalékokat?

A jutalék negyedévente kerül kifizetésre és a havi fizetés megadott százaléka. Például: Elizabeth Bates üzletkötő havi fizetése 7300, jutaléka 15%, azaz minden 3. hónapban a fizetése 8395 helyett 10585. A negyedévek első két hónapjában a cég bérköltsége 691400, az utolsó hónapjában pedig 765090. Mindez arra a 106 fő alkalmazottra vonatkozik, akik részleghez tartoznak. Nincs benne az az 1 fő, aki nincs részleghez rendelve.

Összesített megoldás

A lekérdező SQL parancs:

Eredményül ezt az eredménytáblát adja:

Részlegekre összesített 1. megoldás

Vegyük figyelembe azt a 106 fő alkalmazottat, akik részleghez tartoznak (a 107 fő közül). Az alábbi lekérdező SQL parancsot futtatva:

Az eredménytábla 11 rekordból áll. A százalékok a részlegre jutó bérköltség arányát fejezik ki (tényleges fizetésre és jutalékos fizetésre vonatkoztatva).

Részlegekre összesített 2. megoldás

Balázs írta, hogy a Sales részlegben 35-en dolgoznak. Ez akkor helytálló, ha a munkakörök alapján kérdezzük le és láttuk, hogy a 35 főből értékesítési vezetőként 5 fő, üzletkötőként 30 fő dolgozik. Igen ám, de van egy olyan alkalmazott, aki nem tartozik egy részleghez sem ( DEPARTMENT_ID IS NULL), ezért kapjuk az előző eredménytábla szerint a Sales részlegben a 34 főt. Ugyanis az azt előállító lekérdező parancs a  DEPARTMENT_ID részlegazonosító alapján kapcsolja össze a két táblát ( EMPLOYEES és DEPARTMENTS). Ha az ő fizetését is figyelembe kell venni, akkor ez lehetséges az alábbi lekérdező paranccsal:

Az eredménytáblában az utolsó, 12. rekord tartalmazza az eddig hiányzó 1 fő alkalmazott adatait:

Az eredménytábla – az utolsó rekord kivételével – majdnem megegyezik az előzővel. A fizetési modell szerint a negyedévek első két hónapjában a cégre vonatkozó bérköltség 7000-rel növekszik és a negyedévek harmadik hónapjában pedig 8050-nel. A fizetések arányát százalékban egy tizedesjeggyel ábrázolva szinte nem vehető észre a különbség. A rekordok azonos sorrendjétől tekintsünk most el, hiszen a UNION és az ORDER BY alparancsok alkalmazása együtt külön történet. Aki érti, hogy mire gondolok, most biztosan kacsint egyet. 😉 Aki még nem érti, annak részletesen elmagyarázzuk Java adatbázis-kezelő tanfolyamunkon. Továbbá a százalékokat összesítve a kerekítésük miatt nem kapunk pontosan 100%-ot.

Az így kapott adatok kiegészítik a Top 5 fizetésű alkalmazottak listája blog bejegyzésben kapott adatokat. Ott nem szerepelnek az alkalmazottak részlegei, de természetesen könnyen összepárosíthatók. Másképpen: a 107 fő alkalmazottból 35 fő (32,7%) kapja a fizetések 45%-át jutalék nélkül, illetve 50,4%-t jutalékkal kalkulálva. Tehát érdemes/megéri a Sales részlegben dolgozni. Még akár jutalék nélkül is. 🙂

A bejegyzéshez tartozó teljes Java forráskódot (ami beépítve tartalmazza a fenti SQL lekérdező parancsokat) ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladatok a Java adatbázis-kezelő tanfolyam 13-16. óra: Konzolos kliensalkalmazás fejlesztése JDBC alapon, 1. rész alkalmához és a 33-36. óra: Grafikus kliensalkalmazás fejlesztése JDBC alapon, 1. rész alkalmához kötődnek.

Az SQL forráskód formázásához a Free Online SQL Formatter-t használtam.

Alkossunk másik fizetési modellt! Várjuk hozzászólásban a megoldás SQL parancsait.

Vajon hogyan változna az előző fizetési modell, ha a negyedévente kifizetendő jutalék számítási alapja a havi fizetés helyett a háromhavi – időszakra vonatkozó – fizetés megadott százaléka lenne? Hogyan alakulna a cég bérköltsége?

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

érettségi logó

érettségi logó

A 2023-as középszintű matematika érettségi feladatsorból az 5. feladat alkalmasnak bizonyult arra, hogy a programozás eszköztárával oldjuk meg. Rögtön többféleképpen is, hogy összehasonlíthatóak legyenek egymással. Érdekes belegondolni, hogy mennyire más lehetne a problémamegoldás, ha programozhatnánk a matematika érettségi vizsgán. A teljes feladatsor letölthető az oktatas.hu-ról.

5. feladat

Adja meg a 420 és az 504 legnagyobb közös osztóját! Megoldását részletezze!

Íme kulcsszavakban, mit érdemes átgondolni a megoldás előtt: számelmélet alaptétele, prímfelbontás (prímtényezős felbontás, faktorizáció), osztópár, prímek szorzata, prímtényezők szorzata, kanonikus alak, euklideszi algoritmus.

1. megoldás

Az első megoldás az euklideszi algoritmus alkalmazása. A metódus paraméterezhető. Pozitív paramétereket vár és képes kiírni a konzolra a két szám legnagyobb közös osztóját. A módszer alapötlete: a legnagyobb közös osztó nem változik, ha a nagyobb számot a két szám különbségével helyettesítjük. Ezzel csökken a nagyobb szám, így a cserék ismétlésével egyre kisebb számokat kapunk, amíg a két szám egyenlővé nem válik. Ez az eddigi számpároknak, így az eredeti számpárnak is a legnagyobb közös osztója. Az eredményt az utolsó nem nulla maradék while(m!=0) adja meg int lnko=b;. Az algoritmus lépésszáma csökkenthető, ha a>b, de ennek ellenőrzése nélkül is működik. Mivel a feladat kéri a megoldás részletezését, így aktiválva a megjegyzésbe tett forráskódokat, a kiírásból könnyen érthető, mi és hogyan történik:

A konkrét esetben a metódus eredménye: lnko (420; 504) = 84. Nagyobb számok esetében „beszédesebb” a program kiírása, több lépésben írja ki a megoldáshoz vezető utat, ezért érdemes többféle paraméterrel is tesztelni a metódust.

2. megoldás

A második megoldás a prímtényezős felbontásokon alapul. Mindkét szám esetén gyűjtsük össze listában ezeket, majd vegyük a két lista közös részét. (Ha lista helyett halmazok lennének, akkor metszet programozási tétel lenne.) A generikus listákba prímszámok kerülnek és bármelyik többször is előfordulhat. (Ezért most a leghosszabb közös részsorozat(ok) előállítása szükséges.) Addig osztjuk a számot 2-vel, amíg lehet, utána következik a többi prímosztó, amíg vannak. Érdemes több metódusra szétosztani a megoldást, mert jóval áttekinthetőbb és karbantarthatóbb Java forráskódot eredményez. A beszédes változó, objektum és metódusnevek is segítenek a megértésben. A második megoldás természetesen ugyanazt az eredményt adja, mint az első megoldás. Aktiválva a megjegyzésbe tett forráskódokat, a kiírásból most is könnyen érthetővé válik (középiskolás matematikaóra-szerűen), mi és hogyan történik:

Kanonikus alakban: 420 = 22 * 3 * 5 * 7, 504 = 23 * 32 * 7, így lnko (420; 504) = 22 * 3 * 7. Azaz összeszorozzuk a közös prímtényezőket az előforduló legkisebb hatványon.
A megoldás erősen épít a generikus kollekciók esetén jól használható Stream API lambda kifejezéseire. Ezeket most nem részletezem, helyette ajánlom a szakmai blogból a lambda kifejezés címkét.

Érdemes átgondolni

  • Nagy prímszámok esetén az euklideszi algoritmus nem hatékony. Az algoritmus végrehajtása kifejezetten lassú például a Fibonacci-számok esetén. A prímtényezőkre bontás feltételezett bonyolultságát számos kriptográfiai algoritmus használja ki. Vannak különleges esetek is, például: egyforma számok, az egyik szám 1, a két szám egymás többszöröse.
  • A feladat nem kérte a legkisebb közös többszörös meghatározását, de ha tudjuk a lnko(a, b)-t, akkor abból könnyen adódik a lkkt(a, b)=a*b/lnko(a, b).
  • A legnagyobb közös osztó tulajdonságait megismerve az euklideszi algoritmus könnyen optimalizálható. Számos esetben ellenőrzést végezhetünk, illetve triviális alapesetek is vannak. Létezik kiterjesztett euklideszi algoritmus 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.

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, 9-12. óra: Metódusok, rekurzió, valamint 17-28. óra: Objektumorientált programozás alkalmaihoz kötődik.

Sankey-diagram készítése

A Sankey-diagram alkalmas kétféle adatsor közötti N:M fokszámú kapcsolat, összefüggés és a köztes átmenet ábrázolására. Hangsúlyozza a fő átvitelt vagy áramlatokat egy rendszeren belül. Az áramlás irányát nyíllal szemlélteti és az áramlatok szélessége arányos az áramlási mennyiségekkel.

Feladat

Jelenítsük meg HTML formátumú weboldalként a magyarországi régiókban a foglalkoztatottak számát nemzetgazdasági szektorok szerint a KSH 2018-as adatsora alapján! Automatizáljuk egy Java programmal úgy a feladatot, hogy az év paraméterként megadható legyen!

Tervezés

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

  • 5. Területi adatok,
  • 5.1. A munkaerő-piaci tendenciák Magyarország régióiban,
  • 5.1.3. A foglalkoztatottak száma nemzetgazdasági szektorok szerint, nemenként (2008–)

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

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

A táblázatban lévő adatforrás szükséges része látható az ábrán:

KSH adatforrás Sankey-diagramhoz

A táblázatban a régiók az A105:A112 cellatartományban találhatók. A hozzájuk tartozó 3 nemzetgazdasági szektor a B-C-D oszlopok azonos soraiból olvashatók ki. POJO-k létrehozása mindenképpen hasznos a megvalósításhoz, például new SankeyData("Közép-Dunántúl", "Szolgáltatás", 253.89). Ezekből generikus listát is célszerű építeni: List<SankeyData> sankeyDataList.

Többféleképpen is hozzájuthatunk az adatokhoz attól függően, hogy milyen előismeretekkel rendelkezünk a különböző tanfolyamainkon:

  • A Java SE szoftverfejlesztő tanfolyamon „kézzel” letölthetjük a projekt files mappájába az XLS fájlt. Ezután akár manuálisan is összeállítható a POJO lista, vagy a JExcel API-val is hatékonyan feldolgozható a XLS fájl aktuális munkalapja. Fájlkezelés előtt az összeállított HTML fájlt kiírathatjuk a konzolra, ahonnan „kézzel” vágólapozva létrehozhatjuk belőle a szükséges HTML fájlt. Fájlkezeléssel persze adott mappába, adott fájlnévvel, kivételkezeléssel a java.io vagy java.nio csomagot használva a HTML fájl generálása is automatizálható.
  • A Java EE szoftverfejlesztő tanfolyamon megvalósítható, hogy a program kivételkezeléssel hálózati kapcsolatot épít, majd letölti az XLS fájlt és ezzel a feladat visszavezethető az előző esetekre. Azt is megtehetjük, hogy az XLS fájlt nem töltjük le, hanem olvasunk belőle közvetlenül a webről. Ekkor is rendelkezésünkre áll a POJO lista. Itt már tudunk HTML fájlt is automatikusan generálni.

Tanulmányoznunk kell a Google Charts galériában a Sankey diagram dokumentációját! Meg kell ismernünk a paraméterezési lehetőségeit és JavaScript forráskódját!

Megvalósítás

A createSankeyDiagram() függvény létrehozza a HTML fájl szöveges tartalmát. Átveszi adatforrásként a sankeyDataList generikus POJO listát. A String típusú sankeyData objektum tartalmazza a Stream API-val hatékonyan összefűzött – POJO-któl elkért – toString() szövegeket. Ezek a diagramhoz szükséges adatok ( addRows …). Például: "['Közép-Dunántúl', 'Szolgáltatás', 253.89]". A  String típusú  html objektum kezdetben tartalmazza a diagramhoz nem szükséges fix részeket, a diagram alapbeállításait, valamint a diagram fejlécéhez szükséges metaadatokat ( addColumnRégió, Nemzetgazdasági szektor, Foglalkoztatottak száma (ezer fő)). A függvény végül a html objektum #SankeyData# részét cseréli a sankeyData-val és az adatfüggő résszel frissített HTML tartalommal tér vissza.

Eredmény

Az egyik eredmény a generált HTML fájl (benne a grafikonhoz tartozó JavaScript) forráskódját tartalmazza:

A másik eredmény a Sankey-diagram képernyőképe, amelyről kiválóan leolvashatók az értékek:

Sankey-diagram

A böngészőben megjelenő HTML oldalon a Sankey-diagram dinamikusan – az egérkurzor pozíciójától függően – képes az aktuális adatok megjelenítésére, mintegy lebegő jelmagyarázatként.

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