NaN - czym jest i jak bezpiecznie go wykrywać?

W obliczeniach bardzo łatwo trafić na wynik, który nie daje się zapisać jako zwykła liczba: pojawia się przy dzieleniu przez zero, błędnym odczycie tekstu albo w danych z lukami. Taka wartość nazywa się NaN i potrafi zepsuć porównania, średnie oraz sortowanie, jeśli potraktuje się ją jak normalny numer. W tym artykule wyjaśniam, czym jest ten stan, skąd się bierze, jak działa w porównaniach i jak bezpiecznie obsługiwać go w kodzie oraz analizie danych.

Czym jest NaN i dlaczego w obliczeniach pojawia się osobna kategoria wyniku

W matematyce szkolnej przyzwyczajamy się do odpowiedzi w postaci liczby. Komputer działa podobnie tylko do pewnego momentu: gdy wynik nie ma sensownej reprezentacji w zbiorze liczb rzeczywistych, system zapisywania liczb zmiennoprzecinkowych musi dać jakiś znak ostrzegawczy. Właśnie tym znakiem jest NaN, czyli wartość specjalna „not a number”.

IEEE 754 to standard opisu liczb zmiennoprzecinkowych, czyli takich, które mieszczą ułamki, bardzo duże wartości i różne stany specjalne w ograniczonej liczbie bitów. Ja lubię myśleć o NaN nie jak o liczbie z dziwną nazwą, lecz jak o komunikacie: „tutaj obliczenie przestało mieć sens liczbowy”. W praktyce to odróżnienie jest ważne, bo co innego błąd rachunkowy, a co innego celowy znacznik braku danych.

W szkolnych notatkach zwykle tłumaczę to tak: w matematyce można powiedzieć, że działanie jest nieokreślone albo nie ma rozwiązania w danym zbiorze, a w komputerze ten problem przybiera postać konkretnej wartości specjalnej. To właśnie dlatego warto znać NaN zanim zacznie się analizować większe zbiory danych albo pisać własne obliczenia. Najpierw jednak dobrze zobaczyć, w których miejscach pojawia się najczęściej.

Skąd bierze się NaN w praktyce

Najczęściej widzę trzy źródła tego stanu: nieprawidłowe działanie matematyczne, nieudane konwersje danych i brakujące wartości zakodowane jako specjalny znacznik. To nie jest akademicki detal. W arkuszu, skrypcie albo aplikacji webowej jeden taki przypadek potrafi rozlać się na cały wynik.

Błędy rachunkowe

Do NaN prowadzą działania, które nie mają sensownego wyniku liczbowego: 0/0, odejmowanie nieskończoności od nieskończoności, mnożenie z niejednoznacznym rezultatem albo próba policzenia pierwiastka z liczby ujemnej w arytmetyce rzeczywistej. Jak opisuje MDN Web Docs, do NaN prowadzą między innymi nieudane konwersje, działania typu Math.sqrt(-1) i inne postaci wyniku nieokreślonego.

W praktyce to bardzo ważne, bo jeden błąd w środku wzoru może sprawić, że kolejne operacje też dadzą NaN. Innymi słowy, ta wartość bywa zaraźliwa. Jeśli w formule pojawi się raz, dalsze obliczenia często nie uratują już wyniku.

Nieudane parsowanie danych

Drugi częsty przypadek to tekst, który miał być liczbą, ale nią nie jest. W formularzach pojawia się pusty ciąg, przecinek zamiast kropki, dopisek jednostki albo przypadkowy znak. Dla człowieka to drobiazg, dla parsera często powód do zwrócenia NaN. I właśnie tutaj najłatwiej o błąd interpretacji: program nie krzyczy od razu, tylko oddaje wartość, która wygląda jak liczba, ale nią nie jest.

Brakująca wartość zakodowana jako NaN

W analizie danych NaN bywa używany po prostu jako reprezentacja brakującej obserwacji. Według dokumentacji Pythona takie wartości trzeba odfiltrować przed obliczaniem statystyk, bo sortowanie, mediana czy kwantyle mogą wtedy dawać zaskakujące wyniki. To podejście jest rozsądne, ale wymaga konsekwencji: jeśli NaN oznacza brak danych, nie wolno go po cichu traktować jak zera.

Najważniejszy wniosek z tej sekcji jest prosty: zanim zaczniesz naprawiać wynik, ustal, czy masz do czynienia z błędem rachunkowym, problemem z wejściem czy świadomym znacznikiem braku. To prowadzi bezpośrednio do pytania, jak NaN zachowuje się po pojawieniu się w obliczeniach.

Jak NaN zachowuje się w porównaniach i działaniach

Tu pojawia się najwięcej niespodzianek. NaN nie zachowuje się jak zwykła liczba, więc zwykłe nawyki z matematyki szkolnej przestają wystarczać. Gdy porównujesz go z innymi wartościami, wynik bywa nieintuicyjny, ale właśnie dzięki temu system nie udaje, że ma odpowiedź, której po prostu nie ma.

W JavaScript MDN podkreśla, że NaN jest jedyną wartością, która nie jest równa samej sobie, a w porównaniach porządkowych daje false. To właśnie dlatego algorytmy oparte wyłącznie na równaniu lub większe/mniejsze potrafią zawieść w najmniej spodziewanym momencie.

Warto zapamiętać jeszcze jedną rzecz: NaN zwykle „przechodzi” przez kolejne działania. Jeśli po lewej albo prawej stronie pojawi się wartość specjalna, wynik często też będzie NaN. Dla programisty to sygnał, żeby przerwać łańcuch obliczeń i sprawdzić źródło problemu, a nie tylko końcowy rezultat.

