NaN (Not a Number) menunjukkan keanehan yang jarang diperhitungkan dalam desain bahasa pemrograman. Dua studi kasus terbaru pada Python dan Lua memperlihatkan bagaimana asumsi dasar yang melanggar aturan NaN berujung pada perilaku kode yang tidak intuitif.
Standar IEEE-754 mendefinisikan NaN sebagai nilai khusus untuk merepresentasikan hasil perhitungan yang tidak terdefinisi, seperti pembagian nol dengan nol. Keanehannya terletak pada sifatnya yang tidak mematuhi logika perbandingan biasa. Dalam Python, ekspresi `nan == nan` secara resmi mengembalikan nilai `False`. Namun, ketika NaN dimasukkan ke dalam sebuah list, perbandingan `[nan] == [nan]` justru menghasilkan `True`.
Perilaku ganjil ini berakar pada optimasi internal Python. Saat membandingkan dua list untuk mengecek kesetaraan, interpreter pertama-tama memeriksa identitas objek menggunakan operator `is`. Pemeriksaan kesetaraan nilai baru dilakukan jika identitas keduanya berbeda. Manual referensi Python 3 menegaskan bahwa objek identik seharusnya selalu membandingkan setara (`x is y` menyiratkan `x == y`). Asumsi refleksif ini runtuh ketika bertemu NaN, meski hal itu tidak lantas membuat optimasi Python salah secara fungsional.
Bagi ekosistem teknologi di Indonesia, temuan ini menjadi pengingat kritis terutama untuk tim pengembang perangkat lunak lokal yang banyak mengandalkan Python untuk analisis data dan Lua untuk pengembangan game atau sistem tertanam. Kesalahan logika yang tidak terduga akibat NaN berpotensi memicu bug halus yang sulit dilacak, terutama pada sistem keuangan atau telemetri yang memproses data hilang (missing data) sebagai NaN.
Di sisi lain, Lua menunjukkan masalah yang lebih parah karena menyentuh struktur kontrol inti. Perulangan numerik `for` dalam Lua dirancang dengan pola `for i = 1, 10 do`. Jika batas awal diisi dengan `0/0` (NaN), perulangan hanya dieksekusi sekali. Sebaliknya, jika langkah (step) diisi NaN, perulangan bisa tidak berjalan sama sekali atau malah berjalan sekali dengan arah yang terbalik. Hal ini terjadi karena implementasi referensi PUC-Rio Lua memeriksa batas dengan operator `limit < init` untuk iterasi pertama, lalu `idx <= limit` untuk berikutnya, serta menganggap step NaN selalu negatif karena `0 < step` bernilai false.
Ketiadaan dokumentasi resmi mengenai perilaku ini di Lua mengindikasikan adanya kelalaian desain. Padahal, Lua sudah menyiapkan mekanisme error ketika langkah bernilai 0, sehingga wajar jika pengembang mengasumsikan NaN juga akan ditolak. Di Indonesia, banyak startup gaming menggunakan Lua melalui mesin seperti Corona SDK atau Love2D; kebiasaan mengabaikan validasi input NaN dapat merusak logika game secara diam-diam.
Chris Siebenmann sebelumnya pernah mencatat keanehan serupa ketika NaN digunakan sebagai kunci pada tipe map di bahasa Go. Penemuan beruntun di tiga bahasa populer ini membuktikan bahwa NaN bukan sekadar anomali matematis, melainkan “penyusup” yang membocorkan operator perbandingan internal ke dalam perilaku interpreter.
“Menggunakan NaN menyebabkan operator perbandingan spesifik yang dipakai oleh implementasi bocor ke dalam perilaku interpreter,” demikian observasi penulis studi kasus tersebut. Fenomena ini mengajarkan bahwa asumsi sederhana dalam ilmu komputer, seperti “setiap objek harus sama dengan dirinya sendiri”, sering kali gagal ketika berhadapan dengan batas aritmatika floating-point.
Langkah mitigasi yang paling rasional adalah pemeriksaan eksplisit terhadap keberadaan NaN sebelum memasuki logika perbandingan atau struktur perulangan. Komunitas pengembang Lua disarankan untuk segera mengadopsi pemeriksaan `isnan()` pada parameter loop guna mencegah perilaku tak terdefinisi.
Ke depannya, paradigma desain bahasa pemrograman perlu lebih inklusif dalam menangani nilai ekstrem IEEE-754. Seiring dengan bertumbuhnya industri komputasi performa tinggi dan kecerdasan buatan di Indonesia, pemahaman mendalam terhadap mekanisme NaN akan menjadi fondasi penting agar sistem otomasi tidak mengambil keputusan keliru berdasarkan data yang secara teknis “tidak ada”.