Matura z informatyki rozszerzonej 2026 - co było w arkuszu i gdzie łatwo było stracić punkty?

Ten arkusz dobrze pokazał, że na maturze z informatyki rozszerzonej nie wystarczy „znać składnię”. Trzeba umieć zatrzymać się nad poleceniem, zauważyć ograniczenia, dobrać strukturę danych i pilnować szczegółów technicznych.

W kilku zadaniach zdający mógł mieć dobry pomysł, a mimo to stracić punkty przez drobiazg: zły plik, błędną kolejność symulacji, pominięcie pustego pola albo zbyt szybkie użycie gotowej funkcji.

Najkrócej: co warto zapamiętać z tej matury?

Arkusz miał 8 zadań i łącznie 50 punktów. Czas pracy wynosił 210 minut. Ważne było połączenie części teoretycznej, algorytmicznej i praktycznej pracy z plikami.

Najbardziej charakterystyczne były zadania, w których trzeba było:

• przeanalizować rekurencję bez komputera,

• zapisać algorytm z mocnymi ograniczeniami,

• przetwarzać dane tekstowe,

• pracować na strukturze hierarchicznej,

• tworzyć zestawienia i wykres,

• wykonać symulację krok po kroku,

• połączyć dane z kilku plików,

• zapisać zapytanie SQL.

To nie był arkusz do przejścia „na pamięć”. Raczej arkusz, który sprawdzał, czy uczeń naprawdę rozumie, co dane zadanie każe policzyć.

Linki do materiałów źródłowych

Arkusz PDF:
https://arkusze.pl/maturalne/informatyka-2026-maj-matura-rozszerzona.pdf

Załączniki do arkusza:
https://arkusze.pl/maturalne/informatyka-2026-maj-matura-rozszerzona-zalaczniki.zip

Co było w arkuszu?

1. Rekurencja

   Pierwsze zadanie dotyczyło funkcji zdefiniowanej rekurencyjnie. Zdający musiał analizować kolejne wywołania funkcji A, liczyć ich liczbę, podawać wartości funkcji oraz opisywać zmianę drugiego argumentu w kolejnych wywołaniach.

   To zadanie wymagało spokojnego śledzenia definicji. Szczególnie ważne było rozróżnienie dwóch przypadków: gdy drugi argument jest parzysty i gdy jest nieparzysty.

2. Dodawanie

   Drugie zadanie zaczynało się od prostego na pozór dodawania pisemnego i liczenia przeniesień. W części algorytmicznej trzeba było zapisać sposób liczenia przeniesień dla dwóch liczb o tej samej liczbie cyfr.

   Najważniejszy szczegół: algorytm mógł operować wyłącznie na liczbach całkowitych i zmiennych przechowujących pojedyncze liczby całkowite. Nie wolno było korzystać z tablic, list, napisów ani konwersji między tekstem a liczbą.

3. Pary słów

   W zadaniu z plikiem pary.txt trzeba było pracować na parach słów. Podzadania dotyczyły:

   • największej bezwzględnej różnicy sum kodów ASCII znaków,

   • największej sumy wspólnych wystąpień liter w dwóch słowach,

   • wyszukiwania par, dla których najdłuższy prefiksosufiks ma co najmniej 5 liter.

   To zadanie sprawdzało nie tylko znajomość pracy z tekstem, ale też uważne rozumienie definicji. Prefiksosufiks działał w dwóch kierunkach: początek pierwszego słowa z końcem drugiego albo początek drugiego z końcem pierwszego.

4. Korporacja

   Zadanie opisywało strukturę przełożonych i podwładnych w korporacji. Najpierw pojawił się przykład bez komputera, a potem praca z plikiem korpo.txt zawierającym 50 000 liczb.

   Trzeba było m.in. policzyć:

   • ilu pracowników nie jest przełożonym żadnego pracownika,

   • który pracownik ma najwięcej bezpośrednich podwładnych,

   • ilu najwięcej przełożonych ma jeden pracownik i ilu pracowników ma taką liczbę przełożonych.

   To zadanie mocno przypominało pracę z drzewem. Bardzo łatwo było pomylić bezpośrednich podwładnych ze wszystkimi podwładnymi albo przełożonego bezpośredniego ze wszystkimi przełożonymi.

