Az élet kódjai

Az emberi agy két dimezióval egész jól elboldogul. Három sem okoz túl nagy gondot. Adat elemzés közben viszont nem ritka, hogy sokkal magasabb dimenziószámmal kell dolgoznunk. Mivel az agyunkat nem tudjuk felfejleszteni a feladathoz, az adatokat butítjuk le olyan szintre, hogy mi is megértsük. Ennek több módja is van, ezek közül nézünk meg néhányat.

PCA

A régi jó főkomponens analízis segítségével könnyedén tudjuk redukálni a dimenziókat. Az adatok közötti távolságot is arányosan forgatja el, ezért a kapott eredmények további elemzések alapját is képezhetik. Például klaszterezhetjük azokat k-közép klaszterezéssel. A PCA determinisztikus, tehát mindig ugyan azt az eredményt fogjuk kapni. Paraméterezése nincs, ezért elrontani sem lehet semmit. Hátránya, hogy a többdimenziós teret úgy forgatja el, hogy az első főkomponens mindig a legnagyobb varianciával rendelkezzen. Ez az esetek legnagyobb részénél nem probléma, de néha az érdeklődésünkre számot tartó főkomponens nem az első lesz, ezért célszerű lehet a többi főkomponens ellenőrzése is.

t-SNE

Viszonylag új módszer a t-SNE. Az egy sejtes szekvenálások előretörésével lett egyre népszerűbb a bioinformatikában. A PCA-val ellentétben nem lineáris módszer, ami azt jelenti, hogy a pontok egymáshoz viszonyított távolsága torzul, emiatt nem célszerű az eredményt további elemzésnek alávetni, inkább csak vizualizációra használni. A pontok hasonlósága ugyanis nem egy fizikai távolságot jelent, hanem egy valószínűséget, hogy a két pont jellemzői mennyire hasonlóak. A t-SNE sztohasztikus, és erősen függ a paraméterezéstől, ezért több futtatás is adhat eltérő eredményeket. Cserébe viszont az összetartozó pontok látványosabb klasztereket alkotnak.

UMAP

Az UMAP annyiban hasonlatos a t-SNE-hoz, hogy nem determinisztikus algoritmus, és nem lineáris. A megközelítés viszont más. Az adatokat egy Riemann-sokaságként kezeli, amiről annyit mondanék csak (anélkül, hogy túl sok hülyeséget hordanék össze), hogy olyan, mint egy összegyűrt papír. Egy összegyűrt papíron nehéz megmondani egy pont helyzetét, de ha kisimítjuk, akkor például a jobb sarkától egy egyszerű koordináta rendszerrel leírhatjuk azt. Nos, az UMAP megpróbálja kitalálni, milyen összegyűrt papír illik legjobban az adatainkra. Amint ez megvan, szépen kisimítja azt. Hasonló dolog történik akkor is, amikor a Földet térképpé képezzük. Az algoritmus matematikai alapja megköveteli, hogy a pontok egyenletesen töltsék ki a teret. Mivel ez nem biztos, hogy minden adatra érvényes, ezért a pontokból egy gráfot építenek, ahol a szomszédokat éllel köti össze.

Lássuk mindezt a gyakorlatban. Először is töltsük le a GDC oldaláról az agyi tumorok normalizált expresszióját. Ez három tumor típust foglal magába (egy gliómát, egy glioblasztómát, és egy B-sejtes liómát. Ez utóbbiból csak kettő van). Az expressziós adatokat egy mátrixba kell gyúrni, amit a paste Bash parancs megtesz nekünk. Szükségünk lesz még egy metaadat táblázatra is, ahol a fájlnevek és a tumor típus található. Ezt a két táblázatot kell betöltenünk R-be.

library(umap)
library(Rtsne)

cancer <- read.table("matrix.tsv", header = T, check.names = F)
pcares <- prcomp(t(cancer))
umapres <- umap(t(cancer))
tsneres <- Rtsne(t(cancer))

metadata <- read.table("metadata.tsv", check.names = F, header = T, sep = "\t")
metadata$PC1 <- pcares$x[metadata$Sample,1]
metadata$PC2 <- pcares$x[metadata$Sample,2]
metadata$UMAP1 <- as.numeric(umapres$layout[metadata$Sample,1])
metadata$UMAP2 <- as.numeric(umapres$layout[metadata$Sample,2])
tsneres2 <- data.frame(Sample = colnames(cancer), X = tsneres$Y[,1], Y = tsneres$Y[,2])
rownames(tsneres2) <- tsneres2$Sample
metadata$TSNE1 <- tsneres2[metadata$Sample,2]
metadata$TSNE2 <- tsneres2[metadata$Sample,3]

A főkomponens analízis alapból a rendelkezésünkre áll a prcomp függvényen keresztül. Az umap és a t-SNE használatához külső csomagokra van szükség, ezeket töltjük be a library segítségével. Mindhárom függvény meghívása alapértelmezett paraméterekkel, megegyezik.

Ezután készítek egy eredmény táblázatot, ahol az egyes oszlopok a különböző módszerekkel előállított pontok koordinátái. A PC1 például a főkomponens analízissel elkészített eredmény x koordinátája. A táblázat sorai pedig az egyes tumor minták.

A koordináták sorrendje nem minden esetben egyezik meg a beadott minták sorrendjével, de szerencsére a táblázat sorainak nevei segítenek eligazodni. Ez alól a t-SNE eredménye a kivétel, ahol gyakorlatilag semmilyen információ nincs, hogy miként kell értelmezni az eredményeket. Feltételeztem, hogy a sorrend nem változik a bemeneti adatokhoz képest, de erre nincs semmi bizonyítékom. Ezért voltam kénytelen bevezetni a tsneres2 változót.

Lássuk az eredményeket:

Főkomponens analízisnél a távolságok arányosak, ezért a kiugró értékek itt is elütnet a többi adattól. A glióma és blioblasztóma minták teljesen összekeverednek, ebből a nézetből nem látni semmilyen elkülönülést.

Csupán alapértelmezett beállításokkal dolgoztunk, de a t-SNE máris látványosabb eredményt adott. A tumor minták elkülönülése sokkal egyértelműbb. Látható, hogy glioblasztóma minták keverednek a kék pontok közé. Tudományos igényű elemzésnél célszerű lehet ezen adatok tüzetesebb vizsgálata, hogy megtudjuk, miért helyezkednek el messzebb a többi mintától. Az sem kizárt, hogy az adatokhoz jobban passzoló paraméterezéssel pontosabb eredményt kapunk.

Az UMAP is hasonló eredményt ad, de a kép sokkal elnyújtottabb, az eltérő matematikai megközelítés hatására.

Időről-időre beszerzek olyan hardvereket is, amelyekről úgy gondolom, hogy remek wild compó alapanyag lesz egy demópartira. Egyik ilyen szerzemény a LilyGO T-Watch is, amit szintén használtan szerváltam. Ez a hardver azért érdekes, mert egy csináld-magad mentalitású okosóra. Csináld magad alatt az óra programozását értem, mert maga a szerkezet összeszerelt állapotba került hozzám.

Az óra annyira csináld-magad, hogy alapban még az időt sem lehet rajta beállítani, tehát megvásárlás után gyakorlatilag használhatatlan. Szerintem akitől vettem, ő is ezért ábrándult ki belőle, illetve azért, mert a dokumentáció elég hiányos, de erről majd később.

Az óra alapja egy esp32 SoC. Egy mikrokontrollernél egy fokkal bonyolultabb, mert egy valós idejű operációs rendszer is fut rajta, valamint alapból tartalmaz wifi és bluetooth modult. Az érintőképernyője 240x240-es, ami egy ilyen szerkezetbe elég. Van GPS-es verzió is, nekem nem az van. Tud még rezegni, van benne egy gyorsulás és infra szenzor.

Bár a net tele van különböző videókkal, milyen remek cuccokat lehet fejleszteni rá, engem még a példaprogramok is alaposan megizzasztottak. A fejlesztéshez a leghivatalosabb doksi ez a Github repo. Most már teljesen angol, de mikor elkezdtem szenvedni a szerkezettel, félig angol, félig kínai volt.

Az első akadály az Arduino IDE volt. Azt írták, hogy 1.8-as kell minimum, de az Ubuntu repoban 2.03-as volt, amiből azt gondoltam, hogy az jó lesz, hiszen nagyobb a verziószáma. Még olyan anomáliákon sem akadtam fenn, hogy hiányoztak olyan menüpontok, amelyek a doksi szerint szükségesek ahhoz, hogy az óra programozói könyvtárait a megfelelő helyre importáljam. Megoldottam kézzel. Viszont az esp32 platform fejlesztőkészletét képtelen voltam működésre bírni. Erre is van egy menüpont az Arduino IDE-ben, a doksi szerint, de az nekem szintén hiányzott. Ezért elhatároztam, hogy lefodítom kézzel én magam.

Ez sikerült is, de az IDE képtelen volt használni. Ráadásul egy csomó eszköz alapja az esp32, és mindegyiknek van valami specifikus funkciója, amitől annyi almenü keletkezett az IDE-ben, hogy kilógott a képernyőről, és nem lehetett görgetni sem. Végül észrevettem, hogy az IDE egy konfigurációs állományában meghatázohattam a menüben az elemek sorrendjét. Átírtam a sorrerndet, ezért a nekem szükséges menüpontok mindig legfelül voltak. Így már ki tudtam választani, hogy milyen platformra fordítson az IDE, de a fordítóprogramokat továbbra sem találta. Úgy döntöttem, kell egy két hónapos szünet.

Már nem is emlékszem, milyen apropóból, de úgy döntöttem, teszek egy próbát a hivatalos oldalról letölthető Arduino IDE-vel is. Ez volt az áttörés. Megvoltak a menüpontok, működött a menük görgetése és egy klikkre felment az összes platform specifikus fordító.

A példaprogramokat viszont továbbra sem tudtam lefordítani. Bár a dokumentáció egy árva szót sem szólt róla, a fordítási hibaüzenetekből azt vettem ki, hogy kell egy csomó Python modul is. Kicsit hezitáltam, mert féltem, hogy csak a 2-es Pythonnal mennek majd a dolgok, azt meg nem akartam felrakni. Végül nagy levegőt vettem, és úgy döntöttem, a hármas verzió is jó lesz. Majd kicsit erősebben reszeljük a dolgokat. Minden fordítási kísérlet után feltettem az épp hiányzó modult, mire végül eljutottam oda, hogy fordítani tudtam, linkelni viszont továbbra sem.

Ismét kellett egy hosszabb szünet, amíg újból rá tudtam venni magamat, hogy foglalkozzam a problémával. A wifi modul linkelésénél volt a gubanc, de én már annyira ki akartam próbálni a szerkezetet, hogy végül egy Batman Dial nevű példaprogrammal kíséreltem meg a fordítást, aminek nem kell hálózat. És sikerült!

Hosszú idő után az első demoparty, amit meglátogattam, a QBParty volt. A party olyan volt, mint egy téli álmából felkelő barna medve. Lassú, nehézkes, dezorientált. Három entryt is elkezdtem csinálni, de egyik sem lett kész, ami a szokásos party hangulatnak is betett.

Azért lementem, már csak titkári teendőim miatt is. Ahogy mondani szokás a "kemény mag jött el". Ezt azért tompítanám, mert voltak első partizók is, valamint a kemény mag szerintem több emberből áll. Azt viszont mondhatjuk, hogy családias volt a hangulat. (Főleg, hogy voltak, akik hozták a gyerekeiket, kutyájukat).

Egyébként érdekes látni, hogy miként igazodik egy party a résztvevők aktuális életkorához. Annak idején, mikor még csak tizenévesként jártak partira az emberek, a barátnők ingyen látogathatták a partit. Most a gyerekek látogathatják ingyen.

A világjárvány hozadékaként nem pólót osztogattak, hanem maszkot. A Covid veszély miatt azt is ellenőrizték, hogy a szervezők betartják-e a védettségi igazolvány elkérését. Ezt úgy csinálták, hogy odajött egy emberke, akit még egyetlen scener sem látott, vagy ismert és túláradó lelkesedéssel jegyet akart venni, mintha az lenne a legtermészetesebb dolog a világon, hogy az ember demópartyra jár. Mikor a szervezők kérték tőle az igazolványt, akkor meg elkezdett magyarázkodni, majd alkudozni, hogy őt akkor is engedjék be, ha nincs nála védettségi. Feryx szerint elég szánalmas produkció volt, hiszen ide olyan emberek járnak, akik már - még ha csak látásból is - 10 évnél is régebb óta ismerik egymást. Elküldték, és ezzel jól vizsgáztak a szervezők.

A compók is lassan indultak be. Az első a fotó volt, viszonylag enyhe felhozatallal. A másodiknak a zenéket hallgathattuk végig, de itt sem érezem, hogy a készítők beleadtak volna apait-anyait. Viszonylag lagymatag volt az összes, bár meg kell jegyezni, hogy a hangosítás szerintem nem adta vissza az eredeti hangzást minden esetben. (Megerősítve, itthon végighallgatva az indulókat sokkal élvezhetőbb volt az egész.)

A játék compó volt az első, ahol láthatóan megindult valami. A QB Speedernél éreztem azt, hogy tényleges munka van benne, még akkor is, ha az assetek (vagy csak a dizájnjuk) egy része visszaköszön más produkciókból. A Drakula pedig egy remek ötlet, még akkor is, ha nem rajongok a szöveges kalandjátékokért. Itt a puszta szöveg mellett apró animációk is voltak, amitől nekem a régi Microsoft Encarta jutott az eszembe. Minden esetre, aki szeretné kipróbálni, itt megteheti.

A grafikák csak számukban voltak kevesek, minőségben egy megszokott party színvonalat láthattunk.

Csak egyetlen C64 demó volt, a Padawan csapattól. A demóról van némi háttér információm is. Visage a pandémia idején webes C64 programozást tanított pár lelkes embernek, majd elhatározták, hogy készítenek egy demót, ahol mindenki egy részt kódol, eljönnek a partyra és bemutatják, mint egyfajta diploma munkát. Nos, ha osztályozni kellene, megérdemelnék az ötöst.

A wild egy kicsit megtörte a hangulatot. Az egyik grafikai alkotás folyamatát felvették videóra, és leadták felgyorsítva. A LAL szokás szerint csinált valamit. Haragjuk központjában most a Windows 11 állt. Kaptunk egy mini horror filmet is a Kockák éjszakája címmel, ahol egy szörnypofa legyilkolta egy demóparty résztvevőit. A gyilkolást egyedül egy kis Wow kedvéért hagyta abba.

Volt egy darab 256 byte intró, egy 64k és kettő 4k. Túl sok mindent nem lehet elmondani róluk, mindegyiket a kategória egy-egy mestere alkotta, gyakorlatilag a kisujjukból rázták ki. Demóból is kettő volt. Az egyik a Dilemma sikereinek felsorolása volt, hogy hány éve ontják magukból a nyertes prodokat, a másik a Rebels sorozatban gyártott demója. Megfigyeltem, ha a Rebelsnek gyorsan kell prodot készítenie, akkor abban biztosan van egy polip-szerű effekt.

A party hangulatra nem lehetett hiba, kint és bent egyaránt ment a szórakoztatás. Bent a Double Score Dungeon koncertje, kint meg egy laptopról ment mindenféle, amire még énekelni is lehetett. Néhányan a partyról összegyűjtöttek némi pénzt, és rögtönzött grillezéssel dobták fel a hangulatot és űzték el az éhséget.

Az eredményhirdetés után már nagyon fáradt voltam, de alvásról szó sem lehetett. Előkerült egy teljes dobfelszerelés és egy elektromos gitár, majd jött a rögtönzött koncert. (Bár, aki ennyi felszerelést hoz magával, arra nem mondhatjuk, hogy rögtönzött.)

Összességében jó volt, de még szokni kell mindenkinek, hogy ki is lehet mozdulni otthonról.

Nekem az a meglátásom, hogy még soha nem volt olyan jó programozni, mint manapság. Ha pedig hihetünk a nocode, AI előretörésének, akkor elképzelhető, hogy soha nem is lesz. Azt is modhatjuk, hogy most van a programozás aranykora.

Fórumokon találkozni olyan véleményekkel, hogy manapság nehezebb elkezdeni programozni, mint annak idején, hiszen mostanság egy Android Studio telepítése, konfigurálása, netán egy példakód fordítása hihetetlen komplex feladat. Való igaz, annak idején, mikor megjelentek az otthoni használatra szánt mikroszámítógépek, csak bekapcsoltuk, és máris ott volt egy szerkesztő felület, amibe azonnal pötyöghettük a Basic kódot. Később, a DOS-os PC-k esetén is elég volt egy Turbo Pascal (a méltán népszerű Quick Basicről nem is beszélve), amit csak kicsomagoltunk és máris lehetett futtatni a mellékelt példaprogramokat.

Ehhez képest egy Android Studio tényleg olyan, mintha egy űrállomást kellene irányítani. De egy kezdőnek szerintem nem is feltétlenül erre van szüksége. Igazából továbbra is lehet használni mikroszámítógépeket, bár nem a legköltséghatékonyabb, mert a retroláz eléggé felverte az árukat. Régi PC-t viszont lehet bagóért venni, egy FreeDOS telepítése után lehet is használni a FreePascalt, ami a rendszer része. Ha pedig azon túljutottunk, akár C++ felé is léphetünk, de szöszmötölhetünk assemblyben is.

De egy modern PC-n sem kell lemondani a könnyű és gyors programozásról. Szinte nincs olyan programozási nyelv, amihez ne lehetne találni böngészőből futó értelmezőt (példa, példa, példa ez utóbbit csak poénból raktam ide). De ha imádjuk a telefont nyomkodni, ott is vannak lehetőségek, elsősorban értelmezett nyelvekre. Egy időben a QPython3-al bohóckodtam, de rá kellett jönnöm, hogy az érintőképernyős programozást nem nekem találták ki. Másnak ettől függetlenül bejöhet.

Viszont egy apró problémám volt a korai időkben, és a probléma lényege a fenti eszközökön sem változott meg az idők során. Bármit is csináltam, az csak a képernyőn jelent meg, esetleg ki lehetett nyomtatni. Ha meg szerettem volna mutatni például a nagyszüleimnek, hogy mit is csináltam, az szinte lehetetlen volt. Vigyem el hozzájuk a C64-t? Az még annyira nem is volt nehéz, de egy PC-t? Katódcsöves VGA monitorral? Kizárt.