Skoro już widać, że porównania z NaN są zdradliwe, naturalnym kolejnym krokiem jest sprawdzenie go właściwymi narzędziami, zamiast liczenia na zwykłe operatory.

Jak wykrywać i bezpiecznie obsługiwać NaN w kodzie

Nie próbuję wykrywać tej wartości przez ==, bo to zwyczajnie nie działa. Zamiast tego używam funkcji przygotowanych właśnie do tego celu. To niewielki nawyk, ale oszczędza bardzo wiele czasu podczas debugowania i czyszczenia danych.

W Pythonie

import math

x = float('nan')

math.isnan(x)   # True
x == x          # False

W Pythonie dokumentacja zaleca math.isnan(), ponieważ NaN nie jest równy samemu sobie. W praktyce oznacza to, że sprawdzanie przez is albo == prowadzi do błędnych wniosków. Jeśli pracuję na liście liczb, filtruję NaN osobno, zanim liczę średnią, medianę albo minimum.

Przeczytaj również: Okres w matematyce: zrozumienie ułamków okresowych i funkcji

W JavaScripcie

const value = Number('abc');

Number.isNaN(value); // true
isNaN('abc');        // true
Number.isNaN('abc'); // false

W JavaScripcie różnica między isNaN() a Number.isNaN() ma znaczenie praktyczne. Pierwsza funkcja najpierw próbuje konwersji, druga sprawdza już gotową wartość. Jeśli zależy mi na przewidywalności, wybieram Number.isNaN(), bo unikam ukrytych przekształceń.

Obsługa NaN nie kończy się jednak na samym teście. Trzeba jeszcze zdecydować, co zrobić z danymi: odrzucić rekord, uzupełnić brak, zastąpić wartością domyślną czy oznaczyć błąd w interfejsie. To decyzja merytoryczna, nie tylko techniczna.

Właśnie dlatego kolejnym krokiem jest rozróżnienie NaN od innych stanów specjalnych, które na pierwszy rzut oka wyglądają podobnie.

NaN a null, undefined i nieskończoność

Na początku kariery wiele osób wrzuca te pojęcia do jednego worka, a potem dziwi się, że raport albo formularz zachowuje się inaczej niż oczekiwano. Ja rozdzielam je od razu, bo każde z nich niesie inną informację.

Różnica jest praktyczna. null często mówi: „tu świadomie nic nie wpisano”. undefined bywa stanem pośrednim, gdy wartość jeszcze nie istnieje. Infinity oznacza, że liczba wyszła poza zakres, ale nadal pozostaje liczbą specjalną. NaN stoi obok nich, bo sygnalizuje nie tyle brak, ile problem z samym wynikiem obliczenia.

Jeśli projektujesz formularz, API albo arkusz z danymi, taka precyzja bardzo się opłaca. Ułatwia walidację, upraszcza debugowanie i zmniejsza ryzyko, że ktoś zamieni błąd na pozornie poprawną liczbę. To prowadzi do najbardziej bolesnego etapu pracy z NaN: typowych błędów w danych i raportach.

Najczęstsze błędy przy pracy z NaN w danych i raportach

W praktyce problem rzadko leży w samym NaN. Znacznie częściej kłopotem jest to, że ktoś zareagował za późno albo użył zbyt prostego skrótu. Oto błędy, które widzę najczęściej:

• Zastępowanie NaN zerem bez uzasadnienia - średnia, suma i procenty zaczynają wtedy udawać poprawne wyniki, choć w rzeczywistości są zafałszowane.
• Liczenie statystyk bez czyszczenia danych - jedna brakująca wartość potrafi zmienić medianę, kwartyle albo kolejność po sortowaniu.
• Używanie zwykłego porównania - == i > nie powiedzą Ci, że masz do czynienia z NaN.
• Mieszanie NaN z pustym tekstem - to nie to samo i nie powinno oznaczać tego samego w modelu danych.
• Ukrywanie błędu zamiast jego nazwania - jeśli wartość jest niepoprawna, lepiej ją oznaczyć niż przykryć.

Najlepsza praktyka jest zwykle prosta: najpierw walidacja wejścia, potem test NaN, a dopiero później obliczenia. Gdy pracuję z większym zbiorem danych, traktuję to jako obowiązkowy etap porządkowania, nie opcjonalny dodatek.

Kiedy to już działa, można spojrzeć szerzej i odpowiedzieć na pytanie, kiedy NaN jest użytecznym sygnałem, a kiedy po prostu błędem, który trzeba naprawić.

Kiedy NaN jest sygnałem, a kiedy problemem do naprawy

Najprostsza zasada brzmi: jeśli NaN pojawia się jako świadomy marker brakującej informacji, może być pomocny. Jeśli wyskakuje w miejscu, w którym miał powstać konkretny wynik liczbowy, jest sygnałem, że trzeba wrócić do źródła problemu.

• W obliczeniach naukowych NaN często oznacza, że zakres wzoru został przekroczony albo wejście było niepoprawne.
• W danych tabelarycznych może sygnalizować brak obserwacji, ale wtedy trzeba to jasno obsłużyć w kolejnych krokach.
• W formularzach i aplikacjach najczęściej mówi o błędzie walidacji albo nieudanym przekształceniu tekstu na liczbę.
• W raportach NaN nie powinien być ukrywany, tylko opisany i przeliczony po świadomej decyzji.

Gdy uczę się lub tłumaczę ten temat, zawsze powtarzam jedno: NaN nie jest liczbą do dalszego liczenia, tylko informacją diagnostyczną. Jeśli potraktujesz go jak zwykłą wartość, prędzej czy później dostaniesz wyniki, które wyglądają poprawnie, ale nie mają już sensu.