5. Systemy liczbowe

   Pojawiło się krótkie zadanie z liczbami zapisanymi w systemie piątkowym, dziesiętnym i trójkowym. Trzeba było uzupełnić brakujące liczby tak, aby równości były prawdziwe.

   To typ zadania, w którym błąd często zaczyna się od nieuważnego przepisania podstawy systemu albo od potraktowania zapisu w innym systemie jak zwykłej liczby dziesiętnej.

6. Adresy IP

   Krótkie zadanie sprawdzało znajomość długości adresów IPv4 i IPv6. Tutaj najważniejsza była precyzyjna wiedza, bez długich obliczeń.

7. Staw

   W zadaniu dotyczącym stawu trzeba było pracować z plikiem staw.txt, który zawierał dane z całego 2022 roku: datę, temperaturę i opady. Część zadania wymagała przygotowania zestawienia średnich miesięcznych temperatur i wykresu kolumnowego. Kolejna część dotyczyła najdłuższych ciągów dni bez opadów.

   W dalszej części pojawiła się symulacja rozrostu rzęsy wodnej od 1 marca do 31 sierpnia 2023. Trzeba było uwzględnić wzrost dzienny, powierzchnię stawu, zjadanie rzęsy przez amury i dodatkowe odławianie w piątki.

8. Sieć sklepów

   Ostatnie zadanie dotyczyło danych o klientach, transakcjach i opisach transakcji. W plikach pojawiły się m.in. identyfikatory klientów, sklepów, sprzedawców, produktów, ceny i liczby sztuk.

   Podzadania wymagały:

   • znalezienia klienta z największą liczbą transakcji,

   • policzenia kobiet i mężczyzn, którzy niczego nie kupili,

   • obsługi kas samoobsługowych, czyli transakcji z pustym polem sprzedawcy,

   • znalezienia sprzedawcy pracującego w największej liczbie różnych sklepów w jednym miesiącu,

   • zapisania zapytania SQL dla zakupionych produktów z konkretnej kategorii i z określonym fragmentem opisu.

   To zadanie było szczególnie wrażliwe na dokładne rozumienie struktury danych. Identyfikatory transakcji nie były nadane chronologicznie, a puste pole sprzedawcy nie było błędem w pliku, tylko informacją o kasie samoobsługowej.

Gdzie można było stracić punkty?

Największe ryzyko nie polegało na jednym „strasznym” zadaniu. Ryzyko było rozłożone po całym arkuszu. Wiele punktów mogło uciec przez drobne decyzje techniczne.

Najbardziej prawdopodobne miejsca straty punktów:

• pomylenie danych przykładowych z właściwym plikiem,

• zapisanie odpowiedzi bez numerów zadań w pliku wynikowym,

• oddanie pliku pod inną nazwą niż wymagana,

• użycie list, tablic albo napisów w zadaniu, które tego zakazywało,

• nieuwzględnienie przeniesienia z poprzedniej kolumny w dodawaniu,

• liczenie prefiksosufiksu tylko w jednym kierunku,

• pomylenie bezpośrednich podwładnych ze wszystkimi podwładnymi,

• zbyt wolny algorytm przy dużym pliku,

• błędna obsługa przecinka dziesiętnego w danych liczbowych,

• potraktowanie pustego pola jako błędu zamiast informacji,

• założenie, że identyfikator transakcji oznacza kolejność czasową,

• pominięcie liczby sztuk przy liczeniu wartości zakupów,

• źle ustawiona kolejność zdarzeń w symulacji rzęsy wodnej,