Az internet terjedésével ma már el lehet dicsekedni nem csak a nagyszüleinknek, hanem a világ minden táján élő bunkóknak is, akik nem rejtik véka alá, milyen szánalmasak is vagyunk. De a képlet továbbra is ugyan az: amit csináltunk, az csak egy képernyőn jelenik meg. Egy demoparty keretében talán szép nagy képernyőn, de akkor is csak egy képernyőn.

Mi viszont a valóságban élünk, nem egy képernyőben.

Szerencsére viszont kitörhetünk ebből olyan kütyük segítségével, amelyek a valóságban hajtanak végre interakciókat. Ilyenek viszont nem voltak annak idején, és ezért gondolom, hogy manapság jó dolog programozni. Amit készítünk, nem korlátozódik egy képernyőre.

Az első ilyen eszköz, amit meg kell említeni, a programozható mikrokontrollerek, mint amilyen az Arduino is. Lehet tanuló kiteket is vásárolni, amelyek újonan elég húzós áron vannak, de apróhirdetésekben mindig találni olyanokat, akik megszabadulnak a régi modellektől, mert újabbat akarnak venni. A régi modellek pedig tökéletesen megfelelnek arra, hogy zümmögő, villogó, izgő-mozgó bigyókat készítsünk. Az egyetlen hátrányuk, hogy súlyos függőséget alakítanak ki, aminek következtében minél több szenzort, motort, és egyéb kiegészítő bigyót akar venni az ember. Én odaáig jutottam, hogy felvásároltam egy Spanyolországba kitelepülő ember teljes készletét. Szerintem pontosan nem is tudta, miket ad le, csak meg akarta szabadulni tőlük. Két napot csak azzal töltöttem, hogy megpróbáljam beazonosítani az alkatrészek rendeltetését.

Ha viszont növelni akarjuk a tétet, akkor nem mikrokontrollerekkel, hanem SoC-okkal is kezdhetünk. Előnyük, hogy továbbra is csinálhatunk villogó bigyókat, de akár teljes értékű számítógépként is használhatjuk. Ezekből a Raspberry-k a legnépszerűbbek. Az újabb modellek egyre töbet tudnak, de ha nem vagyunk telhetetlenek, akár még a második generációs modellekkel is remekül szórakozhatunk, miközben az áruk használtan teljesen megfizethető. Például akit elriaszt a Windows-ra telepítendő IDE-k komplexitása, azoknak csak annyit kell tenni, hogy kiválasztanak egy olyan rendszert, ami szimpatikus és kimásolja egy SD kártyára.

Ha gyerekünket akarjuk helyes számítógép használatra szoktatni, akkor ott a Kano OS. Ha hekkelni akarunk, ott a Kali Linux, ha az elektronika érdekel, akkor meg tömérdek online tutorial foglalkozik a kérdéssel. De játszhatunk rég elfeledett játékokkal a RetroPie segítségével, ami annyi régi gépet emulál, hogy felsorolni is nehéz. Sőt, ha igazán bevadulunk, akkor a Raspberry-t összeköthetjük az Arduinóval is. A lehetőségek száma végtelen, egy microSD kártya csere, és a gép kész az új kihívásokra. Ahogy növekednek az ismereteink, úgy tudjuk egyre jobban kihasználni a gépet.

Mivel a körülöttünk található valóság lassabban változik, mint virtuális társa, ezért ezeknek az eszközöknek hosszabb az életidejük is. Ráadásul a méretük is kicsi. Ha a nagyi még nem lenne fent a neten, csak zsebretesszük, elvisszük magunkkal és megmutatjuk, mit alkottunk.

Számtalan felesleges szokásaimnak egyike, hogy a programokat, amelyeket használok, letöltöm, majd archiválom. Évekkel később meg nézem a felhalmozódott adathordozókat, amelyek csak foglalják a helyet, de igazán ritkán nézem meg a tartalmukat. Lehet, hogy az írható CD-k már rég olvashatatlanok? Ki tudja? Egyáltalán emlékszem mi mindent írtam ki? Vagy hova mentettem X programot?

Nem emlékszem. Ezt abból tudom, hogy ha kell valamit, újból letöltöm, majd újból archiválom. Csak gyűjtögetem ezeket a programokat a digitális pofazacskómba, mint valami hörcsög. Még lementett GitHub repok is vannak nálam, amelyek már talán le sem fordulnak, mert ősrégi GCC kell nekik. Bár talán azok is megvannak nekem valahol.

Van felhő, a személyes tárolás a múltté. Már lassan optikai meghajtók sincsenek a gépekben, de ethernet dugó még van.

A legújabb publikációm viszont azért tudott megszületni, mert lementettem egy programot. Ráadásul nem is olyan régen.

Mint arról már korábban írtam, az UMI alapú elemzést egy jó iránynak tartom. A program GitHub oldalát le is mentettem magamnak. A laborosok szépen rá is álltak a módszerre, mi meg elemeztük őket, mint a gép.

Aztán történt egy olyan apróság, hogy az elemzéseket új szerverre költöztettük, ahol még több hely állt rendelkezésünkre, és nem kellett osztozkodni másokkal. Elkezdtük újra telepíteni a programokat, amikor is kiderült, hogy a Qiagen a eltávolította az smCounter2-t a GitHubról. Volt program, nincs program.

A biztonsági mentésemnek köszönhetően persze megvolt a program, de ott motoszkált a fejünkben a kérdés: Vajon mennyit változtattak a kódon azóta? Minden esetre elvégeztük az elemzést.

Később a csoport megvette a fizetős változatot, mi pedig leellenőrizhettük, mekkora eltérés van a két módszer között. Nos, a mindkét eredmény bájtra pontosan megegyezett. Csupán két eset volt, hogy a lefedettség 1 read eltérést mutatott. Valószínűleg volt egy elgépelés a kódban, amit kijavítottak.

Talán nem árulok el nagy titkot, ha azt mondom, hogy a Magyar Demoscene Egyesületet a legtöbb scener támogatja, jó ötletnek tartja, de tisztségeket senki nem akar viselni. Amióta részese vagyok a közösségnek, minden tisztújító közgyűlésen a régi tagok menekülni akartak, mások viszont nem akartak a helyükbe lépni. Ekkor a régi tagok fogukat szívva újra elvállalták a szerepeket. Ha pedig elérték a maximális újraválaszthatóságot, boldogan léptek le. Ekkor szokott kezdődni az a huzavona, amivel új vezetőket csalogatják.

Idén sem volt ez másként. Már majdnem úgy volt, hogy sikerül behálózni pár embert, de végül mégsem álltak kötélnek. Gargaj volt az egyedüli, aki azt mondta, hogy vállalja a következő két évre is mandátumot. Aztán megkérdezték, ki vállalná a többi tisztséget.

Természetesen néma csönd volt. Én meg arra gondoltam, miért ne vállalhatnék valamit? Igazából korábban is kacérkodtam a gondolattal, csak nem éreztem elég hitelesnek magamat. A legtöbben több, mint húsz éve a pályán vannak, tizenéves koruk óta ténykednek, erre én álljak az élre?

Most annyit változott a helyzet, hogy senki nem jelentkezett, ezért belevágtam, megpályáztam a titkári pozíciót, és megszavaztak. Nem egyhangúlag, ugyanis ketten elnöknek akartak.

Meglátjuk, mi sül ki belőle.

Nemrég az egyetemi levelezésen keresztül, egyetemi email címről kaptam egy béna malware-t. Annyira béna volt, hogy letöltöttem elemzési céllal. Az eset remekül példázza azt, hogy kártékony kód írásához nem kell különös képzettség, tudás, de még igényesség sem, csupán rosszindulat.

A szakértők a kártékony kódokat egy virtuális gépen szokták tanulmányozni, ahol megteszik a megfelelő intézkedéseket, hogy a program ne tudjon onnan elszökni és más gépeket megfertőzni. Én semmi ilyesmit nem csináltam, mert az egész egy HTML állomány volt, böngészőben pedig nem szándékoztam megnyitni.

A levél szövege szerint ahhoz, hogy az egyetem egyik fontos dokumentumát megnézhessem, egy kliens programot kell letöltenem. Ez a kliens program a HTML akart lenni a levél csatolmányában. Már a szövegről látszott, hogy ez egy jelszó lopó borzalom, de azt hittem, talán valami fergetegesen zseniális JavaScript van elrejtve benne.

Nem volt. A HTML az egyetemi levelezés bejelentkező képernyőjét másolta annyi különbséggel, hogy a beírt felhasználó nevet és jelszót egy dislack.com-os címre küldte el. Mi a csoda ez a Dislack?

A Dislack segítségével webes űrlapokat készíthetünk, nagyobb szabadságot kapva. Mintha a SurveyMonkey és a Wix keveréke lenne. Regisztráció után kipróbáltam, mit tud a rendszer. Lehet formot is készíteni, de akár végpontot is egy létező HTML-hez. Ebben az esetben a rendszer csak adatot gyűjt. Jelen esetben jelszavakat. Az összegyűjtott adatokat táblázatos formában megjeleníti, ahol az oszlopok az input mezők nevei, a sorok pedig a kitöltött a mezők értékei. A form elküldése után egy dislack oldal jelenik meg, ahol megköszönik, hogy használtuk a rendszert. Elég egyértelmű, hogy nem az egyetem terméke, de akkor már szinte mindegy, mert a jelszavunkat elküldtük. Bár ha ebben a pillanatban valaki felismeri a tévedését, még mindig megváltoztathatja a jelszavát. Az ingyenes verzióval 100 formot lehet feldolgozni, viszont nincs email ellenőrzés, ezért biztos lehet kamu email címekkel rengeteg ingyenes hozzáférést generálni. Ennek ellenére a módszer szerintem nem túl hatékony.

Nem is az a szörnyű, hogy ilyen minimális tudással csinált valaki jelszó lopót, hanem az, hogy a jelek szerint működik! Nyilván ugyan ezzel a módszerrel szerezték meg annak a felhasználónak a hozzáférését is, akitől kaptam ezt a levelet. Miután elemeztem egy kicsit a módszert, az összes információt elküldtem a rendszergazdáknak, akik írtak egy körlevelet képernyőképekkel, hogy a felhasználók felismerhessék a csapdát. Egyetlen probléma volt csak vele. Ezen az ismertetőn a rektori hivataltól jött a jelszólopós email...

Először is, nekem is meg kell jegyeznem, hogy a demoscene immár a világörökség része Németországban. Azért jó dolog, hogy a hobbim már nem csupán kockulásnak számít, hanem valaminek, ami önmagán egy ici-picit túlmutat. Ezzel az emelkedett hangulattal vágtunk neki kedvenc Húsvéti partinknak.

Az idei Revision-t már eleve online partiként tervezték, de bebizonyosodott, hogy váratlan helyzetek így is történhetnek. Az egyik alkotásban ugyanis feltűnt egy csupasz férfi hátsó (de az is lehet, hogy egy másikban látható női kebel miatt) a streaming szolgáltató megszakította az adást és kitiltotta az egész bandát, világörökség ide vagy oda. Én meg nem néztem folyamatosan az eseményeket (azaz nem csekkoltam felváltva a Discord csatornát, fórumot, komment szekciót), ezért csak későn értesültem a cseréről és lemaradtam a legtöbb alkotásról. Csak fokozatosan tudtam bepótolni a látni és hallani valót.

3D grafika

Ez egy új kategória. Eddig is voltak 3D render képek, de csak egy nézetből mutatták be őket. Itt a 3D színteret bejárta a kamera és sok olyan részletet is lehetett látni, amit a hagyományos képekben nem. Csak négy alkotás volt és még egyik sem ütött meg komoly színvonalat, de ettől függetlenül látok lehetőséget ebben a compóban is.

Oldschool grafika

A kategóriát C64 és Amiga produkciók uralták. Egyetlen Atari figyelt csak be Pandafox jóvoltából. Tetszett, hogy a képek között voltak rajzfilm hatásúak is, amik sokkal jobban passzolnak a régi gépek képességeihez. Ennek ellenére álljon itt a győztes, ami a maximálisan kihasználta a rendelkezésre álló kapacitást:

Modern grafika

Ide jött minden, ami nem régi géppel készült, bár az Ascynchronous Colors eléggé pixeles volt ahhoz, hogy akár egy Amigával is el lehessen készíteni. Ettől függetlenül a képek nagy része nem nyűgözött le. Ami legközelebb állt a szívemhez az is témájával, nem esztétikájával tette ezt. Ez pedig a Technically At Home volt:

4k grafikák

Itt viszont kitettek magukért a résztvevők. Húszonegy alkotást láthattunk, és bizony a háromnegyedük kimagasló volt, és szerintem a végső egy negyednek sincs oka szégyenkezni. Tizenegyedik helyre még egy Linux produkció is bekúszott. Önkényes választásom a The word is not enough-ra esett, mert Bond. James Bond.

Paintover

Ebben a hevenyészett Rorschach-teszt alapú compóban nem is az a legérdekesebb, mit alkotnak a művészek az eléjük helyezett pacából, inkább az, hogy mennyire különböző mindegyik eredmény. Komolyan, csak nézzük meg ezt:

És ezt:

Döbbenet.

Fotó

Pasy szintet lépett a fotózásban. Már profi modellt és műtermi felszerelést használ:

ASCII/ANSI/PETSCII

Általában a fotó, utána pedig valamelyik zene compó a legnépesebb kategória. Idén valami miatt mégis a karakterekkel rajzolás volt az, amire a legtöbben beneveztek.

Streaming music

A zenék közül egyedül Turbo Knight zenéje fogott meg, mert a szövegen én személy szerint szétröhögtem magam. Ilyen is ritkán fordul elő, hogy zenekompón felnevessek, ha mégis előfordul, az Netpoetnek köszönhető. Idén is indult, második lett, de ez a swinges akármi nem nyűgözött le.

Animációk

Bár Gaspode nyert, azért érezhetően rájátszott az amigás érzelmekre. Nekem személy szerint nem volt kedvencem a kompóról, pedig tényleg igényes munkák is készültek. A Koritsu 2 (ha valaki tudja, hol az 1., akkor szóljon) például gyönyörű volt. Az Amaranto abszolút professzionális, még ha nem is rajongok a táncos videókért.. Lehet, hogy csak hiányzott a fraktál adagom, azért nyafogok ennyit.

Oldschool demo

Itt egyáltalán nem olyan gépösszetétel volt, mint a grafikáknál. C64-el kevesebb, mint az indulók fele nevezett. Még egy Wonderswan is volt, ami egy annyira ritka gép, hogy eddig csak a három demót írtak rá. (Még Enterprise-ra is van 17 alkotás) Grass új csapata, a Lethargy is indult egy Function invitációval. Bevallom, az elején attól féltem, ez is egy scroll-és-kész-az-invite típus lesz, de nem. Az egyik effektet külön beadták intrónak is.

64k intro

Két intrót nem tudtam lejátszani, mert a Windows Defender törölte őket, amint megpróbáltam megnyitni a zip fájlt. Nem tudom, hogy ez egyedi eset-e, minden esetre a Pusztító Szarvas Isten intrót (aka Deus cervidae) csak videón láttam. Érdekes, nagyon érdekes koncepció. Többet viszont nem tudnék róla mondani. A másik érdekes dolog a Conspiracy volt. Eddig ugyanis megszokhattuk tőlük, hogy minden intrójukkal le akarták robbantani a nézők fejét utolérhetetlen grafikával, végletekig feszített művészi hatásokkal. Ha mégis csináltak valami könnyedebbet, akkor azt mindenféle álnév alatt mutatták be, nehogy a Conspiracy néven bármi folt keletkezzen. Most viszont nem tolták túl magukat, "középen pörögnek a 3D objektek" típusú intrót csináltak, de ezt én nem látom bajnak. Ha az ember állandóan azon görcsöl, hogy minél nagyobb-szebb-jobb intrót csináljon, a végén csak megcsömörlik:

Amiga demo

Az idei Amiga demók kevésbé voltak technikai kuriózumok, sokkal inkább a dizájnra mentek rá. Ez nem jelenti, hogy ne lett volna erős a kód, de kevésbé volt  fajsúlyos, mint egy Elude vagy The Black Lotus demóban. Nézzük csak meg a győztes The Martini Effectet. Néhány egyszerű textúrával gyönyörű fraktál világot teremtettek.

Bevallom, eddig a Noice csapat elkerülte a figyelmemet, pedig már 1993-óta nyomják. Címválasztásuk valami miatt a kecskék körül forog. Nincs is ez másként a Last Goat Standinggel sem. Igazi adrenalin löket.

Demo

Itt aztán bedobtak apait-anyait. Still gyakorlatilag két demót is készített. Az egyiket saját néven adták ki, a másikat Wake alatt. Tavaly is ezt csinálták, majd egyszer kiderítem, mi a motiváció emögött. A Cocoon is készített egy demót, de ennek egyetlen üzenete volt: pofátok lapos. Az utóbbi időben egyesek kritizálták őket, hogy Notch-al készítik a demókat, úgyhogy most csináltak egyet anélkül. Sok értelmet nem kell keresni benne, még akkor sem, ha story demónak akarja eladni magát. Viszont az összes létező shader izzik, számol, pakolja a tűéles textúrákat, valamint szuper karakter animáció van benne. A Futuris ezzel szemben Unreal engine-el dolgozik évek óta. Idei Dark Matter címet viselő alkotásuk nagyon szép részecske-rendszert mutat be. A New Wold Awaits című demó a második lett, itt végre megkaptam az animációknál annyira hiányolt fraktál-orgiát. Csupán az zavart, hogy sok fehérzajt pakoltak a képre. Ettől egy kicsit olyan lett, mintha raytracing lenne az egész, pedig a jelenetek nagy része csak textúrákból áll. Lehet, hogy majd jobban is elemzem ezt a demót. A győztes pedig az Arcade lett, ami az árkád játékgépeknek állít emléket. Ami itt nagyon jó volt, az a rendezés. Ahogy a jelenetek átmentek egyikből a másikba, azt szerintem tanítani lehetne. Csupán egy jelenetet nem értettem, amikor a demók nézték, hogyan táncolnak az árkádgépek a színpadon. Mit akart vajon ez jelenteni? Talán azt, hogy az árkád játékok a demók elődei? Ez biztosan nem igaz, szóval valami mást kell, hogy jelentsen. Persze az is lehet, hogy csak lusták voltak modellezni:

Futtatható zenék

A futtatható zenéknél, a procedurális grafikákhoz hasonlóan nem csupán  a végeredményt kell értékelni, hanem az azt létrehozó kódot is. Emiatt gyakran előfordul, hogy a zenék kevésbé élvezhetőek az "igazi" zenékhez képest. Viszont ahol a kettő képes kiegészíteni egymást, ott születnek a győztesek, ahogy ez történt Wayfinderrel és SunSpire-el. Nekem ugyan utóbbi jobban tetszett, mert a hangszerek természetesebb hatást keltettek.

