Zápočet 19. 1. 2015

Zadával to Yaghob, byly povolený vlastní notebooky a net.
Zadání: Z FITS souboru vypsat seznam hlaviček z jednotlivých HDU (header&data unit), typ jednotlivých HDU (primary, image, bintable) a velikost dat. Ten FITS soubor je binární, ale ty hlavičky jsou v něm uložený textově (včetně čísel), takže s tim zas takovej problém nebyl.
Pokud by to náhodou chtěl někdo zkoušet tak jsem napíšu jenom takovej krátkej seznam toho co nám řikal:
V souboru jsou sekvenčně uloženy jednotlivé HDU. Každá HDU obsahuje nejdříve hlavičky a pak data. Obě tyto části jsou zarovnány na 2880B bloky. Hlavička obsahuje keywordy. Keyword je 80b (co jednotlivý bajty znamenaj viz. přiložená dokumentace toho formátu kapitola 4.1). Hlavička je ukončena keywordem END, za ním i před ním může být libovolně mnoho blanků (80 mezer), ale ta hlavička je zarovnaná na 2880B bloky. Jak se spočítá velikost dat v bitech viz. str. 21 v přiloženém pdf, na tý samý stránce je taky vzor jak vypadá primární HDU (začíná to tím SIMPLE = T), jak vypadají image a bintable viz příslušné podkapitoly v kapitole standard extensions (str 22). U tech keywordu teda je jeste potreba napsat jakyho typu je ta hodnota (viz kapitola Headers->Value). Je potřeba taky si dát bacha, že za tou hodnotou může být / a komentář.

Jinak to probíhalo tak, že nám nejdřív asi 30min vysvětlovat co po nás vlastně chce a povídal nějaký takovýhle věci o tom jak ten formát vypadá, případný další dotazy ohledně toho formátu zodpovídal i během testu. Já odcházel asi v 17:00 a vetsina tam jeste byla (začínalo se ve 13:30 + tech 30min).

Kontrola probihala tak, ze se podival jestli to vypisuje spravny veci. Zdrojak vubec nezkoumal, dokonce si ani neoveroval, jestli jsem to skutecne psal v c++ :D

Ze zadani to mozna nevypada, ale nebylo to tezky, spis slo o to se nejak poprat s tim formatem.

Dostali jsme k tomu tenhle zip, obsahuje 3 příklady FITS souborů i s očekávaným výstupem a dokumentaci toho formátu.

Další náhled na to samé.

• Bylo potřeba číst binární soubor. (hodně lidí nevědělo, že existuje něco jako ios::binary)

• V souboru mohlo být libovolné množství bloků HDU, takže bylo zapotřebí zpracovávat data jednotlivě po HDU až do konce streamu.

• HDU neměly pevnou velikost. Určovala se z jejich obsahu – headeru a dat.

• Header se skládal z libovolného rámců. Každý měl pevnou velikost 80B.

  • Byte 0-7 byl povinný keyword.

  • Byte 8-9 byl vždy rovnítko a mezera.

  • Zbytek byl value a comment (tyto hodnoty byly obě nepovinné). Na konci headeru byl vždy speciální rámec s keywordem 'END'. Za tímto rámcem mohly ještě následovat prázdné rámce (obsahující jenom mezery) tak, aby byla celková velikost headeru zarovnána na násobek 2880B. Bohužel se nedalo spolehnout na to, že tento násobek bude nejmenší možný. Muselo se tedy kontrolovat, kdy přestanou chodit prázdné rámce.

• Data byla uložena rovnou za headerem a pro účely testu nás nezajímala. Mohli jsme je tedy přeskočit. Bylo ale zapotřebí spočítat správně jejich velikost pro čtení (opravdová velikost uložených informací, která se vypisovala) a velikost pro skok (mohla být větší kvůli zarovnání na násobky 2880B, byla nutná, aby čtení HDU skončilo přesně na začátku další HDU nebo na konci streamu).