• brak czytelnego opisu wykresu,

• zapytanie SQL bez wszystkich potrzebnych połączeń tabel.

Na co trzeba było szczególnie uważać?

W zadaniu 2.2 najważniejsze było ograniczenie dotyczące typu operacji. To zadanie celowo odcinało łatwą drogę: nie wolno było zamienić liczby na tekst i przejść po znakach. Trzeba było wydobywać cyfry operacjami arytmetycznymi, na przykład przez resztę z dzielenia i dzielenie całkowite.

W zadaniu 3.3 słowo „prefiksosufiks” mogło wyglądać groźnie, ale sednem było porównywanie początku jednego słowa z końcem drugiego. Pułapka: trzeba było sprawdzić oba kierunki.

W zadaniu 4 trzeba było dobrze zobaczyć strukturę drzewa. Samo zliczenie, ile razy numer pracownika pojawia się jako przełożony, pomaga w części o bezpośrednich podwładnych, ale nie wystarcza do ustalenia liczby wszystkich przełożonych danego pracownika.

W zadaniu 7 kolejność zdarzeń miała znaczenie. Przyrost następował w nocy, pomiar rano, w ciągu dnia rzęsę zjadały amury, a w piątki dodatkowo odławiano jej część. Zmiana tej kolejności mogła dać inny wynik.

W zadaniu 8 szczególnie ważne były puste pola i relacje między plikami. Puste IdSprzedawcy oznaczało kasę samoobsługową. Wartość zakupów wymagała uwzględnienia ceny i liczby sztuk. Do zapytania SQL trzeba było połączyć dane o zakupionych produktach z tabelami produktów i kategorii.

Które typy zadań mogły być najtrudniejsze?

1. Algorytm z ograniczeniami w zadaniu 2.2

   Dla wielu zdających trudność mogła polegać nie na samym liczeniu przeniesień, tylko na zakazie używania wygodnych narzędzi. Zadanie wymuszało myślenie „cyfra po cyfrze” na liczbach całkowitych.

2. Prefiksosufiks w zadaniu 3.3

   To zadanie wymagało dokładnego przetłumaczenia definicji na algorytm. Jedno przeoczenie kierunku porównania mogło spowodować brak części odpowiedzi.

3. Hierarchia w zadaniu 4

   Duży plik i relacje przełożony-podwładny wymagały uporządkowanego podejścia. Trzeba było wiedzieć, kiedy wystarczy proste zliczanie, a kiedy trzeba przejść po łańcuchach przełożonych.

4. Symulacja w zadaniu 7.3 i 7.4

   Symulacje są zdradliwe, bo wyglądają jak prosta pętla, ale wynik zależy od detali: dnia startu, poranka, nocy, procentów, powierzchni, ryb i piątkowego odławiania.

5. Agregacje i łączenie danych w zadaniu 8

   Trzeba było łączyć dane z kilku plików, grupować je według różnych kryteriów i uważać na szczegóły biznesowe: kto niczego nie kupił, gdzie była kasa samoobsługowa, w ilu sklepach pracował sprzedawca w jednym miesiącu.

Jakie błędy były najbardziej prawdopodobne?

W tym arkuszu bardzo prawdopodobne były błędy niepozorne, ale kosztowne:

• rozpoczęcie kodowania bez wypisania, czego dokładnie szukamy,

• brak testu na pliku przykładowym,

• pozostawienie programu działającego na pliku przykładowym zamiast na właściwym,

• liczenie wyniku tylko dla pierwszego pasującego przypadku, gdy trzeba było sprawdzić wszystkie,

• nieuwzględnienie ostatniego dnia albo przesunięcie daty o jeden dzień,

• traktowanie procentu jako liczby bez zamiany na ułamek dziesiętny,

• pomylenie 75 procent powierzchni stawu z 75 metrami kwadratowymi,