256 byte intro

Levezetésként nézzük meg, hogy az egyik legkisebb intró kategóriában mit láthattunk. Nekem legjobban Rrrola csavarodó karfiol-fraktálja tetszett, de ő csak a harmadik helyre szorult. A Wait for it az élvonaltól messzebb helyezkedik el technikában, de ötletben határozottan a legjobb. TomCat is indult, és a 8. helyet érte el

Régen elég sok időt töltöttem számítógépes játékokkal. Még C64-el kezdtem, ahol a kazettás, primitív vackokkal nyomultam, miközben a barátaimnál tátott szájjal néztem a több lemezes komplex játékokat. Ez valahogy később sem változott, mert az új játékok mindig egy nagyobb hardveren futottak, és ezek a hardverek továbbra is haveroknál voltak.

Azt hiszem, valamikor 2005 környékén csömörlöttem meg az egésztől, onnantól nem akartam játszani semmivel. Semmivel, kivéve a GTA sorozattal. Ez az egy, ami mindig le tudott kötni. Az egész még a GTA III-al kezdődött, ami annyira új volt, annyira más, mint bármi, amit addig láttam. Mászkálhattam egy városban és mindenhol apró küldetéseket lehetett találni. Bámulatos volt. Az újabb és újabb játékok pedig csak tovább növelték ezt az ámulatot.

Ezért, mikor ingyenes lett a GTA 5, nem volt kérdés, hogy kell. De egyáltalán nem voltam felkészülve, hogy mit jelent mindez 15 év kihagyással.

Annak idején a játék valami hordozón volt. Kazettán, lemezen, majd később CD-n. Az ember betette a gépbe, majd jászott. Mivel a hardver ugyan az volt mindenkinél, így biztos lehettem benne, hogy a játék futni fog. Később ez már nem volt elég, telepíteni is kellett. A DOS-os időkben néha művészet volt a gépet és a játékot összhangba hozni, de ha megvolt, akkor biztosak lehettünk benne, hogy a játék működni fog, mert kevés hardver volt. Na jo, a hangkártya tényleg eltérő lehetett, de igazából szinte mindegyik DOS-os játékot lehetett hang nélkül is játszani.

A 3D gyorsítással ez végérvényesen megváltozott. Már millió hardver volt, és hiába lett DirectX, a helyzet  kicsit bonyolultabb lett. Már nem csak a gép, de a különböző driverek is beleszóltak a játszhatóságba. Nem elég, hogy megfelelő vas kellett, még megfelelő driverekre is szüksége volt.

A hálózati játékok nekem kimaradtak, egyszerűen azért, mert csapnivaló játékos vagyok. Annyira csapnivaló vagyok, hogy csak úgy tudtam végigvinni a pályákat, hogy megismertem a játékok gyengeségeit. Például régen az árnyékolás olyan gyerekcipőben járt, hogy csak egy sötét kört raktak ki, ami látszott a pálya alsó szintjén is. Tehát ha a mennyezeten volt egy sötét kör, tudtam, hogy ott mászik valami szörny. Néha még le is lehetett lőni a plafonon keresztül.

Mostanra minden megváltozott. Már nincs adathordozó. Először is, kell egy Epic/Steam azonosító, amivel megszerezzük a jogot, hogy megszerezzük a játékot. Ez a rendszer természetesen folyamatosan frissíti magát. De ezzel még nincs vége, mert szinte minden játéknak van saját felhője, ezért kell még egy felhasználó név/jelszó páros, amivel az adott játékkal lehet játszani. Lejön rengeteg gigabájt, bejelentkezések, hálózati azonosítók összekapcsolása, hogy ne kelljen több ezerszer beírni őket, és már lehet is játszani.

Vagy nem. Ugyanis a rendszer komplexitása tovább nőtt, ahogy a játékok frissítik magukat. Már nem csak megfelelő számítógép kell, megfelelő driverekkel, hanem megfelelő internet kapcsolat és megfelelő frissítések is (mind a Streamhez, mind a játékhoz). Bármelyik hiányzik, nincs játék. De ha megvan minden, az sem garantál semmit, mert nem biztos, hogy a legújabb frissítéstől stabilabb lesz a játék. Bármelyik komponens bármelyikkel ütközhet. Néha csak kapok egy üzenetet, hogy a szerver elérhetetlen, és kilép a játék. Esély sincs, hogy az ember bármit is tehessen ellene. Héha teljesen érthetetlen hibákat kapok, amelyek 5 perccel később nem jelennek meg.

Ezért a játék elindítása nekem plusz logisztikát igényel. Először csak egy próba indítás van, amit akkor csinálok, amikor még nincs időm játszani. Ekkor letölt mindenféle frissítést. A net és a vinyó csak úgy izzik, miközben a gép teljesen használhatatlan a terheléstől. Ott is szoktam hagyni, hogy dolgozzon, én is csinálom a magam dolgát. Ha már a vinyó ledje nem világít folyamatosan, óvatosan megnézem, nem fagyott-e le. Ha mozog az egér, akkor letörlöm a kövér izzadság cseppeket a homlokomról és lekapcsolok mindent.

Mikor van szabadidőm, újra elindítom, mert nem kell arra várnom, hogy frissítsen, de így is 10 perc kell minimum, hogy minden elinduljon. Belépek egy online világba, ami egyáltalán nem olyan, mint a Ready Player One. Ott valahogy mindenki normális. Ebben a játékban igazi Darwini rémálom uralkodik. Az erősebb egyetlen célja, hogy levadássza a gyengébbeket.

Aki nem ismerné a játékot, annak röviden elmondom: Ez a jelenünkben játszódik, egy amerikai nagyvárosban, ahol nekünk bűnöznünk kell, hogy pénzt szerezzünk. A pénzen felszerelést veszünk, hogy magasabb szinten tovább bűnözzünk. Rabolhatunk bankot, pénzt hamisíthatunk, vagy fegyverrel is kereskedhetünk.

Viszont akik már régóta játszanak és hatalmas vagyont halmoztak fel, és már teljesen unják a játékot, azok méreg drága tankokkal, vadászrepülőkkel lelőnek mindenkit, aki az útjukba kerül. Sőt, mivel a játék készítői kifogytak az ötletekből, ezért egy idő óta különböző futurisztikus frissítéseket adtak hozzá. Ezért már van lézer fegyver, repülő motor/autó hőkövető rakétával (csak, hogy célozni se kelljen), sőt, valami világűrbe telepített csapásmérő műhold is, amivel egy gomb megnyomásával bárkit el lehet pusztítani, aki a szabad ég alatt tartózkodik.

Ezek a legális lehetőségek. A játék szkript-rendszerét ugyanis néhányan megbuherálták, amitől egyesek olyan képességekkel bírnak, mint tengeralattjárót tudnak a fejünkre dobni, közönséges pisztolyból robbanó golyót kilőni, sebezhetetlenek és bárhol megjelenhetnek a játéktérben. De meg sem kell jelenniük, egyszerűen fel tudják robbantani egyszerre az összes játékos.

Igazából maga a játék is ezeknek az attitűdöknek az erősítésére épít. Ha például én eladok valami szajrét (ami jellemzően egy fegyvertelen, lassú szállítóeszköz vezetését igényli), akkor az összes többi játékos értesítést kap, hogy én mit csinálok, és egy hatalmas piros foltként jelenek meg a térképen, hogy mindenki jól láthasson. Jönnek a taktikai harci gépek, és csak örülhetek, ha egyszer robbantanak fel. Ha olyan kedvük van, akkor amint ismét megjelenek, azonnal célba vesznek. Annyi időm sincs, hogy fedezék után nézzek.

Most elég sok negatívumot írtam, kérdezhetitek, akkor miért játszom vele? Mert nem beszéltem arról, hogy mi a másik erőssége a játéknak. Nevezetesen, hogy lehet szövetségeseket szerezni, akik segítenek. Ugyanis olyan megcsömörlött játékosok is vannak, akiknek szintén megvan minden felszerelésük, de nem abban élik ki magukat, hogy a hozzám hasonló gyíkokat eltapossák, hanem büntetik a fenti rossz szándékú játékosokat. Szabályos járőrözést tartanak, figyelik a játékosok kommunikációját és beavatkoznak, ahol kell.

Ezen felül vannak olyan játékmódok, ahol erősen lekorlátozták mit szabad és mit nem. Például ha csak versenyezni akarok, akkor senki nem repülhet oda egy bombázóval. Számtalan ilyen mini játék van. A versenyzésen kívül persze különböző egymás elleni mérkőzések is vannak és kooperációs játékok is, ahol például az a cél, hogy túléljük a ránk támadó ellenségeket.

De lehetünk akár Michael Knight is, aki egy KITT-hez rendkívül hasonlító kocsival küzdi le az akadályokat. Mi lehetünk Danny Ocean (vagy ha valakinek szimpatikusabb, Debbie Ocean), aki végrehajtja az évszázad rablását. Lehetünk világmegmentő titkos ügynökök egy tengeralattjáróvá átalakuló autóval. Vezethetünk éjszakai bárt, amit természetesen a bűnszervezet fedésére használunk, de ha mindez nem lenne elég, akár az összes pénzünket elverhetjük egy kaszinóban is. Lehetünk kaszkadőrök, akik hajmeresztő mutatványokat hajtanak végre. Vehetünk egy garázst, amiben Mad Max-szerű járműveket készítünk.

Szóval egy olyan játékról van szó, ami mindig más, és még ugyan azt a feladatot is többféle módon lehet megoldani. Ilyen nem volt régen. Régen egy játék elég behatárolt volt. Még az olyanok is, mint a Raid Over Moscow, ahol bár különböző tevékenységeket kellett csinálni, ezek akkor is kötött sorrendben követték egymást. Itt sokkal nagyobb a szabadság.

Mivel R-ben tudok írni ciklusokat és ismerem a cor függvényt, félelmetes hatalomra tettem szert. Kegyetlen sok korrelációt tudok számolni igen rövid idő alatt. Ez a hatalom majdnem a Kruskal-Wallis tesztek hatalmával ér fel. Annyi korrelációt ki tudok számolni, hogy utána egy hónapig bogozzák az eredményeket a laborosok.

Ráadásul ez még tetszik is nekik. Annyira élvezik ezeknek a táblázatoknak a böngészését, hogy újabb és újabb projektekhez kérik ezt a varázslatnak felérő segítséget, mint ez történt legutóbb is.

Megkérdezték, iszonyú sürgős határidővel (mi mással?) tudnék-e nekik giga korrelációs táblázatokat generálni. Azt mondtam, tudok. Erre kaptam egy olyan táblázatot, ahol csak átlagok szerepeltek és plusz-mínusz a standard hiba. Bár már egy tucat ilyen analízist csináltam nekik, mégis, minden egyes alkalommal el kell mondani, hogy átlagokból nem tudok semmilyen korrelációt számolni, kellenek az ismétlések is. Hiába, én már csak ilyen régimódi vagyok: kell adat, hogy számoljak.

Kaptam is. Egy olyat, ami a legborzasztóbb Excel táblázatok közé kívánkozik. A fejlécek teljesen értelmezhetetlenek voltak. Minden oszlopot kiszíneztek. Voltak piros számok, amik mást jelentettek, mint a feketék. De a lényeget így sem tudták elrejteni: kiderült, csupán három ismétlésük van. Vagyis összehasonlításokként három pontból kellene kiszámolnom a korrelációs együtthatót.

Gyorsan meg is állapítottam, hogy ezzel a témával nem kell sokat foglalkozni. Persze a laborosokat nem könnyű olyannal meggyőzni, hogy valami értelmetlen. Megkérdezték, mi lenne, ha kétszer használnám fel az adatpontokat! Igaz is, minek vesződni kísérletekkel, ha egy copy-paste az Excelben megoldja minden problémánkat? Megkérdeztem, miért csak kétszer vegyük az adatokat? Vehetnénk ötször is, az lenne ám a statisztikai erő! Minek végeztek egyáltalán három ismétlést? Egy is elég lett volna, majd azt az egy adatot vennénk nagyon sokszor.

Kiderült, hogy ez még csak a jéghegy csúcsa. Ugyanis az a három ismétlés sem három ismétlés. Néha kettő, néha három, csak a biológiai mintákat összeöntötték egybe, homogenizálták, és abból vettek ki a három mintát, azt mérték le, és ennek eredményét küldték el nekem. Voilá, varázsoltak három ismétlést mindenből.

Szerintem a legtöbb olvasóm tisztába van vele, miért rossz a fenti kísérleti elrendezés, de egy példával megpróbálom a nem szakmabelieknek is elmondani.

Képzeljünk el, hogy egy cég új vízmelegítőt dob piacra. Kíváncsiak, mennyire jól melegíti a vizet. Tegyük fel, hogy annyira rosszul működnek, hogy a beállításoktól függetlenül 4 és 90 Celsius fok között bármilyen hőmérsékletet produkálhatnak. Mi viszont kiválasztunk három gépet, a "felmelegített" vizeket összeöntjük és megmérjük háromszor a hőmérsékletét. Azt látjuk mindhárom mérésből, hogy kellemes langyos vizet készít. Az eredmények alapján kiosztjuk a prémiumokat és eladjuk a gépeket, mint az esti kellemes fürdőzés nélkülözhetetlen kellékeit.

Az egyik levelezésben ráadásul láttam a laborosok üzenet váltásait is. Abban szerepelt egy ilyen mondat: "tudjuk, hogy a statisztika nem szereti a három ismétlést, de meglátjuk". Tehát már az elején tudták, hogy hülyeséget csinálnak, csak arra számítottak, hogy... Nem tudom mire számítottak. Talán arra, hogy nem veszem észre, és véletlenül mégis kiszámolok valamit? Mindegy is. A projekt két nap levelezésbe került csak, és végül a megérdemelt helyére került:

A legújabb publikációm egy olyan kollaborációból született, amiben a Linkedin-en kerestek meg, még 2018-ban. Általában csak HR-esek akarnak kapcsolatba lépni velem, ezért is lepődtem meg, hogy valódi kutatók vannak a vonal másik végén. Kíváncsi voltam, ezért igent mondtam.

A csoportot épp akkor hagyta ott egy Visual Basic bioinformatikus, ezért kellett nekik valaki, aki egyszerű programokat össze tud rakni. Az első megbízás egy Nanopore szekvenálásból származó statisztikai táblázat elkészítése volt. Mivel nagyon sokat szekvenáltak, több párhuzamos projektjük is volt, amire csak három betűs rövidítésekként utaltak.

A táblázatot két szkripttel állítottam elő, az egyik egy BAM feldolgozó Python szkript volt, a másik a statisztikai számításokat, ábrákat készítő R szkript. Első blikkre elég jól működtek. Minden elemzést az otthoni gépemen futtattam, ami akkor már elég hangos volt, hála a CPU paszta döglődésének, de még nem fagyott.

A kapcsolattartás Facebookon ment, de mivel én külsős voltam, nem sokat értettem a kommunikációból, ami tobbzódott a labor-szlengtől. Tulajdonképpen semmit nem értettem magából a kísérleti elrendezésből. Azt tudtam, hogy vírussal fertőztek meg sejteket, de a kondíciókat nem sikerült megtudni, azok számomra csak három betűs rövidítések maradtak. Igazából a kooperáció ezen szakaszán nem is volt túl nagy jelentősége, hiszen csak leíró statisztikákat kellett csinálni, amit még két újabb projekthez is elkészítettem.

Természetesen, mint minden projektben, itt is volt Nagy Kuss. Mivel nem ez volt a főállásom, ezért ezekben az időszakokban nem erőltettem én sem a kapcsolatfelvételt, hogy az új barátság ne menjen a régi rovására.

Azt gondoltam, minden rendben van. De rövidesen kiderült, hogy nagyot tévedtem. Az egyik PhD hallgató keresett meg még 2019 november elején, hogy a leíró statisztikákban van egy anomália. Nevezetesen, hogy a lefedettséggel arányosan nő az indelek száma, ami nyilvánvalóan hülyeség. Bár tucatnyi módon ellenőriztem az eredményeket, de egyetlen korrelációt sem csináltam a szekvenálási ismétlések között. Ha csináltam volna, jópár kellemetlen pillanattól kíméltem volna meg magamat.

Elkezdtem ellenőrizni a szkripteket. Külön a Pythont, külön az R-t. Tökéletesen működtek. Csináltam egy kisebb teszt adatot is. Újabb ellenőrzést végeztem, ismét megállapítottam, hogy a szkriptek tökéletesen működnek. Akkor viszont a korrelációk megléte nem hibára utal, hanem a szekvenálások jellege miatt jelentkezett. Még egy botcsinálta hipotézist is alkottam, miért látjuk a jelenséget.

Utána jött egy elég furcsa beszélgetés, amiben végigvettük az egyik PhD hallgatóval, hogyan működik a szkriptem. Néhány statisztikát több módon is ki lehetett számolni, attól függően, milyen kérdésre kerestük a választ. Minden egyes ilyen esetben megkérdeztem: Ezt szeretnétek? A válasz minden esetben: Ez is egy számítási módszer, majd meglátjuk, a főnöknek melyik tetszik. De soha nem mondtak semmit, hogy pontosan mit is szeretnének.

Aztán megtalálták a hibát is. Bár a két szkript külön-külön tényleg jól működött, a kettő együtt már nem. És én ezt is elmúlasztottam ellenőrizni. A Python szkript ugyanis néha Null-t adott vissza, ha nem volt értékelhető a szekvencia. De az R szkript ezt 0-nak vette, vagyis értékelte azt. Ezért minél nagyobb volt a lefedettség, és ezzel arányosan nőtt az értékelhetetlen szekvenciák száma, annál nagyobb volt a torzítás is. Teljesen leégettem magam. Miután láttam, mi a gond, gyorsan kijavítottam a hibát, és kérdeztem, hogy akkor újrageneráljam-e az eredményeket.

De az igazán kellemetlen dolog ezután jött. Erre a pillanatra ugyanis összehoztak egy házi szkriptet, és inkább azt akarták használni. Jött egy másik email, amiben a hipotézisemet hülyeségnek titulálták, a szkriptemet használhatatlannak. Ennek ellenére azt mondták, a cikkekbe bevesznek, tehát mégsem volt teljesen elvesztegetett idő.

Ebből is látszik, hogy a kommunikáción nagyon könnyen elcsúszhatnak a dolgok, még akkor is, ha látszólag minden rendben van. Másrészt, meg tesztelni kell a nyomorult szkripteket. Nem csak a részegységeket, hanem az egész munkafolyamatot.