Velikost dat se spočítala z headeru. Položka NAXIS určovala dimenzi datové matice (počet os). Velikosti jednotlivých os byly určeny položkami NAXIS1, NAXIS2, atd. Položka BITPIX udávala počet bitů na jednu položku datové matice. Výsledná velikost dat tedy byla určena násobkem BITPIXNAXIS1NAXIS2...NAXIS? (kde ? je hodnota NAXIS). Tato hodnota ale byla v bitech, a tak jí bylo nutno vždy vydělit 8. Ve skutečném vzorci navíc ještě figurovaly další dva koeficienty GCOUNT a PCOUNT, které však ve všech testovacích příkladech byly nastaveny na 1, a tak se jejich vynecháním nic nerozbilo.

Data byla podobně jako header zarovnána na nejbližší horní násobek 2880B, a tak bylo nutné správně spočítat počet bytů k přeskočení.

Program měl přečíst soubor FITS z argumentu a vypsat na stdout pro každou HDU typ, rámce z headeru a skutečnou velikost dat.

• Typ se zjistil z keywordů v headeru. První HDU byla vždy "Primary". Ostatní HDU obsahovaly v headeru položku XTENSION, která nabývala dvou hodnot "IMAGE" nebo "BINTABLE" - tyto hodnoty se vypisovaly jako typ.

• Rámce z headeru nešlo jen tak překopírovat do výstupu, musely se parsovat. Keyword i value obsahovaly počáteční a koncové mezery, které bylo potřeba odstřihnout. Navíc se po nás chtělo, abychom odebrali comment, který byly oddělen prvním lomítkem po skončení hodnoty v poli value. Komentáře ale byly nepovinné a museli jsme počítat s tím, že se ve value nevyskytnou.

• Value jsme měli ještě parsovat na typ, který se vypisoval do výstupu.

  • string - byl ohraničen dvěma apostrofy ('). Pokud však obsahoval dva apostrofy za sebou, byla to escape sequence pro normální apostrof. Navíc, musel se dávat pozor na lomítka uprostřed stringu (byla to součást hodnoty, nikoli oddělovač komentáře). Ve výpisu musely být okolní apostrofy odstraněny a vnitřní dvojapostrofy správně nahrazeny.

  • logical - prakticky bool. Mohl obsahovat hodnotu T nebo F (bez apostrofů). Vypisoval se ale jako TRUE nebo FALSE.

  • int32 - celé číslo v desítkové soustavě. Mohlo být i záporné (pozor na minus). Vypisovalo se standardním c++ způsobem.

  • double - reálné číslo. Mohlo být i záporné. Navíc jsme museli počítat kromě klasického zápsiu i se zápisem ve vědecké notaci (např. 1e09). Vypisovalo se standardním c++ způsobem.

  • complex int, complex double - komplexní varianta předchozích dvou. Obsahovala uspořádanou dvojici dvou int32 nebo double. Bylo nám však řečeno, že tyto dva typy nemusíme implementovat, protože se v testovacích datech nevyskytují.

  • undefined - cokoliv jiného (vč. prázdné hodnoty)

• Bylo nám řečeno, ať naše programy nevypisují rámce s keywordem HISTORY nebo keywordem začínajícím na COMMENT.

• Výpis několika rámců headeru na stdout tedy například mohl vypadat takto:

  SIMPLE[logical]=TRUE NAXIS[int32]=2 XTENSION[string]=IMAGE

Co jsem slyšel od spolužáků, řešili to různě. Někdo to napsal celé prakticky v Céčku, ostatní do toho rvali regex nebo v několika procedurách prakticky implementovali stavový automat (který se jim z regexu stejně vygeneruje). Moje řešení bylo hodně objektové (dědil jsem různé druhy value) a používalo hlavně streamy a streamové operátory.

Odevzdání probíhalo zamáváním na Yaghoba, který přišel, omrknul výpis na stdoutu, případně požádal, ať mu tam dám jiný FITS soubor, a napsal OK k mému jménu na seznam. Nechtěl vidět kód ani způsob řešení.

Času na úlohu bylo celkem dost. Začínalo se před 14 a končilo se v 18. První odevzdali kolem půl páté. Mezi 17:30-18 to ale odevzdali skoro všichni.

Netuší někdo jaká byla úspěšnost?

Katami wrote:Netuší někdo jaká byla úspěšnost?

Když jsem odcházel, úspěšnost byla zhruba tři čtvrtiny.