• zapomnienie, że staw ma powierzchnię 10 000 metrów kwadratowych,

• niewłaściwe sortowanie albo porównywanie miesięcy jako tekstu,

• brak rozróżnienia między liczbą transakcji a wartością zakupów,

• nieuwzględnienie klientów, których nie ma w pliku transakcji,

• zapisanie wyniku bez wymaganego formatu,

• oddanie kodu bez pliku wynikowego albo pliku wynikowego bez kodu.

Co ten arkusz mówi przyszłym zdającym?

• Pierwszy wniosek: trzeba ćwiczyć czytanie poleceń tak samo serio jak pisanie kodu.

  W informatyce maturalnej wiele zadań da się zepsuć jeszcze przed napisaniem pierwszej linijki programu, jeśli źle zrozumie się dane.

• Drugi wniosek: warto umieć pracować z plikami bez paniki.

  Trzeba sprawdzać nagłówki, separatory, puste pola, format daty, przecinek dziesiętny i to, czy identyfikator naprawdę oznacza kolejność.

• Trzeci wniosek: zadania algorytmiczne wymagają prostych, pewnych narzędzi.

  Rekurencja, pętla, zliczanie, maksimum, grupowanie, symulacja i relacje między obiektami wracają w różnych przebraniach.

• Czwarty wniosek: samo „działa na przykładzie” nie wystarcza.

  Program musi działać na właściwym pliku i dla wszystkich przypadków, nie tylko dla pierwszego wygodnego testu.

• Piąty wniosek: warto ćwiczyć zapisywanie wyniku.

  Na egzaminie liczy się nie tylko poprawne obliczenie, ale też plik wynikowy, numeracja odpowiedzi, nazwa pliku i dołączony kod źródłowy.

Jak wykorzystać ten arkusz do powtórki?

Dobry sposób pracy z tym arkuszem:

• najpierw rozwiązać go bez presji czasu i zapisać, które polecenia wymagały ponownego czytania,

• osobno wypisać wszystkie pliki wejściowe i pliki wynikowe,

• przy każdym zadaniu dopisać, jakiego typu algorytm był potrzebny,

• zaznaczyć miejsca, gdzie pojawia się ograniczenie, puste pole, nietypowy format albo szczególny warunek,

• zrobić drugi przebieg tylko z zadaniami praktycznymi,

• po rozwiązaniu porównać program z własnymi notatkami: czy program liczy dokładnie to, co było w poleceniu,

• przygotować małe karty ćwiczeń z tematów: rekurencja, operacje na cyfrach liczby, przetwarzanie napisów, hierarchie, symulacje, grupowanie danych i SQL.

Dla nauczyciela ten arkusz może być dobrym materiałem do rozbicia na lekcje tematyczne. Nie trzeba od razu robić całych 210 minut.

Można osobno przećwiczyć:

• analizę rekurencji,

• algorytm bez napisów i list,

• wyszukiwanie maksimum w danych tekstowych,

• pracę z drzewem przełożonych,

• wykres i analizę miesięczną,

• symulację procesu dzień po dniu,

• agregacje w danych transakcyjnych,

• zapytania SQL z kilkoma tabelami.

Podsumowanie

To był arkusz, w którym spokojna praca była bardzo cenna. Zdający musiał nie tylko znać algorytmy, ale też rozumieć dane, warunki i format odpowiedzi.

Największa lekcja dla przyszłych maturzystów brzmi: zanim zaczniesz kodować, nazwij problem własnymi słowami. Potem sprawdź dane. Dopiero potem pisz program.

Jeśli przygotowujesz się do matury z informatyki, nie ćwicz tylko „dużych arkuszy”. Ćwicz małe, konkretne umiejętności: czytanie plików, zliczanie, maksimum, symulację, daty, puste pola i łączenie danych. To właśnie takie drobne elementy najczęściej decydują o tym, czy dobry pomysł zamieni się w poprawne rozwiązanie.