A katasztrófa-filmekben azt szeretem, hogy bármilyen nagy problémával is találkoznak az emberek, végül a leleményesség, ész, bátorság segítségével úrrá lesznek a problémákon. Természetesen mindig van egy szereplő, aki az emberi kicsinyességet és butaságot testesíti meg (valami miatt többnyire polgármester a foglalkozása), de ő létszámban alul marad és a végén valami szörnyű halált hal, mintha még a katasztrófa is büntetni akarná ostobaságáért.

Egy ideje nem nézek katasztrófa-filmeket, hiszen van saját bejáratú katasztrófánk. De ebben a történetben valami miatt a butaság van túlsúlyban. Nem kell messze menni, elég csak a saját környezetemet vizsgálni. Álljon itt elrettentő példaként, és ez alapján talán mások felismerik a saját környezetükben azt, amin érdemes változtatni.

Először is, az anyósom nagyon szerette volna, ha elmennénk hozzájuk Húsvétra. Ezt eleve egy nagyon rossz ötletnek tartottam, mondtam a feleségemnek, hogy ne menjünk. Az volt a válasz, hogy "elvárják". Az én ostobaságom az volt ebben a történetben, hogy nem álltam eléggé a sarkamra, hagytam elfajulni a dolgokat.

Annyit sikerült elérnem, hogy ne tömegközlekedéssel menjünk. Mivel nekünk nincs autónk, apósom jött el értünk, ami elég nagy tortúra volt neki, hiszen két és fél óra alatt ért el hozzánk. Indulás után arról beszélgettünk, milyen súlyos a koronavírus járvány és emberek mennyire nem veszik komolyan. Az ő ismerősei között is vannak, akik szerint az oltás hülyeség, majd beszélt egy másikról is, aki azért nem ment el az oltás időpontjára, mert pont akkor hozták neki a fát.

Aztán szóba hozta, hogy a sógornőm betegeskedik, de ő akkor is ágynak esik, ha "letörik a körme". Nem most kezdte a betegeskedést, hanem már egy hete tart, de erről az elég fontos dologról valahogy nem beszéltek nekünk, pedig a látogatásaink előtt exponenciálisan emelkedik a telefonálások sűrűsége a feleségem és anyósom között.

Ekkor már kezdett felmenni bennem a pumpa, de azzal próbáltak megnyugtatni, hogy vettek a gyógyszertárban tesztet, ami negatív volt, és ez egy olyan erejű bizonyíték, hogy egy három tagú család egészségét fel lehet tenni rá.

Az út felénél jártunk, amikor kaptuk a telefont, hogy megjött a PCR teszt eredménye, ami pozitív lett. Itt már a feleségem is, én is mondtuk, hogy forduljunk vissza. Anyósomat felhívták, aki elég szomorú volt, mert már "feltettem főni a zöldborsót". Engem ekkor személy szerint a zöldborsó hőkezelése foglalkoztatott a legkevésbé. Mivel ott volt nála a négy éves keresztlányunk is, őt is a telefonhoz adta, aki sírva kérdezte, miért nem jövünk, amikor ő annyira várt bennünket.

Szegénynek csak annyit mondtak, hogy "anya beteg". Biztos vagyok benne, hogy nem értette, hogy anya betegsége miként függ össze a mi utazásunkkal, és abba is, hogy sokkal jobb magyarázat lett volna az, hogy mi nem akarjuk elkapni ezt a nyomorult betegséget.

Szépen visszamentünk. Utána még természetesen anyósom felhívott minket, és előadta, hogy a pozitív teszt ellenére sógornőm biztosan nem lehet kovidos, mert nem lázas. Ezt kérem egy volt egészségügyi dolgozó szájából lehetett hallani. Én elhiszem, hogy egy nagyszűlőnek hiányzik, ha Húsvétkor nem örjöngenek körülötte az unokák, de szerintem ennél fontosabb dolgok is vannak.

Ha már katasztrófa van, akkor viselkedjünk úgy, mint a főszereplők, ne úgy, mint a polgármester.

Néha a legváratlanabb helyről kapok tippeket. Még a pandémiás idők előtt a konditeremben kérdezték tőlem, milyen programmal szoktam videókat szerkeszteni. Az én régi módi módszereim számítógépet igényelnek, de kiderült, hogy elég tekintélyes számú megoldás létezik mobiltelefonra is.

Beszélgetőpartneremnek természetesen ez feküdt, mert úgyis a telefonnal készíti a videókat, miért másoljon mindent át egy másik eszközre? A telefonnál a kijelző mérete az, ami megnehezíti egy klippben való pozícionálást. Ha ezt a lépést valahogy ki lehetne váltani, akkor semmi nem gátolná meg, hogy a kütyün szerkesszük a videókat.

A Magisto ezt a lépést egy tanuló algoritmusra bízza. Mikor először megláttam, mire képes, nagyon impozánsnak találtam az eredményt. Látványos volt, dinamikus, miközben a belefektetett emberi munka minimális volt. Elhatároztam, hogy kipróbálom, nekem is beválik-e.

A munka érdemi része természetesen nem az eszközön történik, hanem a felhőben, ezért egy jó internetes kapcsolat elengedhetetlen. Arra gondoltam, letesztelem, hogy mire képes a program, ha például a 2019-es Functionra beadott videóm alapanyagával etetem meg. Legyen ez amolyan ember vs gép összecsapás. Nézzük meg, félni kell-e adtól, hogy a wild compókat elárasztják az olcsó, AI szerkesztette videók.

Általában én úgy dolgozom, hogy több, hosszabb videót készítek, majd az editálás során kivágom az érdekesebb részleteket és elkezdem a zene ütemére összepakolni őket. Közben többször is megnézem a klippeket, hogy inspirációt szerezzek, melyik részhez melyik klipp lenne jó. Nyilván nem ez a legjobb megoldás, de nekem nem is kell a legjobbnak lenni.

Az első probléma az volt, hogy a Magisto csak legfeljebb 10 másodperces klippeket engedett feltölteni, mert ezzel tud csak dolgozni. Kénytelen voltam kivágni neki megfelelő hosszúságú részeket a nyers videókból. Ezekből sem lehetett feltölteni akármennyit, mert én csak a próba verziót használtam. Ha ezt nézzük, akkor a rendszer nálam meg is bukott, hiszen egy 3-4 perces videót nem tud készíteni 1-2 órás alapanyagból. De ha már itt tartunk, nézzük meg, mennyire tudja megkönnyíteni a munkát.

Feltöltöttem az általam kivágott részeket, hozzáadtam a zenét, majd néhány kérdésre kellett válaszolni, hogy milyen legyen a videó stílusa. Ezek igazából csak különböző filtereknek tűntek számomra, tehát senki ne gondolja, hogy kattintok a Michael Bay opcióra, és rögtön jön a forgó kamera.

Az én esetemben nem sok mindent csinált a program (vagy fogalmazzunk úgy, nem sok látványos dolgot), szinte csak egymás mellé pakolta a klippeket és szénné effektezte. Egyetlen kockát sem hagyott érintetlenül, mindenre adott valamit, még abban az esetben is, ha direkt visszafogtam az alkalmazandó effektek számát a beállításokban.

Túl sokat sajnos nem lehet játszani az ingyenes kipróbálási lehetőséggel. A második-harmadik próbálkozásra már csak SD felbontású videót eredményez. Rövid játszadozásom tehát egyetlen értelmes videót sem eredményezett. Ezért elhatároztam, megnézem, mások milyen eredményre jutottak a program segítségével. Egy idő után már kezdtem felfedezni némi mintázatot, feltűntek az így készült videókkal a közös elemek. Vagyis úgy tűnik, kreatív munkára nem alkalmas. Amit készít, egyfajta tömegtermék.

Ezt erősíti meg a cég weboldalán látható különböző sablonok, valamint mely területeknek nyújtanak támogatást. A tucat munka elsőre derogáló kifejezésnek tűnhet, bár vannak bizonyos előnyei is. Például szerintem a legtöbb mobiltelefonos videó elég pocsékul néz ki. Remeg a kép, nincs elég fény, elmozdul a fókusz, stb. A megfelelő pillanatot is nehéz elkapni. Ha évekkel később megnézzük a felvételt, gyakran már nem is értjük, miért vettük fel valaki hisztérikus kacagását. Ha pedig értjük, akkor az válik rejtéllyé, miért találtuk ezt régen viccesnek. Ráadásul a telefonos videózás olcsó, ezért gondolkodás nélkül levideózunk mindent, nem mérlegelve azt, hogy van-e értelme.

Ezekből a nagyszámú, többnyire selejtes videóból a Magisto készít egy vállalható eredményt, amivel lehet villogni a haverok előtt. Jó eséllyel képes kiválasztani a megfelelő pillanatot, a hibákat pedig digitális sminkkel szépen elfedi, ha pedig a havernak is hasonló a videója, az nem zavar senkit, mert nincs verseny.

Azoknak, akiknek a munkájukhoz kell videó tartalmat készíteni (például egy ingatlan ügynöknek), azoknál szintén előny, ha a minden lakást hasonló módon mutatnak be. Ráadásul nem kell alkalmazni egy embert, aki a 200. videó után elátkozza azt is, aki feltalálta a videókamerát, mert már annyira unja, hogy mindent ugyan úgy kell megcsinálni. Nekik segítség lehet egy ilyen program. Ráadásul ők készítenek annyi videót, hogy megérje előfizetni a szolgáltatásra.

Mert a másik rékfenéje a Magistonak, hogy előfizetéses rendszerben működik. Egy magánembernek szerintem nem éri meg. Hiszen egy évben van egy nyaralás (esetleg kettő, ha télen síelni is elmennek), egy-két születésnap, karácsony, és néhány emlékezetes esemény. A többi időszakban nem csinálnak videókat, de a pénzt akkor is be kell fizetni.

Beszélgettünk is a konditeremben, hogy talán érdemes lenne többünknek összeállni egy előfizetésre, mert külön-külön nem videózunk annyit, hogy megérje előfizetni. Végül nem mentem bele, mert nekem szükségem lenne, hogy letötlhessem a videót, ráadásul én a kreatív alkotás felől közelítem meg a videóvágást, még ha ez nem is látszik meg a végeredményen.

Annyit viszont én is tanultam ettől a mesterséges intelligenciától, hogy nem kell félni egy kis effektezéstől. Ha például van két nagyon hasonló beállítás, akkor egy effekt alkalmazásával el lehet érni, hogy ne tűnjön annyira repetitívnek. Ezt alkalmaztam is a tavalyi Revision-ön, bár így is csak 11. lettem.

Mivel nem sikerült megoldást találnom a GUS kártyás gép problémáira, ezért a munkahelyi nagy szanálás idején mentettem egy Pentium 1-es gépet. Beleraktam a a hangkártyát, a CD olvasót DVD-re cseréltem, és ment minden, mint a karikacsapás. A DVD olvasó is működött, nem fagyott le, mint az előző gépnél. Egyetlen hátránya, hogy soros egérrel üzemel, ezért az USB, PS2 egerek mellett már egy soros egér is van az asztalomon. Ez legyen a legnagyobb probléma.

Megpróbáltam két egérre szűkíteni a beviteli eszközök számát, de nem sikerült. Először egy átalakítóval próbálkoztam, de rá kellett jönnöm, hogy a lézeres egeret átalakítóval sem lehet rácsatlakoztatni a gépre, mert nem ad le elég feszültséget, hogy az elektronika üzemeljen. Mindenképp egy golyós egérre van szükség. Még szerencse, hogy nálam ilyen is van.

A DIN-es átalakító segítségével a PS2-es billentyűzet gond nélkül üzemelt, ezért abból nem kellett egy harmadik az asztalra. Oké, akkor elméletileg meg tudom nézni az összes GUS-os demót. És gyakorlatilag?

Először is le kellene tölteni az összeset. A Pouet.net oldalán ott vannak HTML-be ágyazva az összes információ. Egy közönséges wget-es szkripttel letöltöttem az összes oldalt, amiben felsorolták a GUS tartalmú alkotásokat. Ez könnyű volt, csak egy GET-es paramétert kellett változtatni az URL-ben. Mivel ez csak egy összesítő oldal, szükség van minden egyes alkotás adatlapjára, ahol megvannak a közvetlen linkek. Ebből ki kell nyerni a közvetlen linket, és kész.

Mivel a munkahelyi tapasztalatokból tudom, hogy rengeteg anomália fog fellépni a letöltés során, ezért először csak egy táblázatot készítettem, ahol az alkotás neve, pouet azonosítója és a letöltés linkje szerepel.

Az anomáliák persze jöttek is. Mivel ezek DOS-os programok, a 8+3 fájl név limit miatt több alkotásnak is ugyan az volt a fájlneve. Voltak döglött linkek, ahonnan már semmit nem lehetett letölteni, szerencsére ezekből kevés akadt. Egyes esetekben pedig kézzel kellett finomhangolni a letöltést, mert az elérési út nem teljesen az volt, ami a Pouet.net-en látható.

Végül sikerült! Összesen 1211 produkciót sikerült letölteni. Kényelmesen elfértek egy DVD-n.

Sajnos elsőre rosszul írtam ki, mert a Windows beépített DVD író alkalmazását használtam, ami minden igyekezetem ellenére is UDF-ben írta ki az adatokat. Természetesen pont ez az a formátum, amit FreeDOS alatt nem tudok olvasni. Másodszorra már ISO-ként írtam ki, mire mindent gond nélkül tudtam használni a GUS-os géppel.

Ez a szám elég tekintélyes. Ha csak tízet nézek meg naponta, akkor is négy hónap, mire a végére érek. Kinek van szüksége ezek után Netflixre?

Az ember diploid élőlény, ami azt jelenti, hogy a teljes kromoszóma készletéből kettő van. Egy anyai és egy apai eredetű. Ha csak a legegyszerűbb DNS változásokat, a nukleotid variációkat nézzük, akkor ez azt jelenti, hogy ha megnézzük egy egyén SNP-it, akkor azt jó eséllyel megtalálhatjuk legalább egy szülőben is (feltéve, hogy eltekintünk a szekvenálási hibáktól, spontán mutációktól, nukleotid modifikációktól és még egy csomó olyan dologtól, ami csak azért van, hogy összezavarja az ép ésszel megérthető modelljeinket).

Jogos igény, hogy a vizsgálatok során megtalált mutációkat hozzá tudjuk rendelni vagy az anyai vagy az apai kromoszóma készlethez.

Amennyiben nem használtunk speciális könyvtár előkészítési módszereket, úgy bioinformatikai eszközökkel kell megbírkózni a problémával. Ahogy azt már megszokhattuk, itt jönnek a gondok.

Amikor ugyanis egy biológus haplotípusról beszél, akkor az alatt a klasszikus anyai és apai kromoszóma felosztást érti. Ez pedig alapesetben csak és kizárólag bioinformatikai eszközökkel megállapíthatatlan.

Amit egy bioinformatikus meg tud csinálni, az a variációk haplotípus csoportokba rendezése. Mit jelent ez? Azt nem tudom megmondani, hogy apai vagy anyai eredetű-e egy mutáció, de azt mondhatom, hogy az adott mutáció az előtte-mögötte lévő mutációk közül mennyivel van azonos kromoszómán. Ha pedig véget ér egy haplotípus csoport, és kezdődik egy másik, akkor azt célszerű teljesen független egységnek kezelni.

A VCF fájlban, ha egy mutációról egy program meg tudta állapítani, hogy egy adott haplotípus csoportban van, akkor egy "pipe" jellel választja el a genotípust a perjel helyett. Ezt a VCF fájl 10. oszlopától kezdődően láthatjuk, attól függően, hogy mennyi mintát tartalmaz a fájl.

Miként határozható meg, hogy két mutáció egy haplotípus csoportban van-e? A legegyszerűbb módszer, amit akár mi magunk is elvégezhetünk egy IGV segítségével, ha megnézzük, hogy a két mutáció egy readen van-e. Ez a módszer természetesen csak akkor működik, ha a mutációk távolsága kisebb, mint a read hossza, és a mutációk heterozigóták. (Hiszen a homozigóta mutációk mindkét kromoszómán megvannak.) Ha azt látjuk, hogy az egyik mutáció csak a readek felében fordul elő, míg a másik mutáció a readek másik felében fordul elő, akkor különböző kromoszómán vannak. Ha konzekvensen ugyan azon a readen vannak, akkor egy kromoszómán vannak.

Ennek a módszernek a kiterjesztése, ha egy de-novo összeszerelést végzünk, amivel szinte meghosszabbítjuk a readjeinket. Ezt csinálja a GATK HaplotypeCaller modulja.

A módszer a hosszú readek korában reneszánszát éli. A humán X kromoszóma teljes összeszerelése közben azt vették észre a kutatók, hogy a mostani technológiával mindig találni annyi heterozigóta SNP, indelt vagy struktúrális variációt, hogy akár még a centromereken is átívelő haplotípus csoportokat tudtak felépíteni.

A másik módszer, hogy megszekvenáljuk a szülőket. Ezt csinálja például a Beagle program is, de csak a 3-as verziója. Mivel a variációk nagy részét örököljük, nem nehéz megmondani, hogy mi az eredetük. A problémát itt a spontán mutációk okozzák, amelyek nem találhatóak meg egyik szülőben sem.

További lehetőség, amennyiben rendelkezünk genetikai térképpel, hogy meghatározzuk, milyen messze vagyunk a rekombinációs pontoktól. Minél közelebb vagyunk, annál nagyobb az esélye, hogy a haplotípus csoportunk széléhez tartunk.

Mielőtt tovább mennénk, vizsgáljunk meg még egy lehetőséget. Amennyiben nincs lehetőségünk a szülők szekvenálására, de van egy nagyobb genotípizált populációnk (modell organizmusok előnyben, ugyebár) akkor annak segítségével is megállapítható, hogy hol van nagyobb eséllyel rekombináció. Ez a lehetőség a Beagle 4-es verziójától felfelé érhető el. (Miközben az öröklésen alapuló módszert szépen kivették a program funkciói közül.)

Ami a fenti módszerekben közös, hogy végül egy rejtett Markov lánc segítségével próbálják meg meghatározni a haplotípus csoportok határait. Ezt csinálja a HaplotypeCaller, a Beagle a régi és az új verzióiban egyaránt. Itt emlékezzünk vissza, mit is tapasztaltunk, amikor játszottunk a saját rejtett Markov láncunkkal. Nevezetesen, hogy az állapot változások kezdete és vége nem mindig esik egybe a tényleges rejtett állapotok átmeneteivel.

Ezt akkor vettem észre, amikor egy trio adat elemzése közben fázisolni akartam. Lefuttattam a Beagle 3-t, Beagle 5-öt, miközben a VCF a HaplotypeCallerrel készült. A három eredmény elég eltérő volt ahhoz, hogy elkezdjek a dolgok mélyére ásni. Arról nem is beszélve, hogy a rejtett Markov láncok sztochasztikus modellek, tehát az eredmény futásról futásra változhat. Ezért gondolom, hogy a haplotípus meghatározás egy átverés. Hiszen nem azt mondja meg, amit egy biológus elvár, és azt is rosszul. Nem annyira rosszul, mint egy exom alapú CNV, de elég rosszul, hogy az eredményeket kételkedve fogadjam.

A helyzet a hosszú read szekvenálásokkal javulni fog, sőt, most is vannak olyan könyvtár előkészítési eljárások (például a 10x Chromium), amelyek segítségével pontosabban határozhatjuk meg a haplotípusokat. Ha mégis olcsóbban akarjuk megúszni, akkor a referencia panel alapú megoldást válasszuk, mert jelenleg az a legpontosabb. Ha olyan fajjal dolgozunk, ahol nincs referencia panel, akkor próbáljuk megszekvenálni a szülőket is, de ha ez sem megoldható, akkor ne számítsunk semmi jóra.

- Bocsánat, főfelügyelő úr, de a segítségét kell kérnem - mondta félve a kalaúz, mikor belépett a szűk kis vonatfülkébe.

A férfi letette az újságot, amit éppen olvasott és a kalaúzra pillantott.

- Ennek köze van ahhoz, hogy a vonat nem megy? - kérdezte Poirot.

- Azt hiszem, igen. Tudja, lefagyott a Számítógép, és Ön, mint az összeomlások szaktekintélye, talán tud segíteni.

- Roppant sajnálatos, amit mond, de most épp nyaralok. Ki a területi illetékes?

- Már felvettük a kapcsolatot a hatóságokkal, de amíg ideérnek, kihülhetnek a nyomok. A tetteseknek itt kell lenniük. Mint Ön is tudja, a legközelebbi állomás is több száz kilóméterre van innen. Úgy is mondhatnám a semmi közepén vagyunk.

- Ez esetben a tettes sem tud elmenekülni. Nincs más dolgunk, mint megvárni, hogy a hatóságok ideérjenek - dőlt hátra Poirot.

- Van még egy dolog. Ha megvárjuk, hogy megérkezzenek a nyomozók, az legalább öt óra. Megkezdik a nyomozást, további órák fognak eltelni.

- Értem, de az illetékesek biztosan nem fognak örülni neki, hogy belekontárkodom az ügyükbe. Mint rendőrnek, nekem is kellemetlen, ha mások akarják elvégezni a rám szabott teendőke.

A kalaúz roppant feszélyezetté vált. Szemmel láthatóan gyötrődött, hogyan vegye rá a híres főfelügyelőt, hogy szegje meg a bűnüldözők íratlan szabályát. Poirot látta ezt.

- Talán annyit mégis megtehetek, hogy előkészítem a terepet a kollégáknak.

A kalaúz láthatóan megkönnyebbült. Egy biccentéssel köszönte meg, majd így folytatta:

- Kérem főfelügyelő úr, erre jöjjön. Az utasok már várják.

Egy kis kupéban foglalt helyet a nyolc ember. Poirot alaposan szemügyre vette őket.

- Üdvözlöm Önöket. A nevem Poirot. Egy sajnálatos összeomlás miatt vagyunk itt. Önök mindegyike hardver komponens, akik jelen voltak. A felelős önök között van.

- Tipikus - szólalt meg egy díszes ruhába öltözött hölgy. Lila ruhája és millió fodros kalapja volt. - Amint történik egy összeomlás, azonnal a hardverekre esik a gyanú. Miért nem nézi meg a másik kocsit, ahol a szoftver komponensek vannak? A bárban hallottam, hogy a Windows például hónapok óta nincs frissítve.

- Kit tisztelhetek kegyedben? - kérdezte Poirot.

- Ms. Memória vagyok. Nem kevesebb, mint 32 GB. Négy modulban helyezkedem el és évek óta gond nélkül látom el a feladatomat.

- Igaz, de elég csak egy modul rossz működése és máris kimerevedik a kép. Mivel Ön 32 GB, ami elég nagy, a hiba nem lesz perzisztens, csak ha épp a rossz modul kerül használatba.

Ms. Memória dacosan felhúzta az orrát, és elfordította a fejét.

- A hölgyne ettől függetlenül igaza van. Miért nem az operációs rendszereket kérdezi ki? - vetette közbe egy magas, fehér öltönyös úr. Hanyagul keresztbe tette a lábát és épp kávét szürcsölt.

- Mert több fagyás is történt. Windows és Linux alatt egyaránt. Ez pedig a hardver hibára utal.

Döbbent csend követte a bejelentést. Az emberek zavartan egymásra néztek.

- Bocsátnat, a nevem Tápegység. Nekünk a kalaúz azt mondta, hogy csak egy fagyás történt - mondta egy kopott kabátot viselő úr. Kicsit kilógott az úri társaságból. A többiek látszólag tudomást sem vettek róla.

- Mert a második fagyásról a kalaúz nem tud. Ő csak a Windowst ismeri, ezért a Linux alatti fagyás elkerülte a figyelmét. Észrevettem, amikor bekövetkezett, de nem szóltam, mert nem voltam biztos, hogy Windows alatt is meg fog-e ismétlődni. Ráadásul nyaralok, hivatalosan nem kezdeményezhetek nyomozást.

- Most mégis itt van - jegyezte meg a fehér öltönyös úr.

- Csak addig, amíg a hivatalos szervek meg nem érkeznek. Az érkezésükig órák is eltelhetnek, a vizsgálat lefolytatása szintén hosszadalmas lehet, ha addig közelebb jutunk a megoldáshoz, hamarabb elmehetünk. Közös érdekünk, hogy ne vesztegeljünk itt sokáig.

- Mi történik, ha nem működünk együtt? - kérdezte egy merev tartású, katonai egyenruhát viselő férfi. - Hiszen maga mondta, hogy csak nyaral. Csak annyi joga van, mint bármelyikünknek itt a kocsiban.

- Úgy látom, Ön ezredesi rangban szolgál a seregben.

- Jól látja. Processzor ezredes vagyok, a 8350FX-es zászlóaljban. Nyolc mag tartozik a parancsnokságom alá.

- Az jó sok mag. Elég nagy eséllyel okozhat fagyást.

- Ha tényleg olyan szaktekintély lenne, mint ahogy hírlik Önről, akkor tudná, hogy hibás CPU esetén egyáltalán nem indul el a számítógép.

- És mi a helyzet a túlmelegedéssel? Alaphelyzetben semmi rendellenes nem látszik, de elindul két-három program, és megnövekszik a fogyasztás. Megemelkedik a hőmérséklet, majd minden lefagy.

- Az én parancsnokságom alatt ez elképzelhetetlen. Legfeljebb, ha az a léhűtő Ventillátor nem végzi a dolgát.

Minden szem egy flegma fiatal emberre szegeződött. Drága ruháit lezserül viselte, egyik-másik darab még gyűrött is volt, de Ventillátort ez nem zavarta. Haja is rendezetlen volt.

- Nem értem ezt a felhajtást - mondta egy fintor kíséretében. - A fordulatszámomat, Processzor kapitány...

- ...ezredes... - sziszegte a fogai közül a katona.

- ...bármikor megmondja az Alaplap. Tőle kell kérdezni ezeket.

- Gondolom, Ön lesz Alaplap - fordult Poirot a fehér öltönyös férfihoz, aki meglepetten nézett vissza.

- Honnan...

- Egyszerű. Az Alaplapnak mindenkivel kapcsolatban kell állnia. A testbeszéde elárulta, hogy Ön központi személy ebben a helyzetben.

- No, igen, az én szakmámban a kapcsolat jelent mindent - jegyezte meg nem kis önelégültséggel.

- Egy kapcsolat lehet jó, és rossz is. Nem kerülte el a figyelmem, milyen szemeket mereszt Önre Ms. Memória. Processzor ezredes pedig látszólag ellenséges Önnel.

- Ez egy régi vita közöttünk. Az ezredes felsőbbrendűnek tartja magát, mert minden számítást ő végez. Szerintem pedig fontosabb, hogy minden komponens zökkenőmentesen együttműködjön. Az adatnak el kell jutnia egyik helyről a másikra, nem elég kiszámolni azokat.

Az ezredes horkantott egyet, de nem szólt semmit.

- És mit mond Ön a fordulatszámról?

- Teljesen normális, a beállított értéken pörög.

- Észrevett bármilyen problémát a fagyás előtt? A szenzorai bizonyára érzékeltek valamit.

- Nem - majd kis szünet után hozzátette - De az újraindulás utána feltűnt valami.

- Micsoda?

- Processzor hiba.

Az emberek felhördültek. Az ezredes feje vörösödni kezdett, mint egy kitörni készülő vulkán.

- Az én részegységem minden pillanatban tökéletes munkát végez. Miközben maguk csak henyélnek, én akkor is dolgozom. Én gyűjtöm be az összes információt, és feldolgozom azokat a legjobb tudásom szerint! Míg Ms. Winchestene felpörög, én már milliónyi számítással végzek. Ventillátor mást sem csinál, csak szelet kavar. De ön - remegő ujjával Alaplapta mutatott - ahelyett, hogy eljuttatná az általam kiszámított eredményeket, csak megakasztja az egész folyamatot! Egymás ellen hangolja a részegységeket és meghamisítja a diagnosztikai jeleket.

- Én nem hamisítok meg semmit! - emelte fel a hangját Alaplap is. - Ha a POST alatt bármi történik, akkor jelzem. A fagyás után egyedül Önnel volt probléma.

- Kikérem magamnak! A maga szenzorai hibásak, hibás diagnózist állapított meg.

A kocsiba szó nélkül belépett egy hadiapród és az ezredeshez ment. Átvett tőle egy papírt és távozott.

- Mit adott át neki? - kérdezte Poirot.

- Lehet, hogy Önnek van ideje itt beszélgetni, de a munkának folynia kell tovább. Processzorként vannak bizonyos kötelezettségeim.

- Ahogyan nekem is. Ha megbocsátanak, akkor egy kicsit magukra hagyom önöket - mondta Poirot, majd válaszra sem várva az ajtó felé indult.

- Mégis hova megy? - csattant fel Ms. Memória.

- Megkérdezek valamit a kalaúztól - mondta titokzatosan a felügyelő, majd távozott.

- Most meg itt hagy minket - állapította meg Ms. Memória, inkább csak úgy, magának.

- Nem kell aggódnia drágám, hamar vége lesz ennek - vígasztalta Alaplap.

- Lehet, hogy azért próbálja rám hárítani a felelősséget, hogy leplezze a kisasszony bűnösségét - jegyezte meg Processzor.

Mielőtt bárki válaszolhatott volna, ismét megjelent Poirot.

- Kérem, kérem! Vádaskodással nem megyünk semmire. Azért vagyunk itt, hogy megoldjuk a problémát.

- A felügyelőnek igaza van - mondta Ms. Memória. - Én készen is állok, hogy bebizonyítsam ártatlanságomat. Csak futtatni kell a MemTest86-t, és utána látni fogják, hogy velem nincs semmi probléma.

- Hajlandó alávetni magát a tesztnek? - kérdezte Poirot. - Mint tudja, nem utasíthatom rá. Viszont ha megjönnek rendőrök, ők megtehetik.

- Természetesen alávetem magam. Nincs okom félni a teszttől, ártatlan vagyok.

A teszt nem volt rövid. Többször is meg kellett ismételni, hogy mind a négy modult leellenőrizzék. A végén Poirot szomorúan közölte:

- Önnek két memóriamodulja is hibás.

A hölgy nem szólt semmit. Méltósággal hallgatta, majd a szemében könnyek kezdtek gyűlni.

- Egészen biztos benne?

- Sajnos igen. Az random írás-olvasás teszt rendszeresen hibás értéket adott vissza. Többször is ellenőriztem.

- Akkor végig én voltam a hibás? Ez olyan hihetetlen. Amikor az ember összeomlást lát, mindig azt hiszi, az csak valaki más hibájából történhet. Soha nem gondoltam volna, hogy...

Befejezni már nem tudta. Hirtelen kialudtak a fények. Az utasok összerezzentek.

- Mi történt? - kérdezte pánikkal a hangjában Tápegység.

- Egy újabb fagyás, az történt - jegyezte meg csendben Poirot.

- Szóval Memória kisasszony újabb hibát produkált - jegyezte meg Processzor nem kis gúnnyal a hangjában.

- Nem. Ezuttal nem. A hibás modulokat eltávolítottuk a teszt végeztével. Memória kiasasszony már csak a jó modulokkal üzemel.

- Vagyis? - kérdezte Alaplap.

- Van még egy tettesünk. Mr. Alaplap, most mit mutat a POST teszt?

- Processzor hibát.

- Hogy nem sül le a képe még mindig engem pocskondiázni!

- Maga csak ne beszéljen. Folyton másra akarja kenni a problémát, holott már korábban is mondtam, hogy a maga tesztje nem sikerült. Minden részegység mellett van egy kis LED, és folyton maga melletti gyullad ki. Ezt mivel magyarázza?

Processzor ezredes nem válaszolt azonnal. Száját ragadozó mosolyra húzta.

- Maga azt sem vette észre, hogy Ms. Memóriával gondok vannak. Lehet, hogy Ms. Memória tényleg ártatlan, és az Ön foglalatai kontaktosak. Azt jelzi, hogy hiba van itt is, ott is. De valójában csak egyetlen hiba van - az ezredes közelebb lépett. - Maga.

- Nem - csak ennyit tudott mondani Alaplap, és hátrálni kezdett.

- De igen. Mondja csak meg neki, felügyelő úr. Egy kis áram ingadozás, korrodáció az érintkezőknél. De elég egy kis hibás kondenzátor, felpúposodott tetővel, és máris kész a baj.

- De..de...

- Az ezredesnek igaza lehet, de áram ingadozást más egységek is okozhatnak. Olyan egységek, amelyek egyébként is sok áramot vesznek fel - ezzel Poirot egy ikerpár felé fordult, akik eddig csendesen figyeltek. - Ha nem tévedek, a híres GPU ikrekhez van szerencsém.

- Igen - felelte a jobb oldali testvér. - SLI-be kötve - fejezte be a bal oldali.

- A teljes rendszer áramfelvételének a 2/3-a maguknak kell.

- A nagy teljesítményhez - kezdte a jobb oldali. - Nagy áram kell - mondta a bal oldali.

- A hőtermelésről nem is beszélve.

Az ikrek bólintottak. Lassú mozdulattal, akár csak a szinkron úszók.

- Úgy gondolja felügyelő úr, hogy az ikrek miatt megzavarodtak a szenzoraim? - kérdezte Alaplap.

- Csak arra akartam utalni, hogy a feszültség fontos tényező. Amíg kevés kell, addig észre sem vesszük, de ha megnövekedik a részegységek igénye, akkor akinek nem jut elég áram, nem működik megfelelően.

- Szerintem pedig az ezredes a ludas - mondta Alaplap, hogy visszaszerezzen némi önbecsülést, amiért allul maradt az előző szópárbajban.

- Figyelmeztetem, hogy... - kezdte vörösödő fejjel az ezredes.

- Az ezredes teljesen ártatlan - vágott közbe Poirot.

- Miből olyan biztos benne? - kérdezte Ms. Memória.

- Mert az ezredes parancsai nem jutottak ki ebből a szóbából. Mikor kimentem az apród távozása után, akkor azért mentem ki, hogy elintézzem, hogy a parancsai ne jussanak tovább. Egy másik katonatiszt látta el az ön feladatait ez idő alatt.

- Hogy mert engem lecserélni!? Ehhez nem volt joga.

- Ez igaz. Viszont szükséges lépés volt, hogy kiderüljön, Ön áll-e a hibák hátterében.

Alaplap láthatóan összetört a hallottak alapján.

- Akkor mégis csak én vagyok a hibás - mondta, majd egy fotelba huppant. Ms. Memória együttérzően mellé ült, és megsimogatta a kézfejét. - Az lenne a feladatom, hogy összehangoljak mindent, de képtelen vagyok rá. Ezek alapján csak is én lehetek, aki nem megfelelően működik.

- Kicsit túl szigorú magához - mondta Poirot. - Maga csak látott egy anomáliát, de nem látta az igazi okot.

- Ezt hogy érti?

- Amikor érzékelte, hogy Processzor felől nem jön információ, akkor azt hitte azért, mert Processzor működésében van valami probléma. De azért nem jött információ, mert nem jöhetett. Processzor ezredes ugyanis nem kapott áramot.

- Ezt nem értem. Összeomlás csak ritkán fordult elő. Az esetek nagy részében minden zökkenőmentesen működött. Hogyan lehetséges, hogy egyszer kap áramot, egyszer meg nem? Ennek semmi értelme.

- Igen, magam is szívesen venném, ha felvilágosítana - jegyezte meg az ezredes.

- Azonnal. Az áram ellátás ugyebár úgy néz ki, hogy megy egy 24 tűs ATX csatlakozó Alaplaphoz - a férfi bólintott. Van egy másik, illetve jelen konfigurációban két másik ár a GPU ikrekhez.

- Igen, igen, tudjuk mind. Kapnak Winchesterék, GPU, Alaplap. Minden részegység árammal megy, ezért van rajtuk csatlakozó. Legyen szíves a lényegre térni!

- A lényeg, hogy van még egy 12 Voltos csatlakozó, ami közvetlenül Önnek jár, bár Alaplap kapja. Ha ez az ág nem szállít elég áramot, akkor Alaplap úgy érzékeli, hogy Ön nem működik. Általában nincs is gond, de ha megnő a számítógép áramfogyasztása, akkor jelen esetben ez az ág nem ad le elég áramot. Tehát a tettes Tápegység!

Az említett férfi szeme elkerekedett. Hirtelen felugrott, és az ajtó felé kezdett futni. Az ezredes, azonnal utána vetette magát. Ms. Memória felsikoltott. Tápegység feltépte az ajtót, de visszahőkölt. A rendőrség emberei már ott voltak. Éppen be akartak kopogni. Tápegység kikapta az egyik rendőr övéből a pisztolyt.

- Álljanak meg. Maguk ketten - fordult az újonan jött rendőrök felé -  jöjjenek be, és álljanak a többiek mellé. Gratulálok felügyelő úr. Kicsit alábecsültem magát. Utoljára fogom megölni, hogy kifejezzem elismerésem.

- Maga álnok, képmutató disznó! - kiáltotta Processzor. - Tegye le azt a fegyvert, nem méltó rá, hogy viselje.

- Nem vagyok rá méltó? Mégis, hogy mondhat ilyet? Mindenki az én áramomat fogyasztja, mégis folyton panaszkodnak: "Nem lehetne még egy +12V csak nekem?" "Közös ágon vagyok a DVD olvasóval, ezt nem tűröm." Mégis lenéznek, tudomást sem vesznek rólam. Elegem van, hogy nem tekintenek igazi számítógép komponensnek. Processzor ezredes a megaherzekkel büszkélkedik. Alaplap az USB csatlakozók számával henceg. Fogadjunk, még a teljesítményemet sem ismerik. Ha pedig felmelegszem, annyi áramot adok másoknak, akkor meg a hűtőm zajával van bajuk.

- Ezért tette? Szeretne több figyelmet?

- Nem. Emlékeznek a tavalyi nagy túlmelegedésre? Amikor a hűtőpaszta annyira megszáradt, a házban 70 fok fölé ment a hőmérséklet.

Többen bólogattak.

- Akkor történt. Az egyik csatlakozóm pontosan Processzor fölött volt. Az összes meleg levegő ott keringett és megolvadt a csatlakozó műanyag vége. Azóta nem működök rendesen. Nem mertem szólni. Féltem, és összezavarodtam.

- Mutassa a sérült csatlakozót, kérem - mondta Poirot.

- Annyira sajnálom - mondta összetörten Tápegység. - Annyira sajnálom.

Leengedte a fegyvert, és hagyta, hogy a rendőrök elvezessék.

A rejtett Markov láncok nagyon hasonlóak a korábban bemutatott Markov láncokhoz, de van bennük egy csavar. Minden állapot bizonyos valószínűséggel emittál egy másik állapotot, amit látunk. Ezért az eredeti állapotot mi nem látjuk, tőlünk rejtve van, ezért hívják rejtett Markov láncoknak.

Például, ha azt vesszük, hogy egy (nagyon is leegyszerűsített) genomon egymást követik a fehérje kódoló, és nem kódoló szakaszok, akkor ez lehet egy rejtett állapot. Ezt mi nem látjuk (legalábbis a modell szerint, kísérleteket természetesen tervezhetünk a kimutatására). Amit látunk, az a DNS bázissorrend. Ha hétköznapi módon akarnék fogalmazni, a rejtett Markov lánc a közvetett bizonyítékok vizsgálatán alapul.

Gyakorati szempontból három algoritmust szoktak tárgyalni, ami a rejtett Markov láncok három alkalmazási módjával áll kapcsolatban. A Forward-Backward algoritmus, a Viterbi algoritmus és a Baum-Welch algoritmus.

Az első segítségével a modell paramétereit és megfigyelt állapotok kapcsolatát lehet számszerűsíteni, magyarul, mennyire jó a modellünk a megfigyelt adatokra. A Baum-Welch a látható állapotok alapján a modellünk paramétereit határozza meg.

A bioinformatikában általában a Viterbi algoritmust használják, mert ez mondja meg, hogy mi a legvalószínűbb rejtett állapot, ha ismerjük az emittált állapotokat. A példánknál maradva, hol vannak a kódoló/nem kódoló szakaszok, ha ismerjük a DNS bázissorrendjét.

A rejtett Markov láncokról rengeteget lehet olvasni a Wikipédián, én nem is akarom újra leírni azt. Amit viszont fontos megismerni, hogy mi a módszer gyengesége, mert a későbbi posztokban utalni fogok rá.

Ezért írtam egy kis programot, ami nem csinál mást, mint generál egy Markov láncot, és abból emittál bizonyos valószínűséggel egy másik állapotot. Ez most az időjárásos példa a Wikipédiából. Utána egy Viterbi algoritmussal visszafejti azt. Tehát egyszerre látjuk, miből indultunk ki, és mi lett a keresés eredménye.

Nyugodtam írjuk át a programban a valószínűségi értékeket, hogy lássuk, milyen hatással van az eredményekre. (Ha telepítve van a Go fordító, akkor a go build hmm.go paranccsal fordíthatjuk.)

Ha megnézünk egy tipikus kimenetet, akkor nem sok eltérést fogunk látni. Olyan esetekben lesz eltérés például, ha napos idő esetén is takarítanak. Mivel napos időben csak 0,1 a valószínűsége, hogy valaki takarít, ezért a Viterbi inkább az esős idő felé hajlik ilyen esetekben. Ez nem is meglepő, hiszen ez a legvalószínűbb állapot.

A másik fontos észrevétel, hogy az állapot átmeneteknél egyfajta "késés" van a valódi és a Viterbi által visszafejtett állapotok között. Igazából, ez sem meglepő, ha belegondolunk. Napos idő után nagy valószínűséggel megint napos lesz, esős után esős. Ha történik egy átmenet naposból esősbe (vagy vissza), akkor az algoritmus, ami csak az emittált állapotok alapján dolgozik, pár lépéssel később végzi el a váltást. (Persze ez is a valószínűségektől függ. Ha minden rejtett állapot csak egyfélét emittál, akkor ez a késés nem jelentkezik.)

És mi a helyzet a HMM profilokkal?

A bioinformatikában a rejtett Markov láncok alkalmazásának másik nagy területe a különböző profilok létrehozása, elsősorban fehérje alapon. Itt szó szerint rejtett állapotok vannak. Mit értek ez alatt? Az időjárásos példánál a rejtett állapot egy valódi entitás volt (maga az időjárás), csak nem szerezhettünk róla információt. A fehérje profiloknál viszont a rejtett állapot egy meg nem fogható jellemzője a fehérjének. Csupán egy absztakció, még akkor is, ha szoros kapcsolatban van az aminosav fehérjében betöltött pozíciójával. Amit mi látunk, tehát az emittált állapot, maga a fehérje aminosav sorrendje.

Most jön a trükk. Hogyan lesz ebből a megfoghatatlan valamiből profil? Hiszen nekünk ismernünk kell az emittált valószínűségeket. Úgy, hogy fogunk sok - valamilyen tulajdonság alapján hasonló - fehérjét és végzünk egy többszörös illesztést. Ha egy pozícóban csak glicin van, akkor az a rejtett állapot 100%-ban glicint emittál. Egy másik pozícióban azt látjuk, hogy néha alanin, néha fenilalanin van, akkor a modellben annak megfelelően állítjuk be a valószínűségeket, hogy a többszörö illesztésben hányszor fordul elő az adott aminosav.

Még a deléciók és inszerciók sem jelentenek problémát, hiszen azokat is felvehetjük rejtett állapotnak. Az inszerciók szintén emittálnak aminosavat, de a deléciók nem fognak semmit emittálni, a szerepük, hogy át tudjunk ugrani a következő állapotba.

Leegyszerűsítve, a többszörös illesztés oszlopai a rejtett állapotok, a sorok pedig az emittált állapotok. Itt az állapot átmeneteknek kisebb szerep jut. Képzeljünk el egy olyan többszörös illesztést, ahol nincsenek inszerciók, sem deléciók. Minden állapot 100%-ban átmegy a következő aminosavat emittáló állapotba. A profilban az igazi információt az emittálási valószínűségek fogják adni, mert abból derül ki, milyen aminosavat tartalmazhatnak az egyes pozíciók.

Talán ebből is látszik, hogy a rejtett Markov láncok rendkívül rugalmasan alkalmazhatóak. Nem véletlen, hogy szinte minden programozási nyelvhez adtak ki modulokat, amelyek segítségével rejtett Markoc láncokat kezelhetünk. Python alatt a hmmlearn csomagot érdemes használni, mert az közeli kapcsolatban van a sci-kit learn csomaggal. R alatt több lehetőségünk is van, az rHMM, a HMM és a depmixS4.

Habár előszeretettel hivatkoznak a DNS láncra, mint egy hosszú szalagra, ahol csak a nukleotidok sorrendje az egyedüli fontos ismertetőjegy, a valóságban a DNS egy komplex struktúra, ahol külön logisztikát igényel a sejttől, hogy ezt az információt valahogy tárolja.

A DNS ezért nem egy összekuszált fonalgombolyagra hasonlít, amivel három macska játszott, hanem egy kazettákban használt hang szalagra. Ezt kromatinnak hívják. Az előbbi analógia természetesen sántít, mert ha szükségünk van egy dalra, ami a szalag közepén van, folyton tekergetni kell a magnót, hogy mindig azt a részét halgathassuk, amelyiket akarjuk. Ezt az időveszteséget a sejt nem engedheti meg magának, neki úgy kell feltekernie a DNS-t, hogy közben elérhesse azokat a géneket, amelyekre szüksége van. Ezért a kromatin állapot folyton változik a sejt aktuális szükségleteinek megfelelően.

A kromatin még ennél is többet tud! A DNS különböző pontjain fellelhető információnak néha egy helyen és egy időben kell jelen lennie. Mintha a korábban említett kazettán a dalok hangszerei külön lennének felvéve, de lejátszásnál mégis egyszerre hallatszana minden. Ezért a génkifejeződés közben bonyolult térbeli struktúrák jönnek létre, amikor távoli DNS részek közel kerülnek egymáshoz. A Hi-C szekvenálás pontosan ezen struktúrák elemzésére szolgál.

A segítségével megállapítható, hogy egy adott gént milyen távoli enhanszerek szabályoznak. De előszeretettel használják kromoszóma összeépítésre is, mivel ezek a struktúrák általában egy kromoszómán belül jönnek létre és a távolságuk sokkal nagyobb is lehet, mint bármelyik harmadik generációs szekvenálás read hossza.

Először is kovalensen kötik a feltekeredett DNS darabok egymáshoz közeli részeit, ami olyan, mintha pillanatragasztóval fixálnák ezeket a kötéseket. Ezután egy restrikciós enzimmel levágják a hosszú DNS darabokat, amelyek ezekről a fixált részekről lelógnak. Az eredmény tehát egy nagy csomó lesz, amiről rövid DNS láncok lógnak le. Ezeket a szabad láncvégeket összekötik, majd a szekvenálják.

A bioinformatikai elemzés ebből a sajátos laboratóriumi előkészítésből adódóan nagyon eltér a többi második generációs szekvencia elemzésektől. Először is, a read párok távolsága nem követ normál eloszlást, emiatt nem is együtt illesztik őket, hanem mintha külön szekvenciák lennének. Másodsorban a genom adott pontján található read mélységnek nincs információ tartalma. Két genomi pozíció összekötésénél nem az számít, hogy hány read esik egy pontra, hanem hány ilyen pont van, ami megerősíti, hogy kapcsolat van két pozíció között.

Rengeteg program van, amivel feldolgozhatjuk adatainkat, én csak egyet mutatok be, ez pedig a Juicer. Azért ezt, mert erre a protokollra építkezve nem csak a szabályozó kapcsolatokat lehet elemezni, hanem egy genom-összeszerelő módszer is épül rá. Így egy eljárással két bioinformatikai módszert is ismertethetek.

A Juicer nem millió parancssori paraméterrel működik, hanem egy rögzített könyvtár struktúrával dolgozik. Ebbe a könyvátrba helyezzük a references alkönyvtárat a referencia genomokkal, a fastq-t értelem szerűen a fastq fájlokkal. Végezetül a scripts könyvtárba kell helyeznünk azokat a Juicer szkripteket, amelyekkel dolgozni akarunk. Ugyanis a fejlesztők minden platformhoz készítettek egy szkript halmazt, amit különböző alkönyvtárakba helyeztek el (nézzük csak meg a Github repójukat). Például ha csak egy gépen akarunk futtatni, akkor a CPU alkönyvtár szkriptjeit helyezzük el itt. (Vagy csak egy linket helyezünk el). Ez nem egy professzionális megoldás, főleg, ha azt nézzük, hogy már létezik Snakemake. Vitathatatlanul ez az egyik gyengesége a programnak.

Első lépésként a BWA-val indexelni kell a referencia szekvenciát. Ezt nem írom le, gondolom a könyökén jön ki mindenkinek, aki szekvencia feldolgozással foglalkozik.

Ha ezekkel megvagyunk, el kell készítenünk a restrikciós helyek térképét, amihez a Juicer misc alkönyvtárában találhatunk egy szkriptet.

python generate_site_positions.py enzimname reference.fa restrictionfile

Sajnos az enzim nevek a programba vannak égetve. Van HindIII, DpnII, MboI, Sau3AI, Arima. A referenciából kell még készítenünk egy kromoszóma méret táblázatot is, amit a samtools-al készíthetünk el, de csak az első két oszlopra van szükségünk.

samtools faidx reference.fa
cut -f 1,2 reference.fa.fai >reference.chrom.sizes

Ha mindezekkel megvagyunk, indíthatjuk a programot:

scripts/juicer.sh -D workdir -z reference.fa -y restrictionfile -p reference.chrom.sizes

Eredményül fogunk kapni egy .hic kiterjesztésű állományt. Minden további munka, ezzel a fájllal megy.

Rövid vizuális áttekintésre használhatjuk a Juicebox alkalmazást. Javaban írták, és hála a hic tömörített formátumának, akár egy erősebb laptopon is elfut, bár ne reméljünk eget rengető sebességet.

A Juicer egyik kimenetét használhatjuk genom összeszereléshez is, ha referenciának használjuk a scaffoldokat. Ehhez egy másik programra lesz szükségünk, a 3d-dna-ra. Telepíteni nem kell, csak ki kell bontani. A fent említett könyvtár struktúrában a Juicer hatására létrejön egy aligned könyvtár, amiben van egy merged_nodups.txt fájl. Gyakorlatilag erre és a scaffold fájlra van szükségünk. A program támogatja a diploid genom összeszerelést is.

./run-asm-pipeline.sh -m diploid reference.fa workdir/aligned/merged_nodups.txt

Az eredmény a reference.FINAL.fasta lesz.

Természetesen ritka, hogy egy kísérlet hibamentesen fusson. (Ha mégis így van, utóbb kiderül róla, hogy felesleges volt elvégezni.) Szükség van rá, hogy megtudjuk, melyik lépésnél keletkezett a hiba.

Ha az emésztés valamilyen okból nem volt sikeres, akkor azt látjuk, hogy a read párok elhelyezkedése közeli. Közeli alatt azt értem, hogy olyan, mintha egy közönséges DNS illesztés lenne, tehát a fragment távolságok normál eloszlást fognak mutatni.

Ha az emésztés sikerült, de a ligálásnál történt valami malőr, akkor az intrakromoszómális és interkromoszómális fragmentek aránya kisebb lesz. (Az érték egyébként humán vonatkozásban 80 szokott lenni.) Ezt az értéket a Juicer ki is számolja nekünk.

Ha megnézünk egy tipikus Hi-C ábrát, azt látjuk, hogy a főátlóban helyezkedik el a legtöbb fragment, a TAD-ok közelében. Amennyiben nem ilyen az ábra, kezdhetünk gyanakodni, hogy valami gubanc történt.

Felhasznált irodalom:

Bryan R. Lajoie, Job Dekker, Noam Kaplan: The Hitchhiker’s guide to Hi-C analysis: Practical guidelines

Az Experience mindig is egy laza levezetés szokott lenni a partik sorában. Mivel idén nem remekelt a scene, a levezetés is ehhez hasonlatos volt. Csak a legelvakultabbak vették a fáradságot, hogy valamit beadjanak, ezért inkább egyéni, mint csapatversenyt láttunk. Talán ezért is voltak az intrók felülreprezentálva.

Kezdjük mindjárt az első helyezettel, az Ugyanaz mindennel. Számomra nem volt tiszta, hogy mi az, amit ugyanaz. Talán az effektek, amelyeket láttunk már néhány Fresh!Mindworkz produkcióban? Ki tudja? Klasszikus demó annak minden előnyével és hátrányával.

A második Trixy volt, egy 256 byte intró Abaddontól. Ez egy nagyon kedves intró, jó ötlettel, kiváló kóddal. Ez egy igen stílusos búcsúzás az évtől, mert nem túl bonyolult, mégis magával ragadó.

Tifeco ismét egy Demojoe intróval örvendeztette meg a nézőket. Mivel a sztoris alkotásokat előnybe részesítem, ezért majdnem ezt tettem volna meg győztesnek. Az egyetlen hibája talán a nosztalgikus húrok megpedndítése, mert ettől számomra hatásvadásznak tűnik. A scenerek ilyen szempontból olyanok, mint az Oscar-bizottság, akik imádják a filmekről szóló filmeket. Az intró kulisszatitkairól egyébként nemrég irás is megjelent.

Az utolsó helyezett új értelmet ad a "valós idejű animációkan". Egy naplementét láthatunk nagyjából olyan lassan, mintha tényleg a Föld forgását szimulálná. Az egyetlen mentsége, hogy 256 byte intró. A streamen Charlie azt mondta, hogy szerinte remekül összegez mindent 2020 demóiról. Kicsit borulátó megállapítás, de nehéz belekötni.

Nemrég volt egy elég sajnálatos incidens, aminek következtében gyakorlatilag egy hátsó ajtót találtunk a tárhelyünkön.

Az egyik számítógépünkhöz egy külső tárhely van csatlakoztatva. Elsőre elég jó cuccnak tűnt, weben keresztül lehet konfigurálni még a raid blokkokat is. Újraindítás nélkül rendezhetjük csoportokba a vinyókat, sőt, még a hardver hibákat helyét is megmutatja egy képen. Tényleg szuper.

Össze volt kötve a számítógéppel, amin dolgozunk, ezen kívül egy másik számítógéppel, hogy azon keresztül adminisztráljuk, és az internettel, hogy adatokat osszunk meg a kooperációs partnerekkel, ha éppen arra van szükségünk. Én mindig a neten keresztül adminisztráltam, a másik számítógéppel nem sokat foglalkoztam. Az idők során meg is feledkeztem róla.

Egyik nap a főnököm felhívott, hogy "támadják a NAS-t". Minden munkát eldobtam, azonnal beléptem az admin felületre és próbáltam kitalálni, mit tegyek, hogy visszaverjem a támadást. Ilyen szempontból elég kevés eszköz volt, például azt sem láttam, ki kapcsolódik a szerverez. Mivel statikus IP címe volt a tárhelynek, a nagy agyammal kitaláltam, hogy dinamikus IP-t adok neki, mert akkor nem fogják tudni, hol van, ergo nem fogják "támadni".

Be is állítottam. Egy kis számláló mutatta, hol áll a konfigurálás, én meg közben azon gondolkodtam, ha a tárhely dinamikus címet kap, hogyan fogok belépni az admin felületre? Amint rájöttem, hogy hülyeséget csináltam, a képernyő villant egyet, ahogy a böngésző frissítette az oldalt, és a tárhely webes admin felülete eltűnt. De legalább nem támadják - gondoltam.

Utána jött a hír, hogy igazából nem támadta senki a gépet, csupán az rendszeresen felkeresett egy gyanús IP címet, ami a rendszergazdák szerint egy ismert malware update cím. Tehát valaki belépett a tárhely operendszerére és ott futtatott valamit, amit nem kellett volna. Tehát az akciómnak semmi értelme nem volt, mert továbbra is fut rajta a malware. Oké, már csak meg kellene találnom a gépet, mert fene tudja milyen címen van.

Jobb híján az nmap-el fésültem át tartományokat, olyan gépre vadászva, aminek a 8816-os portján egy webszerver üzemel. Aztán eszembe jutott, hogy egy másik gépbe is bekötötték a tárhely egy portját, ráadásul közvetlenül, így teljesen mindegy milyen dinamikus IP-t kapott, a fenti gépen keresztül is el tudom érni.

Elértem, visszaállítottam az eredeti konfigurációt. Szuper, az első ellenséggel, önmagammal leszámoltam. Visszaállítottam a statikus IP címet, kikapcsoltam minden felesleges szolgáltatást, de a tárhely CPU használata szükségtelenül magas volt. A rendszergazdák megerősítették, hogy a gyanús IP-t továbbra is felkeresi. A malware tehát még mindig futott.

Kicsit körbeszaglásztam én is a NAS-t, és láttam, hogy a 22-es port nyitva van. Belépni viszont nem tudtam egyetlen általam ismert jelszóval sem. Arra gondoltam, biztos az SFTP miatt van nyitva. Hiába állítottam le azonban az SFTP szolgáltatást, a 22-es port továbbra is nyitva volt.

Végül nem tudtam mást tenni, mint a gyártó honlapjáról leszedtem az összes elérhető dokumentációt (az egyik 500 oldalas volt), majd frissítettem a firmware-t. A firmware egy 1.7GB-os fájl volt, érzésem szerint a NAS teljes operációs rendszere egy képfájlban, de a formátumára nem jöttem rá.

A firmware frissítés megoldotta a problémát. A CPU használat visszaesett egy 0 közeli értékre, de az SSH port problémáját nem oldotta meg. Márpedig jó eséllyel ott jöttek be a támadók, ezért szerettem volna lezárni.

Közben, csak kíváncsiságból csináltam egy tracerout-ot a kérdéses IP címre az egyik szerverünkről, mire fél órán belül mindenki tiszta ideg lett, mert azt hitték, hogy az a gép is megfertőződött a malware-el. Ahogy Dumbledore is megmondta:

Eltelt pár nap, és én azt hittem, a problémán túl vagyunk, mert a NAS más nem kereste fel a gyanús IP-t, de a rendszergazdák ismét felvették velem a kapcsolatot, mert biztosak akartak lenni, hogy minden rendben van a tárhellyel, és ez az eset nem fog megismétlődni. Igen, kérem, ilyen is van, hogy komolyan veszik a biztonságot. Ők is átnézték a NAS-t, de csak annyit javasoltak, hogy változtassam meg az admin jelszót egy hosszabbra, amit meg is tettem.

Igen ám, de ők is kiszúrták a nyitott 22-es portot. Szerették volna, ha bezárom. Mondtam, hogy nem tudom bezárni, mert az admin felületen nincs rá mód, a jelszót meg nem tudom, hogy parancssorral belépjek és ott oldjam meg a problémát. Átnéztem újra minden dokumentációt, de egy árva szó sem volt ssh-ról benne. Kipróbáltam az általam ismert jelszavakat, de egyikkel sem engedett be.

Kis idő múlva felhívtak, hogy be lehet ssh-zni rootként, ha az 111111 jelszót használják. Hoppá! Kipróbáltam, de szerencsére nem volt ennyire rossz a helyzet, bár már ettől is kirázott a hideg. A jelszó megadása után ugyanis kaptunk egy random 6 karaktert (minden bejelentkezésnél mást), majd egy újabb jelszót kért. Szerintem valami egyszer használatos jelszó mechanizmus lehet.

Ismét átnéztem a dokumentációkat, az internetet, de semmit nem találtam erre vonatkozóan. Végül írtam a NAS gyártójának, hogy ez elég gáz, meg kellene oldani ezt a problémát. Azt válaszolták, hogy ezt az ő R&D csapatuk használja, és nem kell aggódni miatta.

Végül is miért kellene aggódnom? Van egy hátsó ajtó a NAS szerverünkön, amit tud használni a gyártó, tudnak használni fekete kalapos hekkerek, de mi, az üzemeltetők nem. Mintha vennénk egy autót, aminek a csomagtartójába a gyár munkatársai időnként bemásznának, hogy ott kutatás-fejlesztést végezzenek.

Végül leszedtük az internetről a NAS-t. Mostantól nem lesz "cloud" opció, nem lesz adat megosztás kooperációs partnerekkel, de nem lesz titkos nyulka-piszka sem a gyártó R&D csapatától.

Ahogy a konferenciák legtöbbje, úgy a Magyar Bioinformatikai Társaság éves konferenciája is on-line került megrendezésre. Ennek egyik vitathatatlan előnye volt, hogy több külföldön dolgozó magyar kutató is beszélhetett munkájáról. Hátránya pedig (az ingyen kaja hiányán kívül) az informális beszélgetések nélkülözése volt. Nézzük is át, manapság az egyes kutatócsoportokat milyen kihívások foglalkoztatják. A konferencia anyaga itt található.

Korcsmáros Tamás: Hogyan hat a sejtjeinkre a SARS-CoV-2 fertőzés? Hálózatbiológiai vizsgálatok és lehetőségek

A SARS-CoV-2 vírus a fertőzés során egy úgynevezett citokin-vihart okoz, amelynek pontos megértéséhez a jelátviteli mechanizmusok feltérképezése szükséges. A csoport ezen a téren már elég tapasztalatot gyűjtött össze, ezért ezen az úton indultak el. A ViralLink segítségével elemezhető, hogyan hat a vírus mRNS a gazdasejtre. A program számára létfontosságú adatokat az irodalomból szedték össze. Egy másik program, a CytokineLink a sejtek közötti citkokin alapú kommunikációt vette górcső alá. Itt a protein atlaszból megállapították mely sejtek melyik citokin molekulát expresszálják, majd meghatározták a target sejtet az alapján, hogy milyen receptor van a felszínükön. Ezeket az adatokat felhasználva metahálózatokat hoztak létre, ahol szövet-szövet és citokin-citokin kapcsolatok szerepelnek. Az előadás végén a bélrendszeren keresztüli fertőzésről volt szó, ami a vizsgálatok alapján súlyosabb kórlefolyást eredményez.

Manczinger Máté: A kevesebb néha több, avagy miért hátrányosak a generalista HLA molekulák a tumorellenes immunválaszban?

Az adaptív immunválasz során a HLA antigének peptidkötő képessége széles skálán mozog. Amennyiben többféle antigént is képes bemutatni a T-sejtnek, az előnyös egy vírusfertőzés során, mert nagyobb védettséget ad az egyénnek. De mi a helyzet a tumorok esetén? A csoport eredményei szerint a promiszkuózus antigén prezentáló sejt rosszabb immunválaszt vált ki, mert kevés a különbség az egészséges sejtekhez képest. Végeztek RNS szekvenálást is, ahol az alacsony és magas promiszkuitású mintákat hasonlítottak össze. Az eredményül kapott gének GO elemzése T-sejt szabályozással összefüggő géneket írt le.

Makai Szabolcs: Hi-C adatok felhasználásának lehetőségei a genom térbeli szerkezetének leírására az árpa példáján keresztül

A Hi-C adatok a genom különböző pontjai között található kapcsolatokat tárják fel. Gráfelméleti módszerekkel ezek a kapcsolatok vizsgálhatóak. Egy egyszerű, a rugó viselkedésének leírására használt fizikai modellel a kromatin kompartmentek is jellemezhetőek. Az interkromoszómális kapcsolatok modellezésével viszont egy lineáris struktúrát kaptak, amiről az előadónak egy ingasor jutott az eszébe, és ez alapján úgy véli, a működése is hasonló lehet.

Nagy Gergely: A makrofágokat meghatározó transzkripciós faktorok együttműködésének vizsgálata

Nagy mennyiségű chip-seq adatatot elemeztek, és cisztrómokat együttállását vizsgáltak makrofágokban. Sok eredményük már jól ismert irodalmi adatot adott vissza, de az NFE2L2 a MAF-okon kívül más fehérjékkel is tud heterodimert alkotni és cAMP válaszadó elemeket is megköthetnek.

Dankó Benedek: Abnormális transzkripciós mintázatok vizsgálata nagy mennyiségű RNS-szekvenálási adat segítségével mielodiszplasztikus szindrómában

A mielodiszplasztikus szindróma kialakulásában splicing faktor mutációk játszanak szerepet, ezért RNA-seq adatokból olyan splice variánsokat kerestek, amelyek eltérnek a normál szövetektől. Callistot és Salmont használtak az abundancia meghatározására és Iso-kTSP-el nézték az alternatív splice variánsokat. Az előadás fő üzenete az volt, hogy az alkalmazott programok használatától függően eltérő eredményeket kaphatunk.

Kálmán Zsófia: Betegséget okozó mutációk hatásának vizsgálata a coiled-coil szerkezetekre

A coiled-coil moduláris távtartók, állvány fehérjék. A vizsgálatok során az Uniprotból leszedték a fehérje szekvenciákat, a Humsavarból pedig a betegségeket okozó mutációkat. A coiled-coil mutációk többségében idegrendszeri betegségekben fordulnak elő, valamint az erre a régióra eső mutációk kisebb mértékben destabilizáló hatásúak. Ha mégis destabilizáló a hatás, akkor a mutáció a hidrofób magot érinti. Ezen kívül az N terminális régióban található mutációknak kiemelt szerepe van.

Olar Alex: Rheumatoid arthritis betegség automatikus, ízület alapú pontozása röntgen felvételek alapján

A kutatás témája egy Dream challenge-ből indult ki. Az izületi elváltozásokat egy pontozó rendszerrel jellemzik az orvosok, de mivel a kéz minden egyes izületére meg kellene határozni, a gyakorlatban csak nagyon ritkán használják. A versenyben pont az volt a cél, hogy egy algoritmusnak megtanítsák ezt. Először egy neurális hálót használtak az izületek röntgen felvételeken történő azonosítására, majd 12 másikat a predikcióra. A 12 eredményt pedig egy random forest klasszifikációval fűzték egybe.

Radványi Ádám: A standard genetikai kód és kodonmintázatok viszonyának elemzése környezeti adatok fényében: mezofil optimalitás és mutációs trendek

Miért csak egyféle genetikai kód van? A kérdés azért is fontos, mert rajta keresztül az élet eredetére is keressük a válaszokat. Az eddigi vizsgálatok sorra azt állapították meg, hogy az ok abban keresendő, hogy ezzel a kóddal lehet a hibákat minimalizálni. De a kodon használat nem egyenletes a különböző élőlénycsoportok között, mint ahogy ezek a vizsgálatok feltételezik. Ezért ebben a vizsgálatban azt nézték, hogy a kodon használat esetleges hibái hogyan hatnak különböző környezeti feltételek esetén. Azt találták, hogy az extrém magas hőmérsékleten élők esetén egy pontmutáció hatása sokkal súlyosabb. Ezért a genetikai kód valószínűleg a mezofil hőmérsékletű élőlényekre optimális, innen eredhet.

Pajkos Mátyás: Rákbetegségekben mutálódott rendezetlen régiók evolúciós vizsgálata

Az előadás címével ellentétben nem a tumoros megbetegedésekről szól. Az evolúciós vizsgálatokhoz a nagy számú fehérjét valamilyen logika szerint szűrni kellett, ezért csak a tumorokban szerepet játszó fehérjékre korlátozták azt. Megállapították, hogy ezen fehérjék a vizsgálatok szerint ősi eredetűek, a rendezetlen régiók konzerváltak.

Udvarnoki Zoltán: Onkogenetikai elemzések magyar mintákra

A csoport magyar minták onkogenomikai elemzését végzi. A szekvenálástól a szomatikus mutációk annotálásáig minden lépést elvégeznek, az eredményeket pedig egy webszerveren teszik közzé. Az előadás a cBioPortal bemutatásával folytatódott.

Becsei Ágnes: A levegő-metagenomika szerepe a kórokozók monitorozásában

Az előadás egy nagyon nehéz módszert, a levegő metagenomikát igyekezett bemutatni. A nehézséget mi sem bizonyítja jobban, minthogy a csoport nem talált koherens eredményt. Nem találtak plazmidokat, nem találtak horizontális géntranszferre utaló jeleket. Amit találtak, az is erősen szórt.

Farkas Bianka: A CFTR NBD1 mechanikai letekeredésének jellemzése számításos és kísérletimódszerek felhasználásával

A cisztás fibrózis a CFTR génben bekövetkezett mutációra vezethető vissza, aminek van rendezetlen része is. Az általuk vizsgált mutáció hatására a fehérje tekeredése változik meg, amit molekula dinamikai számításokkal vizsgáltak. Eredményeik alapján a leválási időpont változik meg. A hibásan működő domain pontenciális gyógyszercélpont lehet.

Börzsei Rita: A somatostatin 4-es receptor és az endogén ligandum-komplex szerkezetének előállítása

A somatostatis egy neurotranszmitter, ha a receptora hibás, az számos pszichiátriai betegség oka lehet. A vizsgálatban az sst4 receptor és a somatostatin kapcsolódását vizsgálták. Mivel a receptor szerkezete nem ismert, ezért homológ fehérjék alapján próbálták meg felépíteni azt. A dokkolást így sem tudták elvégezni, mert a szerkezet túl nagy volt a szimulációk futtatásához. Ezért az irodalmi adatok alapján a szerkezetnek csak azon részét használták, ami a dokkolásban ténylegesen részt vesz. Eredményeik alapján új somatostatin analógot tudnak fejleszteni, ami gyógyszerként is lehet alkalmazni.

Zsidó Balázs: A TRPA1 receptor ligandumokkal alkotott komplexeinek számítógépes vizsgálata

Az előadás némi átfedést mutat az előzővel, itt is receptor és ligand közötti dokkolást végeztek, de ez egy úgynevezett "szárazdokkolás" volt, "szemiempirikus" paraméter beállítással. Talán emiatt lehetett, hogy a kötési szabadenergiák az irodalomban fellelhető értékeknél 3-4-szer alacsonyabbak voltak.

Csizmadia Georgina: MemMoRF: Lipid kettősréteghez kötődő rendezetlen fehérjerégiók adatbázisa

A lipid kettős réteg és a rendezetlen fehérjék kapcsolatát nehéz vizsgálni, mivel a membrán környezet megnehezíti a vizsgálatokat. Ezért létrehoztak egy adatbázist, ahol az elérhető NMR adatokat felhasználva flexibilitást számoltak és meghatározták milyen másodlagos szerkezetet vehetnek fel a membránhoz kötött rendezetlen fehérjék. Az adatbázis megközelítőleg 500 bejegyzést tartalmaz, és itt érhető el.

Liska Orsolya: TFLink, egy átfogó transzkripciós faktor - target gén adatbázis

Bár már vannak transzkripciós faktor és target gén adatbázisok, ezek nem egységesek, általában csak egy fajra készülnek el. A TFLink egy helyre gyűjti ezeket a több forrásból származó adatokat, és csak kísérletesen igazolt eredmények vannak benne.

Miczi Márió: In silico módszerek alkalmazása a SARS-CoV-2 koronavírus fő proteáz (3CLpro) gazdasejt szubsztrátjainak azonosítására

A vírus proteázok interakcióba lépnek a gazdasejt proteómjával. A vizsgálat célja a 3CLpro proteáz humán célpontjainak meghatározása. Mivel erről a proteázról kevés információ van, ezért Blast segítségével homológokat kerestek és azok segítségével határozták meg a potenciális célpontot. A NetCorona webszerverrel pedig a hasítások helyét állapították meg. Az eredményeket in-vitro validálták, de sok esetben más eredményt kaptak. Vagy nem volt hasítás, vagy máshol volt, mint ahogy a predikció jósolta.

Palla Gergely: Metilációs hálózatok hierarchikus és kontroll tulajdonságai

A DNS metiláció szintjével jól lehet jellemezni az öregedést. Ezen alapul az úgynevezett Horvath-féle óra is, ami egy az ismert epigenetikai órák közül. Ezért ez a vizsgálat arra irányult, hogy a CpG metiláció szabályozásának hálózatát térképezzék fel. Erre egy regularizált Lasso-regressziót használtak, ahol akkor hoztak létre éleket a gráfban, ha ez a regressziós érték nullánál nagyobb volt. Az így elkészült hálózat hierarchikus volt, ahol a hierarchia tetején olyan gének szerepeltek, amelyek jobban beleszólnak az öregedés szabályozásába, mint a hierarchia alján lévők.

Kerepesi Csaba: Egér öregedés és megfiatalodás mérése epigenetikai órákkal

Az előadás több ponton is kapcsolódik az előző témához. Itt is az epigenetikai életkorral összefüggő vizsgálatok történtek, de jóval gyakorlatiasabb módon. A csíravonal sejteknek van egy olyan állapota, amikor "megfiatalodnak", vagyis a metilációjuk a fiatal sejtek állapotára hasonlít. A csoport egy olyan gépi tanuláson alapuló epigenetikai órát fejlesztett ki, ami nem csak az életkort becslüli meg nagy pontossággal, hanem az egyes életkor befolyásoló kezelések hatását is.

Fiser András: Aminosav alapú farmakofór módszer fehérje kölcsönhatások vizsgálatára

Ahogy a korábbi előadásokban is láthattuk, a fehérje kölcsönhatásokat dokkolással szokták vizsgálni. A dokkolás ismert kapcsolódásokon alapul és egyszerűsítéseket tartalmaz. A csoport kifejlesztette a ProtLID módszert, ami kiküszöböli a fenti limitációkat, cserébe nem az egész fehérjét, mint egységet nézi, csupán az aminosavakat. A szimuláció lényege, hogy a fehérjéből csak azokat az aminosavakat vizsgálja, amelyek potenciálisan részt vesznek a kötésben. A módszer az antigén-receptor kötéseket jobban képes leírni, mint a hagyományos dokkolás alapú módszerek.

Albert István: Bioinformatika és Egyéb Problémák

Az előadás azt mutatta meg, hogyan akadt az előadó egy bioinformatikai elemzés hibájára, amit úgy jellemzett "nekem egy órába telt, másnak talán több időbe". A probléma az volt, hogy az RNS szekvenálás irányított volt, de a Galaxy-ban rosszul klikkeltek egy paraméterre, amitől a readek irányát fordítva vizsgálták. Ettől két gén abundanciáját rosszul határozták meg, amelyek átfedtek, de ellenkező szálon voltak. A megoldást az adta, hogy az IGV-ben be kell állítani, hogy színezze be a readeket orientáció szerint. Ezután még olyan jótanácsot is hallhattunk, hogy a jó bioinformatikus tudja, mit jelentenek a paraméterek, amelyeket beállít a programokban.

Toth Adrienn előadását sajnos nem tudtam végignézni, ezért arról nem írok összefoglalót.

Amikor a számítógépeket használjuk, hajlamosak vagyunk (na, jó, hajlamos vagyok) azt hinni, hogy a kiszámított értékek teljességgel pontosak. A valóság viszont az, hogy csak egy közelítést adnak. Alkalmanként nem is olyan közelit.

Már eddig láttam jeleket, hogy a számítógépek máshogy viszonyulnak a számokhoz. Ha megnéz az ember egy 256b Mandelbrot fraktál zoomert, akkor előbb-utóbb azt tapasztalja, hogy a lebegőpontos számításhoz használt értékek elérik végső határukat, nevezetesen a fraktál egy színű lesz. De nem kell egy demoscene rendezvényre elmenni, hogy mindezt lássuk. A Python híresen rosszul kezeli a lebegőpontos számokat. Próbáljuk csak ki az interaktív konzolba beírva:

>>> 6.89 + 0.1
6.989999999999999

Az egyik legutóbbi feladatomnál Fisher tesztet kellett végeznem, viszonylag nagy számokra. A kontingencia táblázatban alkalmanként 200 milliós érték is lehetett! Az elvégzendő tesztek száma pedig olyan nagy volt, hogy nem akartam R-el vesződni. Igen, kicsit sok adat gyűlt össze. A teszt végeredményének kiszámításához faktoriálisokat kellett használni, és itt kezdődtek a problémák.

Ha csak a naív módszert használjuk, hamar rájövünk, hogy a 64 bites lebegőpontos számokkal 142-nél nagyobb faktoriálist nem lehet kiszámítani. Ráadásul a Fisher tesztben nem egy faktoriális szerepel, hanem faktoriálisok szorzata! Ezért a régi, jól bevált módszerhez folyamodtam: Nem szoroztam, hanem az értékek logaritmusát adtam össze. Mindjárt elég volt a hely, hogy akár 200 milliónak is kiszámítsam a faktoriálisát.

Ezzel viszont a pontosság rovására mentem. Ha megnéztem, milyen eredményt ad ki az R, akkor a nagyságrend stimmelt, viszont az értékek köszönő viszonyban sem voltak. A sebesség is gyatra volt. Egy teszt kiszámítása  kb. 4 másodpercet vett igénybe. Az összes teszthez két hónapra lett volna szükségem!

Lassú és rossz. Ezt a kombinációt akartam elkerülni. De mit lehet tenni ilyen esetben? Tisztázni kell a célokat. Igazából nem muszály manuálisan kiszámítani a faktoriálisokat, van egy közelítő eljárás, a Strigling módszer. Nem ad pontos eredményt, de nagyon gyorsan adja vissza. Egy gyors összehasonlítás a korrekten kiszámított értékekkel azt mutatja, hogy már alacsony értékeknél is lehet eltérés.

Egy közelítő értékeket használó statisztikai teszt, ami gyors és rossz. Lehet ebből jó eredmény? A válasz az, hogy igen. Ugyanis nekem azt kell eldönteni, hogy az asszociáció létezik-e két jelenség között. Tulajdonképpen nem számít, hogy ez az érték 3,4e-14, vagy 5,6e-12, amíg ebben a nagyságrendben mozognak. Ezt viszont a közelítő értékekkel is meg tudom állapítani.

Azért annyit változtattam a faktoriális kiszámító eljárásomon, hogy ha 10-nél kisebb számot adok meg neki, azonnal visszaad egy előre tárolt értéket. Ha 10 és 120 közötti az érték, akkor pontosan kiszámítja (ha eltekintünk a kerekítési hibáktól), és csak ennél magasabb érték esetén használja a közelítő formulát.

A program olyan gyors lett, hogy a másodperc tört része alatt megkaptam az összes eredményt. (Utána jutott eszembe, hogy elég lenne a legnagyobb szükséges értékre kiszámítani a faktoriálist és az összes köztes értéket tárolni egy tömbben, az gyors is lenne és pontos is.)

Ettől függetlenül látható, hogy a számítás módja meghatározza az eredményeket. Ez nem csak nálam érhető tetten, a nagy cégek által írt programoknál is fontos. Ha megfeledkezünk az Excelről, akkor is marad elég példa. Sőt, ahogy változik egy API verziószáma, úgy áttérhetnek más számítási módszerre is. Érdemes résen lenni, és sűrűn olvasni a dokumentációt.

Azért elgondolkodtató, hogy mennyire ismerhetjük meg a valóságot. Hiszen nem csak a számítás torzításán keresztül látjuk a világot, hanem azt is el kell dönteni, milyen torzítást használjunk. De biztosan tudom a kiválasztott módszer összes hátrányát? Nem lehet, hogy további meglepetések várnak rám, csak a megértésem még nem jutott el arra a szintre?

Az én példámnál maradvan, nem a Stirling az egyetlen közelítő eljárás. Választhattam volna mást is, amely más tulajdonságokkal bír. Ez még csak a faktoriálist. Erre épül a Fisher tesztem, ami ha egyszerűsítést nem is, kerekítési hibákat tartalmazhat.

Mi a jobb? Megállni biztos távolságra az ismeretlentől, és kijelenteni: eddig a pontig mindent ellenőriztem, amit itt találtam, az megbízható. Esetleg a hiányosságok ellenére is tovább menni, és remélni, hogy amit látok, az egy új eredmény, nem pedig a szemüvegem torzításának a felnagyítása?

A rövid válasz a fenti kérdésre, hogy mindkettő. Twitteren, blogokon, szakmai fórumokon rendszeresen felbukkannak hasonló kérdések (a leghíresebb talán a Python vs R vita), ahol rendre megjelennek olyan írások, hogy egyik vagy másik programozási nyelv felsőrendűbb a másiknál.

Nekem ezekre a vitákra egyetlen válaszom van: egy profi nem engedheti meg magának, hogy csak egyetlen eszközt ismerjen. A hátukgombolósok meg csak vitázzanak.

A jó kérdés inkább az, hogy mikor érdemes használni egyik vagy másik nyelvet? Mert ez nem mindegy.

Még nem vagyok egyik nyelv mestere sem, hiszen pár hónapja vetettem bele magam a tanulásukba, de azért kezd kirajzolódni egy kép bennem, hogy mely területeken lesz érdemes használnom ezeket.

Közös a két nyelvben, hogy az implementációk nem csak a fordító programot tartalmazzák, hanem a függőségek kezelését is. Más nyelvekben ez külön program szokott lenni. Például a Maven a Javahoz. A másik, hogy a fordító több feladatot vesz át a kód ellenőrzésből.

Természetesen különbségek is vannak. Kezdjük a Rust-al. A Rust egy második C akar lenni, ezért mindenhol, ahol korábban C-t használtunk, használhatunk Rust-ot. A nyelv megtanulása nem egyszerű, bár az is lehet, hogy én kötődök a hibás sémákhoz, amelyek értelem szerűen nem megengedettek Rust alatt. A kód fordításáért nekem meg kell szenvedni.

A C-vel való kompatibilitásnak ára is van, ezért lehetőséget adnak a fejlesztőnek arra, hogy "nem biztonságos" kódot is írjunk. (Bár szerény véleményem ez a biztonságos kódírásról. Még akkor is, ha elég sokszor lábon lőttem már magam)

Minden esetre, ha elsajátítottuk a nyelvet, könnyedén át tudunk térni Rust-ra, fokozatosan átírva egy projektet. Hangsúlyozom, miután elsajátítottuk. A tanulás hosszú időt vesz igénybe, később fogunk csak örülni az eredménynek. Még a nagy projektek is most vizsgálják, mennyire képes leváltani a nyelv akár a C++-t is.

Ezért a Rust például alkalmas lehet demók írására, mert van OpenGL könyvtár, van idő kísérletezni és jó, ha a végeredmény nem fagy le, mert nem figyeltünk eléggé az erőforrások felszabadítására.

A Go ezzel szemben nem törekszik arra, hogy a mindenség egyetemes nyelve legyen. A Google Cloud nyelvként definiálja, ami nem tudom, mit akar jelenteni. Amit tudok, hogy a Rustnál gyorsabban megtanulható, mert a nyelvi szintaxis egyszerűbb. Támogatja a többszálú feladat végrehajtást, amit remekül ki lehet használni a mai többmagos gépeknél, a fordítás után kapott bináris pedig statikusan linkelt. Ez utóbbi miatt könnyebben lehet horozni a binárist különböző Linux disztribúciók között.

A könyvtárak száma ezzel szemben limitált. Véleményem szerint soha nem fogunk Go alatt grafikus felületű programokat fejleszteni. Ha megnézzük az elérhető könyvtárakat ilyesmiket találunk: hálózatok, titkosítási eljárások.

Ezek a tulajdonságokat remekül lehet bioinformatikai programok fejlesztésére használni. Mire van legtöbbször szükség? Konzolos alkalmazásokra, amelyek beolvasnak egy fájlt és létrehoznak egy másikat. Esetleg adatokat kell letölteni az internetről. Sokszor kell nagy mennyiségű adatot feldolgozni, amihez elengedhetetlen, hogy több processzor magot is használjunk. A Go pedig mindezt tudja.

A TV adás nálunk egy Horizon médiaboxon keresztül érkezik. Sokáig nem is foglalkoztam vele, mert nálunk a TV-zés kimerül a napi Mancs Őrjárat megtekintésben. Néha vannak különleges napok, amikor iszonyat töménységben adnak le részeket, és ezek megtekintése még a legnagyobb rajongóknak is komoly megterhelést jelent, szegény szüleikről nem is beszélve.

Szerencsére a médiaboxhoz lehet vinyót csatlakoztatni USB-n keresztül, és fel lehet venni a részeket. Elkezdett érdekelni, vajon a felvett tartalmakat át tudom-e rakni számítógépre, és ott le tudom-e játszani. Abból indultam ki, hogy a doboz gyártói bizonyára nem kezdtek el saját formátumokat kitalálni, hanem meglévő komponensekből építkeztek.

Először a netet túrtam fel, de csak a szolgáltató felületes leírásai jöttek fel találatként. Talán senkit nem foglalkoztat a probléma?

A vinyót egy Linuxos laptophoz csatlakoztattam és sikerült megnézni a fájlrendszert. Ahogy elsőre számítottam rá, érthetetlen könyvtárnevek és ismeretlen fájl kiterjesztéseket találtam. Amin először meglepődtem, hogy a vinyón ext4 fájlrendszer volt, holott a leírások FAT32-t kérnek. Nocsak, nocsak. Bizonyára ezzel a primitív trükkökkel akarták megakadályozni a Windowson szocializálódott embereket, hogy TV műsorokat lopjanak.

Az első érdekes fájl a recordings volt. Linux alatt van egy file nevű parancs, amivel elég sok fájl típusát meg lehet mondani. De ennél egy közönséges less is elégnek bizonyult, ha nem ijedünk meg az ASCII karakterek tengerétől. A fájl ugyanis egy SQLite 3 adatbázis!

Ezt könnyedén be lehet olvasni, ha rendelkezünk a megfelelő adatbázis kezelővel:

sqlite3 recordings

Ebben az adatbázis kezelőben a .tables paranccsal kilistázhatjuk a táblákat. A felvételek a nagyon beszédes nevű recordings táblában vannak. A szerkezetét is megnézhetjük:

.scema recordings

Bár elég sok ismeretlen elemet láthatunk, rövid nézelődés után találhatunk egy path mezőt, ami alapján megtalálhatjuk a videó fájlokat. Persze a semmitmondó könyvtárakban úgyis a legnagyobb fájl tartalmazza a videókat, de ha specifikusan keresünk valamit, akkor az adatbázisból könnyedén ki lehet keresni a megfelelő felvételt.

Ezután jött a nagy kérdés, hogy micsoda a .rec kiterjesztésű fájl? Sem a less, sem a file parancs nem tudott érdemi választ adni. Elkezdtem bújni a netet, hátha találok valami érdekeset. Amitől nagyon féltem, hogy valami ostoba titkosítást fognak használni, ami lehetetlenné teszi, hogy használni lehessen a felvételeket.

Annyit sikerült találnom, hogy ez egy Toppy formátum, de ami felcsillantotta a reményt, hogy a VLC lejátsza. Akkor talán az MPlayer is!

Kis is választottam egy tetszőleges fájlt, de nem jelentek meg a kutyik, csak színes négyzetek villództak, mint a hibás MPEG2 videók esetén. Elkezdtem ismét a netet bújni, amikor a feleségem megkérdezte, mit csinálok. Neki is megmutattam a lépéseket, de a videó fájl kiválasztásánál egy másik példát választottam.

Megdöbbenésemre megjelent a mese! Hmm. Mint kiderült, két-három esetben valami miatt nem sikerült a felvétel, és nem lehetett visszajátszani. Többségében viszont az Mplayer (VLC is) zokszó nélkül lejátsza azokat.

Az ext4 fájlrendszer és az SQLite3 arra utal, hogy ebben a médiaboxban egy Linux dorombol. Vagy fene tudja, milyen hangot adnak ki a pingvinek.

2020 sok új szót hozott nekünk: nyunyóka, Mortran, QAnon. Mi? Ti nem tudjátok, mi az a Mortran? Akkor azt sem tudjátok, hogyan dolgozik egy igazi Nobel-díjas? Elmagyarázom.

Először is, meg kell szerezni a Nobel-díjat. Miből? Teljesen mindegy. A díj megszerzése ugyanis autómatikusan feljogosít arra, hogy az illető mindenhez értsen. Ehhez adjunk hozzá egy világjárványt, amihez egyéként is mindenki ért. A kettő együtt már jó alap arra, hogy bármilyen hülyeséget is mondjunk, arra mindenki figyelni fog. Újságok írják meg, miniszterelnökökkel találkozhatunk, akiknek személyesen mondhatjuk el. Ha egy-két jóslatunk véletlenül be is jön, az csak jó.

Nem hiszitek? Ezt csinálta Michael Levitt is. Az életműve előtt le  a kalappal, hiszen a hatvanas-hetvenes években komplex molekulák számítógépes modellezésével foglalkozott. El lehet képzelni, milyen hardver és szoftver környezettel dolgozhatott, úgyhogy abban alkotni maradandót, nem kis munka. Ezzel nem is akarok vitatkozni. De, ami azután jött, az már nem ilyen elismerésre méltó. A járvány kitörésével ugyanis COVID szakértő lett, és lépten-nyomon hangoztatta is jóslatait.

Viszont ezzel a tudományos közösséggel valami baj lehet, én mondom. Nem volt nekik elég a sok nyilatkozat, kijelentés, előrejelzés, amit Levitt tett. Azt is tudni akarták, mégis mi az alapjuk ezeknek a jósnatoknak? Nem azért, mert annyira pontosak voltak, hanem ellenkezőleg, mert úgy tűnt, semmi közük a valósághoz. Például az Egyesült Államokban négy hét alatt vége lesz a járványnak, 170 ezer halottal. Ha pedig egy ilyen befolyásos ember mond hülyeséget, annak következményei vannak, gondoljunk csak a C-vitaminra és a megfázásra.

A nagy unszolásnak az lett a vége, hogy született egy kézirat, ami a szokásos csontot veti oda a nyílt tudomány híveinek: minden adat és kód nyilvános lesz. Hol és mikor, az már egy más kérdés. Ezek a hátul gombolós tudósok folyton ilyen apróság miatt hisztiznek. De azért így is érdekes dolgokat tudhatunk meg. Például Levitt Mortranban kódol. Nem kell félni, nekem is kiadós utánajárást jelentett, ami azt jelenti, mégsem vagyok olyan öreg. :-) Ez a csökevény még '75-ből maradt ránk, a trapéz gatya és a hippi hajviselet korából. Tudom, hogy régi programnyelv, nem vén programnyelv. Azt is tudom, hogy a COBOL is milyen értékes lett. De bárki, aki számítógépekkel foglalkozik, lépést kell, hogy tartson azok fejlődésével is, nem igaz? Ha pedig programozik, akkor a programozási nyelvek fejlődésével is. Nem baj, ha valaki szereti a Fortrant, de akkor tartson is lépést vele!

Azért nehogy azt higgyük, ez az ember képtelen a fejlődésre! A cikk következő bekezdésében megtudjuk, hogy Levitt másik kedvenc programozási nyelve egy elavult Perl. Nem kéne ilyen szigorúnak lennem vele, lehet, hogy magabiztosan kezeli a Python 2.3-t is...

Nem sokat tudok a Mortranról, de valószínűleg manapság nem lehet binárist készíteni vele, hiszen a kéziratban is azt írták, hogy átfordították C-re. De mi is az a nagy titok, amit ebben a nyelvben fejlesztettek? Mi lehet az, amit csak Mortranban lehet megoldani? A válasz nem más, mint a loess normalizálás. Ez nem más, mint egy közönséges görbe simító eljárás, amit ilyen ujhullámos nyelvekben, mint R és Python rutinszerűen szoktak meghívni. Nos, a szerzők találtak egy '76-ból származó Fortran kódot (biztos az egyik szalagos egységen pihent), amit átírtak Mortranba. Igen, abba a Mortranba, amit végül C-re fordítottak.

Így dolgoznak az igazi nagyágyúk. Ezek a mai tejfölös szájú mitugrászok meg jönnek a deep learninggel, meg virtualizációval, hogy mindent a nyomorult felhőben futtassanak. Még egy nyamvadt Mortran kódot sem tudnak összedobni. Bezzeg régen! A mai fiatalok azt hiszik, hogy a forráskódból olyan természetességgek jönnek létre a binárosok. Klikkelgetnek az IDE-n aztán deployolnak operációs rendszertől függetlenül? Régen nem így volt. Régen a binárisért meg kellett szenvedni, és aki nem szenved meg érte most, az nem is tudja értékelni azt! Van még mit tanulni.